AWS Availability Zone Design - How Physical Separation and Fault Isolation Create a Reliability Advantage
Examine the design philosophy behind AWS AZs as physically independent data center clusters, compare them with Azure and GCP availability zones, and look at them against the published design criteria and real-world incident examples.
Every Cloud Has Availability Zones, but They Are Not the Same
AWS, Azure, and GCP all offer the concept of "Availability Zones." The basic idea of distributing resources across multiple zones to eliminate single points of failure and achieve high availability is shared. However, the implementation details differ significantly. AWS began offering AZs in March 2008, two years after the EC2 launch in 2006, as a feature added together with Elastic IP addresses. Through operation up to 2026, the separation design criteria and a family of services built on multi-AZ assumptions have been put in place. Azure made Availability Zones generally available in 2018, a 10-year gap in when the offering started. Starting earlier, however, does not by itself mean a superior design. This article sorts out which differences can actually be confirmed, based on the design criteria each provider publishes and primary information on incidents that actually occurred.
AWS AZ Design - Thorough Physical Separation
Each AWS AZ consists of one or more physically independent data centers. AWS has published specific design criteria for this physical separation. Each AZ has an independent power supply sourced from different substations. Cooling systems and network connections are also independent. The distance between AZs is far enough to prevent localized disasters such as floods, earthquakes, and fires from simultaneously affecting multiple AZs, while remaining close enough (typically within 100km) to maintain low-latency communication. The core of this design is "complete separation of failure domains." A power outage in one AZ is designed not to affect adjacent AZs. For network equipment failures, cooling system anomalies, and building-level disasters as well, containing the impact within the affected AZ is the design goal. AWS's own primary description is also written as a design goal - "each AZ is designed to be isolated from failures in other AZs" - and does not guarantee that no event will ever spill over to other AZs. Availability design needs to decide the scope of redundancy with this difference between "design goal" and "guarantee" in mind. AWS describes this as "minimizing the blast radius," reflecting a consistent design philosophy of physically limiting the scope of failure impact.
Azure Availability Zones - Background of Their Introduction and What to Check
Azure made Availability Zones generally available in 2018. Availability zones are described as "one or more data centers with independent power, cooling, and networking," and the idea of distributing resources across multiple zones to eliminate single points of failure is shared with AWS. What differs is the history. Azure originally used Availability Sets (logical separation through fault domains and update domains) as the basic unit of availability, and availability zones were added later as a concept, rolled out gradually while maintaining consistency with existing services. For that reason, design work needs a step of checking, in Microsoft's official region list and per-service documentation, whether the target region supports availability zones and how the services you use handle zones (zone-redundant or pinned to a specific zone). Because support keeps expanding, it is safer not to lock in decisions based on a support table from a single point in time. How much each provider publishes about inter-AZ distances and power and cooling separation criteria also varies. Even when the same term "availability zone" is used, the granularity that users can verify is not uniform, and comparisons need to start from that premise.
GCP Zone Design - A Different Approach
GCP zones are conceptually similar to AWS AZs but take a different design approach. GCP typically places three zones per region, built on Google's massive global network. GCP's strength is that its zone design reflects the knowledge gained from Google's years of operating large-scale distributed systems. Globally distributed databases like Spanner are designed with inter-zone replication as a premise, providing high resilience against zone failures. On the other hand, three-zone regions are the majority on GCP, and regions where you can choose four or more zones, like AWS's Tokyo region (4 AZs), are limited. That does not mean four-zone regions do not exist, however: us-central1 has four zones. More zones give more options for distributing resources and make it easier to keep spare capacity in the remaining zones when one zone becomes unavailable. What to check at design time is not each provider's total zone count, but how many zones you can actually choose in the region you want to use, and whether you can spread capacity across them.
AZ Isolation Effectiveness Through Real-World Incident Examples
The true value of AZ design is tested when actual failures occur. AWS has experienced multiple large-scale incidents, and in most cases, AZ isolation functioned as designed. During the 2017 S3 outage (us-east-1), caused by a typo in an operational command, the impact was limited to specific subsystems, and services in other regions and AZs continued operating normally. In the 2019 us-east-1 power outage, the event was contained within a single AZ. Environments that had resources only in that AZ, however, were affected. A multi-AZ configuration is not automatically unscathed; whether you ride out the event as a single-AZ incident depends on whether the application side is configured to keep processing in the remaining AZs. AWS publishes post-event summaries for some large-scale incidents, but not for every event. Design should rest on design goals and each service's behavioral specifications, not on individual published reports. Similar events have occurred at other providers. In the August 2023 Australia East region incident, a voltage sag caused the cooling units to shut down. Microsoft's published post-incident review states that the impact was limited to a subset within one of the three availability zones. The relative degree of isolation between providers cannot be read from a single provider's incident. What serves as evidence is the design criteria each provider publishes and the operational stance of how granular their post-incident reviews are.
Best Practices for Multi-AZ Design
Even with excellent AZ isolation, applications that aren't designed for multi-AZ won't benefit from it. AWS provides abundant services and tools that make multi-AZ design easy. RDS Multi-AZ deployments automatically place primary and standby instances in different AZs with automatic failover during failures. ELB (Elastic Load Balancing) distributes traffic across the AZs you have enabled. The default for cross-zone load balancing, which spreads requests across AZs, differs by load balancer type: it is enabled by default on Application Load Balancers and disabled by default on Network Load Balancers. If you want to avoid uneven load on an NLB caused by uneven target counts, either enable this setting explicitly or place the same number of targets in each AZ. Auto Scaling groups distribute instances across multiple AZs and automatically replenish capacity in remaining AZs when a specific AZ becomes unavailable. Even with these services, however, user-side settings - "keep multiple AZs enabled" and "reserve sufficient capacity in each AZ" - are a prerequisite. If you have created a subnet in only one AZ, left the Auto Scaling group's minimum at one instance, or are using a single-AZ RDS configuration, the service-side distribution features will not work. Multi-AZ design is not about choosing supported services; it is about deliberately choosing every AZ-related setting in each service.
Low-Latency Inter-AZ Communication - Balancing Separation and Connectivity
Maintaining low communication latency between physically separated AZs is directly tied to the practicality of multi-AZ architectures. AWS connects AZs with dedicated high-bandwidth, low-latency networks, and inter-AZ round-trip latency is typically within 1-2 milliseconds. This low latency enables synchronous replication (RDS Multi-AZ, EFS) and real-time failover to operate at practical speeds. Separation and connectivity are inherently a trade-off, but AWS resolves this trade-off at a high level through investment in dedicated dark fiber networks. Data transfer between AZs incurs charges, reflecting the maintenance costs of dedicated inter-AZ network infrastructure. This cost difference compared to free intra-AZ communication needs to be understood and factored into architectural design.
Summary
AWS's AZ design has been built up since the offering began in March 2008 through the publication of physical separation design criteria, improvements informed by incidents, and the accumulation of services designed on multi-AZ assumptions. Azure made availability zones generally available in 2018, and GCP has a zone design that reflects Google's expertise in large-scale distributed systems. Side-by-side comparison is difficult because both the granularity of published design criteria and the scope of published post-incident reviews differ by provider. In cloud selection, therefore, the practical approach is not to ask whether the term "availability zone" exists, but to check individually how many zones you can actually choose in the region you want to use, how the services you use behave across zones by default, and how much of the post-incident review is published when failures occur. On top of that, what matters in the end is whether the application side is built on multi-AZ assumptions so that it can take advantage of the isolation design of the cloud you chose.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon EC2 official page
- Amazon VPC official page
- Amazon Route 53 official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.