Every cloud resource lives somewhere physical. Providers group their data centers into regions and, inside each region, into Availability Zones (AZs). These boundaries decide what fails together, how far your data travels, and which laws apply to it. Placing resources well across them is the first step toward a system that survives a data center outage.
Regions#
A region is a separate geographic area where a provider runs its infrastructure, such as us-east-1 (Northern Virginia) on AWS or europe-west1 (Belgium) on Google Cloud. Regions are spread around the world and are isolated from one another.
Every resource you create belongs to a region, so picking one is usually your first decision. Four things drive the choice.
- Latency: put resources close to your users.
- Compliance and data residency: some laws require data to stay in a country or area.
- Service availability: new services and instance types do not reach every region at once.
- Cost: prices differ between regions.
Availability Zones#
A region on its own is still a big target for failure, so providers split each one further. An Availability Zone is an isolated location inside a region. On AWS, each AZ is one or more discrete data centers with their own redundant power, networking and cooling. On Google Cloud the same idea is called a zone, named like us-central1-a.
- AZs in a region are physically separated, so a fire, flood or power failure in one should not reach another.
- They are linked by high-bandwidth, low-latency private networking, so synchronous replication between them is practical.
- A region has several AZs. AWS names them by adding a letter to the region, such as
us-east-1a.
One catch with those letter names: AWS maps AZ names to physical zones separately for each account. Your us-east-1a may be a different zone from another account's us-east-1a. Use AZ IDs (such as use1-az1) when you coordinate placement across accounts.
Fault isolation#
The point of all this structure is to contain failures. Regions and AZs are fault isolation boundaries, and each level protects against a bigger kind of failure.
| Deploy across | Survives | Costs |
|---|---|---|
| One AZ | A single server or rack failure (with several instances) | Lowest; one zone outage takes you down |
| Several AZs in one region | Loss of a whole data center | Some inter-AZ data transfer charges and a little latency |
| Several regions | Loss of a whole region (major disaster or regional outage) | Much more complexity: data replication, routing, consistency |
Multi-AZ is the normal baseline for production. Multi-region is a bigger step, usually taken for strict availability targets, disaster recovery or global latency. The regionalization and latency note covers multi-region design, CDNs and regional partitioning.
Zonal, regional and global services#
Knowing the boundaries only helps if you know which side of them each service sits on. Every service has a scope, and the scope tells you what a zone or region failure takes with it.
| Scope | Lives in | AWS examples |
|---|---|---|
| Zonal | One AZ | EC2 instance, EBS volume, subnet |
| Regional | Spread across AZs in one region | VPC, S3 bucket, DynamoDB table, SQS queue, Lambda function, Application Load Balancer, auto scaling group |
| Global | Not tied to one region | IAM, Route 53, CloudFront |
A few rules follow from the scope.
- A subnet lives in exactly one AZ. An AZ can hold many subnets. A VPC spans every AZ in its region.
- An EBS volume attaches only to instances in its own AZ. To move data to another AZ, take a snapshot and create a new volume from it.
- An auto scaling group can span several AZs, but not several regions.
- A regional service such as S3 Standard already stores data across several AZs. To survive a region outage, you must replicate to another region yourself.
- A load balancer works inside one region. Route traffic between regions with DNS (for example Route 53 latency or failover routing) or a global service such as AWS Global Accelerator.
Designing across AZs#
Here's how the scope rules and the multi-AZ baseline come together in practice. A standard multi-AZ web stack puts a copy of each tier in at least two AZs, behind a regional load balancer.
- Create one VPC in the region.
- Create a public and a private subnet in each AZ you use.
- Run app instances in an auto scaling group that spans those AZs.
- Put a load balancer in front, enabled in the same AZs. Its health checks skip failed instances.
- Run the database with a standby in a second AZ (for example Amazon RDS Multi-AZ), so it can fail over automatically.
If one AZ fails, the load balancer stops sending it traffic, the auto scaling group launches replacements in the healthy AZs, and the database fails over to its standby. The load balancing note explains health checks and routing.
Pitfalls#
Even with that layout, multi-AZ designs fail in a few predictable ways.
- Hidden single-AZ parts. One NAT gateway, one cache node or one database instance in a single AZ undoes the rest of the design.
- No spare capacity. With two AZs, each must handle full load if the other fails. Plan for losing one AZ and still serving traffic.
- Chatty cross-AZ traffic. Data transfer between AZs is usually billed and adds a little latency. Keep heavy internal traffic within an AZ where you can.
- Untested failover. A failover you have never triggered may not work. Test it on purpose.
Key takeaways#
- A region is a geographic area. An AZ is one or more isolated data centers inside it.
- Pick a region for latency, compliance, service availability and cost.
- Services are zonal, regional or global, and the scope decides what one failure takes down.
- A subnet lives in one AZ; an AZ can hold many subnets; a VPC spans the region.
- Run production across at least two AZs, with no single-AZ component left behind.
- Load balancers and auto scaling groups stay inside one region. Cross-region needs DNS routing and data replication.