Resilience Patterns · Resilient Data and Dependencies
Multi-AZ, Multi-Region and Failover
Redundancy across failure domains and how failover really works.
Spread instances across availability zones by default (independent power/network within a region). Multi-region protects against regional outages but adds data replication, consistency and cost challenges. Patterns: active-passive (warm standby, failover on disaster — RPO/RTO depend on replication lag and automation), active-active (traffic served in several regions; data model must handle multi-region writes), and cell-based architectures limiting blast radius. Test failover regularly; untested failover usually fails.
Redundancy patterns (RTO = time to recover, RPO = data loss window)
| Pattern | RTO | RPO | Cost / complexity |
|---|---|---|---|
| Single AZ | Hours (AZ outage) | Varies | Lowest |
| Multi-AZ (default) | Seconds–minutes | ~0 (sync replication) | Low |
| Multi-region active-passive | Minutes–hours | Seconds–minutes (async) | Medium |
| Multi-region active-active | ~0 for reads; writes depend on design | ~0–seconds | High |
| Cells | Limits blast radius | Per cell | Medium–high |
Common pitfalls
- Failover runbooks never exercised.
- Hidden single-region dependencies (auth, DNS, secrets, CI).
- Active-active writes without conflict handling.
Key points
- Multi-AZ by default
- Multi-region by RTO/RPO needs
- Test failover regularly
Further reading: AWS Well-Architected: Reliability pillar
Practice questions
What do RTO and RPO mean?
Answer
Recovery Time Objective: how long until service is restored. Recovery Point Objective: how much data (time window) you can afford to lose.
Why do untested failovers often fail?
Answer
Hidden dependencies on the failed region, stale configuration, insufficient capacity in the standby, and manual steps nobody has practiced.
Open in the app to mark lessons complete, take notes and track your progress.