Availability Zone

A cloud region is a geographic area, like AWS us-east-1 in Northern Virginia or Azure West Europe in the Netherlands. Inside that region the provider builds several isolated failure domains, and each one is an availability zone. AWS regions typically have three to six AZs. Each AZ is one or more buildings spaced a few kilometers apart from the others in the region.

The whole point of the separation is independence. Each AZ has its own utility power feed plus backup generators, its own cooling, and its own network links. A fire, a flood, a power substation failure, or a switch meltdown in one AZ is engineered to have no effect on the others. They are close enough that a fiber round trip between them stays in the single-digit millisecond range, but far enough that one physical disaster does not take out two of them.

An AZ is not the same as a region and not the same as a single rack or server. It sits in the middle: bigger than a rack, smaller than a region. When you launch a virtual machine, a managed database, or a disk volume, the provider places it in a specific AZ, and you usually get to choose which one or let the provider spread your resources for you.

You make your system resilient by running redundant copies in different AZs and putting a load balancer in front of them. AWS Application Load Balancers, Azure Load Balancers, and Google Cloud load balancers are themselves zone-redundant, so they keep routing traffic to healthy zones when one goes dark. If AZ-a fails, the balancer health checks notice within seconds and send all traffic to the instances still running in AZ-b and AZ-c.

For databases the pattern is a primary in one AZ and a synchronous standby in another. Amazon RDS Multi-AZ keeps a hot standby replica in a second zone and replicates every write to it before acknowledging the commit. If the primary AZ dies, RDS flips the DNS record to the standby, typically completing failover in 60 to 120 seconds with no data loss. Aurora goes further and stores six copies of your data across three AZs.

Inter-AZ latency is low but not zero, usually well under 2 ms within a region. That is small enough for synchronous replication of most databases, which is why multi-AZ gives you strong durability without the consistency headaches of replicating across regions thousands of kilometers apart.

Spreading across AZs is the baseline for any production workload that needs to survive a data center outage. It costs you redundant compute and storage plus inter-AZ data transfer fees, which on AWS run about 1 to 2 cents per GB in each direction. For a chatty microservice that shuffles a lot of traffic between zones, that bill adds up, so teams often pin tightly coupled, high-throughput services to the same AZ and only go multi-AZ at the boundaries that matter.

Multi-AZ protects against a single facility failure but not against a whole-region failure or a bad software deploy that you push to every zone at once. The famous AWS outages, like the us-east-1 events in 2020 and 2021, took down control planes that spanned the entire region, so multi-AZ alone did not save everyone. For protection against losing a whole region you need multi-region, which is far more expensive and forces you to deal with cross-region latency of 50 to 150 ms.

A common mistake is assuming the provider spreads things for you. It often does not. If you launch three instances and they all land in AZ-a, one zone failure wipes out all three. You have to explicitly request placement across zones or use an auto scaling group configured with multiple subnets.