Shifting resilience testing left, that is, testing early in the application development cycle, is a rational move that helps avoid outages and data loss. Our recent blog and July webinar discussed early, proactive resilience testing and strongly advocated this practice.
Today’s post will look at the kinds of threats to availability and security that arise from misconfigurations and single points of failure in your public cloud environments – AWS and Azure – threats you should avoid by shifting resilience testing left.
Ideally, following every software change or version update, or new capabilities introduced by cloud providers, validation tests should be conducted to examine where changes to configurations should be made. However, the typical development sequence doesn’t normally include such tests. And realistically, it’s impossible to manually keep track of all reconfigurations that must be made to accommodate each application change, version, capability or service.
In our latest webinar entitled “Shifting Left on Cloud Infrastructure Availability” we reviewed a few examples of such misconfigurations. Here’s a recap:
Our AvailabilityGuard NXG™ solution checks for hundreds of potential misconfigurations and single points of failure. The risks above are only a handful of potential scenarios that might occur. It’s very important to be aware that since native tools like AWS Trusted conducts only about 20 checks and Azure only about 5, there’s a very high likelihood that resilience issues which can cause disruption or downtime won’t be detected before they erupt.
AvailabilityGuard NXG scans the enterprise’s entire IT stack for configuration information and compares this against a knowledgebase containing all the constantly updated information available and needed on vendor and user best practices. This is how issues critical to resilience are discovered in time to prevent them from becoming a risk to resilience.