AWS Regions and Availability Zones: How to Architect Across Them

What Regions and Availability Zones Actually Are

An AWS Region is a geographic cluster of data centers — us-east-1 (Northern Virginia), eu-west-1 (Ireland), ap-southeast-1 (Singapore), and so on. Each Region is fully independent: it has its own power grid, networking backbone, and control plane.

Inside each Region are Availability Zones (AZs). An AZ is one or more discrete data centers with redundant power, cooling, and networking. AZs within a Region are connected by low-latency, high-bandwidth private links, but they're physically separated — typically tens of miles apart — so a flood, fire, or power outage that takes down one AZ won't take down another.

As of 2024, AWS has 33 launched Regions with 105 AZs. The number keeps growing, so check the AWS global infrastructure page for the current count.

The Failure Domain Hierarchy

Think in layers:

• Instance / host — a single EC2 host can fail silently
• AZ — a whole zone can become unavailable (rare, but it happens)
• Region — large-scale, multi-AZ events are extremely rare but not impossible
• Account / service limits — soft limits can throttle you even when infra is healthy

Your architecture should tolerate failures at each layer proportional to the cost and risk tolerance of your system.

Architecting Within a Region (Multi-AZ)

For most production workloads, spanning at least three AZs inside a single Region is the baseline.

Compute

Use Auto Scaling Groups with instances spread across AZs. Set balance to balanced-best-effort or use the AZRebalance process so AWS redistributes capacity when an AZ recovers.

Load Balancing

Application Load Balancers (ALBs) and Network Load Balancers (NLBs) are inherently multi-AZ. Enable cross-zone load balancing so traffic distributes evenly even if one AZ has fewer healthy instances.

Databases

• RDS Multi-AZ keeps a synchronous standby in a second AZ and fails over automatically in 60–120 seconds.
• Aurora replicates storage across three AZs by default. Aurora Global Database extends this across Regions.
• ElastiCache supports Multi-AZ replication groups — enable it.
• Avoid single-AZ RDS instances in production. It is the most common mistake we see in incident post-mortems.

Storage

S3 is already replicated across at least three AZs within a Region — you don't need to do anything special. EBS volumes are zone-local; snapshots are regional.

Architecting Across Regions (Active-Active or Active-Passive)

Cross-region is harder and more expensive. Choose it when your RTO/RPO requirements or compliance rules demand it.

Active-Passive

One Region handles all traffic; the second is a warm standby. Route 53 health checks plus failover routing records can redirect traffic within seconds of a primary-region failure. Data replication is one-way.

Steps to set up a basic active-passive failover:

1. Deploy your stack in two Regions (e.g., us-east-1 primary, us-west-2 secondary).
2. Replicate data: RDS read replicas can be promoted; DynamoDB Global Tables handle this automatically.
3. Create Route 53 health checks pointing at both regional endpoints.
4. Configure Route 53 failover routing — primary record has lower priority weight; secondary triggers when health check fails.
5. Test failover by manually failing the primary health check. Do this before you need it.

Active-Active

Both Regions serve traffic simultaneously. This eliminates failover delay but requires conflict-resolution strategies for writes. DynamoDB Global Tables uses last-writer-wins. For relational data, you'll need application-level logic or CRDTs.

Global Accelerator routes users to the nearest healthy Region using the AWS backbone, cutting latency and giving you automatic regional failover without DNS TTL delays.

Monitoring Across Regions

Your monitoring infrastructure itself is a failure domain. If your health checks run from a single Region and that Region has a networking issue, you'll either get false positives or miss real outages.

Checking from multiple geographic vantage points — something uptime monitoring services like Pingy do by design — tells you whether an outage is local to one region or global. That distinction matters when you're deciding whether to fail over.

Common Mistakes

• Single-AZ RDS in production
• Hardcoded AZ names in launch configs (AZ names like us-east-1a are account-specific aliases, not guaranteed to map to the same physical AZ across accounts)
• Forgetting NAT Gateway AZ affinity — put one per AZ or you'll pay cross-AZ data transfer fees and create a single point of failure
• Assuming S3 is global — buckets are regional; cross-region replication must be explicitly configured
• Not testing failover — runbooks rot; automated failover that has never been exercised is not reliable

Key Takeaways

• Regions are independent failure domains; AZs are isolated zones within a Region.
• Multi-AZ is the minimum for any production workload; aim for three AZs.
• Cross-region adds complexity — justify it with real RTO/RPO requirements.
• NAT Gateways, RDS, and ElastiCache all require deliberate multi-AZ configuration.
• Test your failover paths before an incident, not during one.
• Monitor from outside your own infrastructure so a regional event doesn't blind your observability layer.