Availability Zones

In 2017, a single Amazon S3 outage in us-east-1 took down a significant portion of the internet, including Slack, Trello, Quora, and parts of AWS's own dashboard. The root cause was a typo in a command that took down more servers than intended in one location.

If your entire application runs in a single data center and that data center has a power failure, a network cut, a cooling system malfunction, or a human error, your application goes down. 100% downtime. No fallback.

Availability Zones (AZs) solve this by giving you multiple physically separated data centers within the same region. Each AZ has independent power supplies, cooling, and networking. They're connected by high-bandwidth, low-latency links (typically <2ms). When one AZ fails, your application continues running in the others.

Spreading across AZs is the minimum viable high availability strategy. It's so fundamental that cloud architects consider a single-AZ deployment to be a design flaw, not a design choice.

Physical separation: Each AZ consists of one or more data centers in physically distinct locations, different buildings, different power substations, different flood plains. A fire, flood, or power outage that affects AZ-a should not affect AZ-b.

Network connection: AZs within a region are connected by dedicated, high-bandwidth fiber. Latency between AZs is typically 1-2ms, fast enough for synchronous replication.

AZ naming quirk: AZ names are randomized per account. Your us-east-1a might map to a different physical data center than another account's us-east-1a. AWS does this to prevent everyone from packing into the "first" AZ. Use AZ IDs (like use1-az1) for cross-account coordination.

What multi-AZ means in practice: Run at least 2 instances of every critical service, each in a different AZ. Put a load balancer in front. If one AZ goes down, the load balancer routes all traffic to the surviving instances.