Regions, AZs & Global Infrastructure

1. What Is It?

AWS operates a global network of physical data centers organized into a two-level hierarchy: Regions and Availability Zones (AZs). A Region is an independent geographic area (e.g., us-east-1 in Northern Virginia, eu-west-1 in Ireland) containing multiple isolated data centers. Each data center cluster within a Region is called an Availability Zone.

Without this structure, running a globally available, fault-tolerant backend would mean either building your own data centers or accepting that a single hardware failure could take your entire service offline. AWS's infrastructure model lets you distribute workloads geographically using APIs — no physical hardware to manage.

2. How It Works

Regions

A Region is a fully independent AWS deployment. Regions do not share compute, storage, or networking resources by default. Each Region has its own endpoint (e.g., s3.us-east-1.amazonaws.com).

You choose a Region explicitly when:

• Creating any resource (EC2 instance, S3 bucket, RDS database)
• Configuring your AWS CLI (aws configure)
• Writing infrastructure-as-code (e.g., Terraform provider "aws" { region = "us-east-1" })

As of 2025, AWS operates 36+ Regions globally.

Availability Zones

Each Region contains 2–6 AZs (most have 3). An AZ is one or more discrete data centers with independent power, cooling, and networking. They're physically separated by meaningful distance (typically miles apart) but connected by low-latency, high-bandwidth private fiber.

AZ names follow the pattern <region><letter>: us-east-1a, us-east-1b, us-east-1c.

Important: The physical AZ behind us-east-1a differs per AWS account. AWS shuffles the mapping deliberately to prevent all customers from overloading the same physical datacenter. Never use AZ names to coordinate between accounts.

Multi-AZ Deployment (the standard pattern)

-+ResetFullscreen

If us-east-1a loses power, the load balancer stops routing to that AZ's instances. RDS promotes its standby in us-east-1b. Traffic continues within seconds.

Edge Locations & CloudFront

AWS also has 400+ Edge Locations (Points of Presence) worldwide. These are not full Regions — they only run AWS CloudFront (CDN) and Route 53 (DNS). They cache content close to end users but cannot run compute or stateful workloads.

3. What Backend Engineers Actually Need to Know

Region selection affects:

• Latency — pick the Region closest to your users or your dependencies (e.g., a database you can't move)
• Data residency — regulatory requirements (GDPR, HIPAA) often require data to stay in specific regions; data does NOT leave a Region unless you explicitly replicate it
• Service availability — not all AWS services are available in all Regions; newer services often launch in us-east-1 first

Common misunderstandings:

• "Multi-AZ means my service is in multiple regions." — No. Multi-AZ is within a single Region. Cross-region replication is a separate, explicit configuration.
• "Deploying to multiple AZs doubles my cost." — Roughly, yes — but a single-AZ deployment is not production-grade for any service requiring >99.9% uptime.
• "If the Region goes down, I'm done." — A full Region outage is extremely rare (the 2021 us-east-1 partial outage affected only specific services and AZs). Most "outages" are AZ-level, which Multi-AZ handles.

What you actually configure day-to-day:

• Resources deployed to a specific AZ: EC2 instances, EBS volumes, ElastiCache nodes
• Resources that span AZs automatically: Application Load Balancers, RDS Multi-AZ, S3
• Global resources (no region): IAM, Route 53, CloudFront distributions

4. Tradeoffs & Decisions

Single-AZ vs. Multi-AZ:

• Single-AZ is cheaper and simpler. Use it for dev/test, batch jobs, or stateless ephemeral workloads where downtime is acceptable.
• Multi-AZ is required for any production service with an SLA. The cost is roughly 2x for stateful resources (databases, cache), but stateless compute (behind a load balancer) already spans AZs naturally.

Single-Region vs. Multi-Region:

• Multi-Region is rarely necessary and expensive to operate. You need it for: global active-active serving (sub-50ms worldwide), strict regulatory isolation, or disaster recovery with RTO < 1 minute.
• If you see a requirement like "the service must survive a full Region failure," you're looking at multi-region with Route 53 health-check-based failover or a global load balancer. This requires replicating data across regions (eventually consistent) and handling split-brain scenarios.

If you see X, it usually means Y:

• "We need 99.99% uptime" → Multi-AZ for all stateful services, at minimum.
• "We have EU users who can't have their data leave Europe" → Deploy to eu-west-1 or eu-central-1, do not enable cross-region replication.
• "Latency to Asia is too high" → Add a Region in ap-southeast-1 (Singapore) or ap-northeast-1 (Tokyo) with a CDN in front.

5. Interview Cheat Sheet

Key sentences:

1. "A Region is a fully isolated geographic deployment; an AZ is a physically separate data center cluster within that region connected by low-latency private fiber."
2. "Multi-AZ protects against hardware and datacenter-level failures; multi-region protects against full regional outages and supports global low-latency serving."
3. "Data doesn't leave a Region unless you explicitly configure cross-region replication — this is the mechanism behind GDPR data residency compliance on AWS."
4. "S3 and ALBs are inherently multi-AZ within a region; EC2 and EBS are tied to a single AZ and require you to design HA manually."

Common follow-ups:

Q: If I deploy an EC2 instance in us-east-1a and that AZ fails, what happens? A: The instance goes down. EC2 instances are AZ-scoped. To survive AZ failure you need multiple instances in different AZs behind a load balancer, managed by an Auto Scaling Group with a multi-AZ subnet configuration.

Q: What's the difference between an Edge Location and an AZ? A: AZs run the full AWS compute and storage stack. Edge Locations only run CloudFront (CDN) and Route 53 (DNS) — they cache content and resolve DNS close to users but cannot host databases, EC2, or application logic.

Q: How does AWS decide which physical data center maps to "us-east-1a" in my account? A: AWS randomizes the mapping per account to distribute load across physical AZs. The AZ name us-east-1a in your account may point to a different building than us-east-1a in another account. Never use AZ names to coordinate placement between accounts — use AZ IDs (e.g., use1-az1) instead, which are stable across accounts.