Regions and availability zones

A region is a geographic area with its own independent data centres, such as us-east-1 in Northern Virginia. An availability zone (AZ; GCP calls it a zone) is one or more data centres inside a region, with independent power, cooling and networking. Almost every reliability decision starts from these two layers.

The big idea

Regions are deliberately isolated. An outage in us-east-1 should not take down eu-west-1. That isolation is also why moving data between regions costs money and adds latency, typically 60 to 150 ms across an ocean.

AZs sit in the middle. AWS places them far enough apart that one fire or flood is unlikely to hit two. They are still close together. The round trip between AZs is around 1 to 2 ms, which is fast enough for synchronous database replication. You can keep a standby in another building and fail over without losing committed writes.

Walking through the spare capacity

Whole-region outages are rare. Single-AZ problems happen several times a year across a large fleet. So the default rule is: every tier spans at least two AZs, preferably three, with enough capacity to lose one.

Suppose the service needs 6 instances at peak.

Spread over 3 AZs, losing one leaves 2/3 of capacity.
Required total:    6 / (2/3) = 9 instances  (3 per AZ)  -> 50% extra

Spread over 2 AZs, losing one leaves 1/2.
Required total:    6 / (1/2) = 12 instances (6 per AZ)  -> 100% extra

To survive the loss of one of n zones, you need N × n / (n − 1) capacity. Three zones are cheaper than two for the same resilience. Amazon calls this static stability: the system keeps working without launching anything new. During a real zone event, the tools you would use to launch replacements may be slow or out of capacity.

Cross-AZ traffic is not free. AWS charges about $0.01 per GB in each direction. A service that moves 50 TB a month between AZs pays roughly 50,000 GB × $0.02 = $1,000 a month for it. Keep request paths zone-local where you can.

Common mistakes

• Sizing for N with no spare. Losing a zone then overloads the survivors.
• Hidden single-AZ parts. One NAT gateway, one self-managed Redis node or one volume can take down a multi-AZ service.
• Putting the database primary and standby in one zone. Put them in different zones, with a managed multi-AZ option where possible.

Check yourself

1. You need 6 instances at peak across 3 zones. How many in total? Answer: 9, so that losing one zone still leaves 6 running.
2. Why can AZs replicate synchronously, but regions usually cannot? Answer: AZs are about 1 to 2 ms apart. Regions are 60 to 150 ms apart or more, which is too slow for every write to wait.

Key takeaways

• Regions isolate failures. AZs are close enough to replicate across synchronously.
• To survive one zone, provision N × n / (n − 1) capacity.
• Cross-AZ traffic has a cost, so keep request paths in one zone where you can.
• Add a second region only for a concrete reason.

Further learning

Next, see how the compute that runs in these zones is sized and bought: VMs, spot and autoscaling. The networking that connects them is in cloud networking and VPCs.