How do you design AWS workloads so an Availability Zone failure does not become a full regional outage?
Quick Answer
You design for AZ failure by spreading stateless capacity, data replicas, routing, and dependencies across at least two or three Availability Zones, then testing that each tier can continue when one zone is impaired. The hard part is removing hidden single-zone dependencies such as NAT gateways, subnets, load balancer targets, caches, and database writers.
Detailed Answer
Think of a hospital system with several buildings on the same campus. If one building loses power, patients should not lose all care because the pharmacy, oxygen supply, and emergency desk were only in that building. AWS Availability Zones are similar failure compartments inside a Region. Multi-AZ design is not just placing servers in two zones; every dependency the service needs must survive the loss of one zone.
AWS reliability guidance emphasizes strong foundations, resilient architecture, change management, and failure recovery. For a web service, this usually means an Application Load Balancer spanning subnets in multiple AZs, Auto Scaling groups balanced across those subnets, independent NAT gateways per AZ for private egress, and data stores configured for Multi-AZ durability or replication. Stateless services are easiest because replacement capacity can start elsewhere. Stateful services need replication, failover semantics, and recovery objectives.
The internal request path matters. A client resolves DNS, reaches a regional load balancer, the load balancer chooses healthy targets, app instances call databases, caches, queues, and external services, and responses return through the same dependency chain. If the app instances are balanced but all private traffic exits through one NAT gateway in the impaired AZ, healthy instances in other zones can still fail. If a cache cluster has all primary shards in one zone, the app may be technically running but unusable.
In production, engineers watch per-AZ target health, load balancer zonal metrics, database failover events, queue age, retry rates, and dependency saturation. They also run game days that intentionally remove an AZ from service, disable a subnet route, or shift traffic away from a zone. Good systems use timeouts, retries with jitter, idempotent writes, queue buffering, and autoscaling headroom so the surviving zones can absorb load without cascading.
The non-obvious gotcha is that multi-AZ can still fail as one unit when deployments, credentials, or shared control-plane assumptions are regional. A bad launch template, expired secret, or globally shared config can break all zones at once. Senior engineers separate failure domains, but they also test rollback, configuration isolation, and dependency degradation. Multi-AZ is a reliability foundation, not a substitute for disciplined operations.