awsEvery AWS resilience conversation eventually reaches the same fork: Multi-AZ or multi-region? The honest answer is unfashionable - most teams should do Multi-AZ excellently before spending a dollar on a second region. But "most teams" is not "your team," and the difference is a calculation, not a vibe. Here is the framework.
What Multi-AZ actually protects
Availability Zones are physically separate data-center clusters inside a region with independent power, cooling, and networking. Multi-AZ architecture (instances in ≥2 AZs behind a load balancer, RDS Multi-AZ, zone-redundant everything) protects you from the most common serious failure: losing one facility. AZ-level events - a power issue, a flooded data hall, a network device failure like the Sydney EC2 event - happen far more often than regional ones, and Multi-AZ turns them from outages into blips.
What it does not protect: anything that fails at the region scope. The 2017 S3 outage took S3's regional index down for every AZ at once. The December 2021 event congested the region's internal network. The October 2025 DynamoDB DNS failure emptied one DNS record and every AZ lost the endpoint together. Control planes, regional service subsystems, and DNS are shared across AZs - that whole failure class passes through Multi-AZ untouched.
What only multi-region buys you
A second region gives you an independent control plane, independent service subsystems, and independent failure modes. It is the only architecture that would have kept you fully serving through the three incidents above. It also buys survivable operator access (regional STS/console endpoints) and - often overlooked - negotiating leverage: your RTO no longer depends on AWS's recovery time.
The costs are real and mostly not infrastructure: data replication (with its consistency trade-offs), keeping two environments deployable, DNS failover you actually trust, and the discipline to test the failover path quarterly. An untested standby region is theater.
The four strategies, priced
| Strategy | What runs in region 2 | Typical added cost | Realistic RTO |
|---|---|---|---|
| Backup & restore | Nothing - backups only | ~5–10% | Hours–days |
| Pilot light | Data replicated; minimal core services | ~10–30% | Tens of minutes–hours |
| Warm standby | Scaled-down full stack | ~30–60% | Minutes–tens of minutes |
| Active-active | Full stack serving traffic | ~90–100%+ | Seconds–minutes |
Move down the table only when the row above provably fails your RTO/RPO numbers - which means you need RTO/RPO numbers first (the DR checklist forces this in step 2).
The decision framework
Work through these in order; stop at the first "no":
- Is your Multi-AZ story actually finished? Zone-redundant data stores, no single-AZ singletons, load-shedding, tested AZ evacuation. If not, a second region multiplies a fragile architecture.
- Does an hour of downtime cost more than ~$10–50k? Below that, the engineering payroll for real multi-region rarely pays back; buy better backups and alerting instead (start with outage alerts).
- Do compliance or contracts require geographic redundancy? If yes, the decision is made - pick the cheapest strategy that satisfies the auditor and your RTO.
- Can your data layer replicate acceptably? Cross-region consistency is the hard part: DynamoDB Global Tables and Aurora Global Database make it tractable; a write-heavy Postgres with strict consistency does not.
- Will you test failover at least quarterly? If the honest answer is no, buy pilot light, not active-active - the gap between designed and demonstrated recovery is where outages live.
The us-east-1 special case
If you run in us-east-1, weight the calculation harder toward multi-region: it is AWS's oldest, largest region, hosts several global control-plane dependencies, and has the deepest incident history - three of the four worst AWS outages of the past decade were us-east-1 events. Running your second region as the primary and us-east-1 as the standby is an increasingly popular hedge.