Remove one Availability Zone—what still works?

“Highly available” is incomplete without a failure. Start with one business operation, such as checkout. Then name what disappears: one process, one instance, one Availability Zone, or an entire Region. State how much service must remain and for how long.

Two instances in one Availability Zone can survive one instance failure. They cannot survive losing that zone. Multi-AZ means the required in-Region path uses more than one Availability Zone. A Regional outage requires a separate disaster-recovery design.

Draw the whole path: entry point, subnets, routes, load balancer, targets, state, database, egress, and external dependencies. Remove the failed resources and trace both the request and response. The first required component that no longer exists is the real failure.

This method prevents replica counting from becoming the goal. Five application copies do not help when all five depend on one unavailable route or writer. Count complete surviving business paths, not only resources.

Place enough stateless capacity in at least two Availability Zones before relying on emergency scale-out. An Auto Scaling group can maintain EC2 targets across selected zones. Elastic Load Balancing sends traffic to registered targets according to health.

The surrounding path must also exist in each required zone. A healthy application target is useless if its route, NAT path, database, shared mount, or payment dependency exists only in the failed zone.

Health checks observe a configured endpoint; they do not prove every business operation works. When all registered targets are unhealthy, documented ALB and NLB fail-open conditions can still route traffic. Treat that as degraded routing and check the application response separately.

Keep health probes specific enough to detect the dependency required by the operation, but do not expose secrets. A shallow process check can stay green while checkout fails; an unnecessarily deep check can remove every target during one optional dependency outage.

During an Availability Zone test, cross out every resource in that zone. Recalculate surviving target capacity, IP space, routes, quotas, and startup time. Then send a real request and observe the business result.

Use timeouts, queues, and degraded behavior to contain optional dependency failures. Multiple copies of the same bad deployment are not fault tolerant, so keep immutable versions and a tested rollback path.

Measure successful business operations, latency, errors, healthy targets by zone, and surviving capacity. Extra standby capacity has a cost, but removing it because normal traffic is low contradicts an Availability Zone survival requirement.

Record the expected result before the game day. If the test is meant to preserve half of peak checkout, a surviving but overloaded zone is a failed result. Recovery time and useful capacity belong in the same claim.

A passing test names what remained degraded as well as what worked. Record optional features lost during the failure so the availability claim stays precise.