Cloud Regions and AZs: Infrastructure Built for Failure

WHY IT EXISTS Cloud providers need to offer infrastructure that can withstand major failures. A single data center is a massive single point of failure. The Region/AZ model was created to provide customers with a simple framework for building highly available applications that can survive the loss of an entire data center or more.

THE MENTAL MODEL Think of a cloud Region as a city, like metro London. Within that city are multiple Availability Zones (AZs), which are like independent power grids for different boroughs. A fire at the Battersea Power Station might black out one borough, but the rest of London stays online because their grids are isolated. The AZs are all part of the same city (Region) and well-connected, but they are built to fail independently.

HOW IT WORKS A Region is a specific geographic area (e.g., 'us-west-2'). Within that Region are multiple physically separate AZs (e.g., 'us-west-2a', 'us-west-2b'). Each AZ consists of one or more discrete data centers with redundant power, networking, and cooling. AZs within a region are connected with high-bandwidth, low-latency networking, but are far enough apart that a single disaster like a fire, flood, or tornado is extremely unlikely to affect more than one. You build resilient systems by running application instances in multiple AZs and using a load balancer to distribute traffic.

WHEN TO USE IT Use a multi-AZ architecture for any production system where downtime is unacceptable. This is the default for critical web applications, databases, and backend services. If you need your service to remain online during a data center outage, you must deploy it across multiple AZs.

WHEN NOT TO USE IT For development environments, temporary test servers, or non-critical batch processing, deploying to a single AZ is often sufficient and more cost-effective. If a service can tolerate several hours of downtime without major business impact, the added complexity and data transfer costs of a multi-AZ setup may not be justified.

ONE CANONICAL EXAMPLE A web application runs on servers spread across three AZs in the 'eu-west-1' region, with a load balancer in front. Its database is configured for Multi-AZ replication, with a primary instance in 'eu-west-1a' and a standby replica in 'eu-west-1b'. If a power failure takes the entire 'eu-west-1a' zone offline, the load balancer automatically stops sending traffic to the servers there, and the database automatically fails over to the standby in 'eu-west-1b'. Users experience no service interruption.