What Regions and AZs Actually Are
AWS divides its infrastructure into Regions — independent geographic areas like us-east-1 (Northern Virginia) or eu-west-1 (Ireland). Each Region is completely isolated from others: it has its own power grid, networking backbone, and control plane.
Inside each Region are Availability Zones (AZs) — typically three to six physically separate data centers connected by low-latency, high-bandwidth fiber. AZs within a Region share the same Regional services (like IAM or Route 53) but are isolated enough that a fire, flood, or power failure in one should not affect the others.
The practical implication: AZ failures happen more often than full Region outages. Designing across AZs is table-stakes; designing across Regions is for stricter availability requirements.
Architecting Across Availability Zones
The Baseline: Spread Everything by Default
Most managed AWS services handle AZ distribution for you if you let them. The mistakes usually come from opting out accidentally.
- EC2 Auto Scaling Groups: specify subnets in at least three AZs. If you specify only one subnet, all instances land in one AZ.
- Application Load Balancers: enable all AZs in your VPC. ALBs only route to AZs you've explicitly activated.
- RDS Multi-AZ: turn it on. The standby isn't a read replica — it's a synchronous failover target. Without it, an AZ failure takes your database down.
- ElastiCache and OpenSearch: use cluster mode with replicas distributed across AZs.
- ECS/EKS: use spread placement constraints or pod topology spread constraints so tasks don't pile up in one AZ.
Stateless vs. Stateful Tiers
Stateless compute (web servers, API nodes) is easy — spin up instances in every AZ and let the load balancer distribute traffic. Stateful tiers (databases, caches, queues) need more thought:
- Databases: RDS Multi-AZ or Aurora with replicas across AZs. For Aurora, a Regional cluster automatically stores data across three AZs regardless of how many DB instances you run.
- Queues: SQS is inherently multi-AZ; no action needed. MSK (Kafka) requires you to configure brokers explicitly across AZs.
- Object storage: S3 redundantly stores objects across a minimum of three AZs automatically — you don't need to do anything extra.
Watch for AZ-Affinity Bugs
A common failure pattern: your compute is spread across AZs but your database or cache is in one AZ. Under normal load this is invisible. When that AZ degrades, latency spikes or connections time out even though your instances are "healthy."
Audit your architecture for cross-AZ dependencies — places where a request originating in AZ-A must talk to a resource pinned to AZ-B. These are hidden single points of failure.
When to Go Multi-Region
Multi-Region adds significant operational complexity. It makes sense when:
- Your RTO (Recovery Time Objective) is measured in seconds or low minutes, not tens of minutes
- Regulations require data residency in specific geographies
- You serve users across continents and latency to a single Region is noticeable
- A Regional AWS control-plane incident (rare but real) would be unacceptable
Common Multi-Region Patterns
Active-passive (pilot light / warm standby): Your primary Region handles all traffic. A secondary Region runs a scaled-down copy, continuously fed via database replication (DynamoDB Global Tables, Aurora Global Database, or S3 Cross-Region Replication). On failure, you promote the secondary and update DNS.
Active-active: Traffic runs in multiple Regions simultaneously. Requires a globally consistent or eventually consistent data layer — DynamoDB Global Tables is the most common choice. Conflict resolution logic becomes your problem.
DNS and Failover
Route 53 health checks combined with failover or latency-based routing are the standard mechanism for directing traffic during a Regional incident. Set your TTLs low (60 seconds) on records you intend to fail over — a 300-second TTL means five minutes of continued bad routing after you've already flipped DNS.
Monitoring Across Regions
Your monitoring should not live in the same Region as what it's watching. If us-east-1 has a networking issue, a health check running inside us-east-1 may not detect it — or may itself be impaired.
External uptime monitoring from multiple geographic vantage points (which is what a service like Pingy does) gives you a view of your application that's independent of your infrastructure's health. It's one of the few places where the monitoring and the monitored thing genuinely need to be decoupled.
Key Takeaways
- AZ failures are more common than Region failures — spread across AZs first.
- Managed services do the work only if you configure them correctly; check your subnet and AZ settings.
- Cross-AZ dependencies (compute in multiple AZs, database in one) are hidden single points of failure.
- Multi-Region is the right answer for strict RTOs, compliance, or global users — not for every workload.
- Keep Route 53 TTLs low on records you plan to fail over.
- Run your monitoring outside the infrastructure it's watching.