Availability zones explained in a provider’s documentation are infrastructure boundaries. An application can run in a cloud region containing several availability zones and still fail when one zone goes down. The region’s infrastructure offers fault-isolation boundaries; the workload must actually use them.
AWS’s fault-isolation guidance describes an availability zone as one or more discrete data centers with separate power, networking and connectivity inside a region. Its resiliency documentation then separates those provider responsibilities from how a customer designs an application.
A region and a zone describe different boundaries
AWS says each region is isolated and contains multiple availability zones. Zones within a region are physically separated while connected through low-latency, redundant networking.
That arrangement supports replication across zones without putting every component in the same facility. AWS describes independent power and cooling infrastructure and deployments separated in time to reduce correlated failures.
The distinction matters when reading an incident report. A problem in one zone is different from a regional service problem or a customer’s deployment affecting every copy of an application.
Multi-zone infrastructure is not automatic application recovery
AWS’s shared-responsibility model for resiliency assigns the provider responsibility for the infrastructure and the customer responsibility for the workload design, configuration and operation.
If every application instance is in one zone, the existence of other zones does not move those instances on its own. If data is available only in the failed zone, a running web server elsewhere may have nothing useful to serve.
A review therefore needs to follow dependencies: traffic routing, application capacity, storage, databases and the services used to recover. The label “multi-AZ” on one component does not describe the whole path.
Follow a request through the failure
Consider a hypothetical checkout with application instances in two zones and a database reachable only in one. Losing the database’s zone can stop checkout even while the second application’s instances remain healthy.
The example is not a report of an AWS incident. It illustrates why redundancy should be assessed at the operation a customer needs to finish rather than counted as a number of servers.
| Component | Recovery question |
|---|---|
| Traffic routing | Can requests reach the healthy instances? |
| Application capacity | Can the remaining deployment handle demand? |
| Data | Is the required state available outside the failed zone? |
| Dependencies | Do authentication and other services remain reachable? |
| Recovery controls | Can the team operate them during the disruption? |
A deployment can avoid a single facility’s failure while remaining vulnerable to an application change rolled out everywhere. Independent infrastructure and controlled software releases address different causes.
Another region adds more separation and more work
A second region changes the fault boundary again. It also requires decisions about data replication, traffic movement, recovery timing and service configuration.
For some workloads, several zones in one region match the required recovery objective. Others need a separate regional recovery plan. The provider’s number of regions does not establish which design a workload uses.
AWS’s multi-location deployment guidance places these decisions in the context of workload requirements. State the desired recovery behavior before treating more locations as a complete plan.
Four practical details that shape a multi-zone design
How many zones a region has. AWS’s Regions and Availability Zones page says each AWS region “consists of a minimum of three, isolated, and physically separate AZs.” The same page says zones are separated “by a meaningful distance, many kilometers,” while all zones in a region sit “within 100 km (60 miles) of each other,” which is close enough for synchronous replication.
Networks follow zones too. A virtual network can cover a whole region, but its subnets cannot. The AWS VPC guide on subnets states that “each subnet must reside entirely within one Availability Zone and cannot span zones.” A multi-zone application therefore needs at least one subnet in each zone it uses, and its load balancer and database settings have to point at all of them.
Crossing a zone boundary can cost money. AWS’s global network FAQ says there is a charge for data transferred in and out of EC2, RDS and several other services across availability zones in the same region. An AWS networking post from April 2026 on Network Load Balancer costs puts that inter-zone charge at $0.01 per GB in each direction, with traffic inside one zone free. Spreading across zones buys resilience, and chatty traffic between zones is part of the bill; check the current price on the service’s own pricing page.
Azure uses two terms. Microsoft’s availability sets overview describes an availability set as a grouping that spreads virtual machines across fault domains, which share a power source and network switch. Sets add no extra charge and give lower latency between machines, but Microsoft says they “don’t offer the same level of resiliency as availability zones” and remain exposed to failures such as data-center-level network outages. Availability zones place copies in separate data centers.
Read outage language carefully
A provider can describe an isolated infrastructure failure while users experience a broader outage through a shared dependency. Both descriptions can be consistent if the application concentrates a critical part of its request path.
For the public communication side, see why a status page can lag an outage. For past incidents described in the providers’ own reports, see the outage archive. The recovery architecture and the incident message are separate evidence.
