AWS Reliability Design
The artilce is organised into four best-practice areas, plus definitions and design principles up front. Current edition is dated November 6, 2024.
1. Foundations
Things that must be right before anything else, and are often outside a single project’s scope.
- Service quotas and constraints — knowing your limits, monitoring headroom, requesting increases before you need them, accounting for quotas across accounts and regions
- Network topology — IP address planning that leaves room to grow, connectivity between VPCs and on-premises, redundant paths, avoiding overlapping CIDR ranges you can’t undo later
2. Workload architecture
How the software itself is structured.
- Service architecture — service-oriented or microservices, bounded contexts, keeping services independently deployable
- Preventing failures in distributed systems — idempotency, constant work, avoiding tight coupling, designing for eventual consistency
- Withstanding failures — graceful degradation, throttling, retries with exponential backoff and jitter, circuit breakers, timeouts, fail-fast behaviour
3. Change management
Anticipating and absorbing change, whether it comes from demand or from you.
- Monitoring — metrics, logs, traces, alarms tied to what users experience rather than to CPU
- Adapting to demand — Auto Scaling, load balancing, provisioning ahead of predictable spikes. This is where your termination-policy question lives.
- Implementing change — immutable infrastructure, canary and blue/green deployments, automated rollback, infrastructure as code
4. Failure management
The largest section, and the one most people skip.
- Backing up data — identifying what needs it, automating it, encrypting it, and periodically restoring to prove it works
- Fault isolation — multi-AZ and multi-region, bulkhead and cell-based architectures, shuffle sharding, blast-radius containment
- Withstanding component failures — health checks, automatic replacement, static stability (surviving a failure without needing a control-plane action), redundancy
- Testing reliability — game days, fault injection, chaos engineering, testing recovery paths rather than only happy paths
- Disaster recovery — RTO and RPO targets, and the four documented strategies: backup and restore, pilot light, warm standby, multi-site active/active
Also in the front matter
Availability targets — what each additional nine actually costs, and the arithmetic of hard dependencies multiplying downtime. Two 99.9% components in series give you 99.8%, and that compounding is why the paper pushes so hard on removing hard dependencies.
Get Srilalitha Vishnubhotla’s stories in your inbox
Join Medium for free to get updates from this writer.
The five design principles — recover automatically, test recovery, scale horizontally, stop guessing capacity, manage change through automation.
For the certification domain specifically, weight your time on Failure management and Change management. Multi-AZ versus multi-region, RTO/RPO trade-offs, and the four DR strategies account for a large share of Design Resilient Architectures questions.
Core concepts for these pillars
The four best-practice areas, and how they split:
And the four disaster-recovery strategies:
The two diagrams cover different halves of the pillar, and they’re worth reading against each other.
The first splits on a useful line. Foundations and workload architecture are decisions you make once, mostly before launch — quotas, IP ranges, service boundaries, retry behaviour. Change management and failure management are ongoing disciplines. That’s why the second pair is where most real incidents originate: the first pair is done and forgotten, the second pair needs continuous attention.
The second diagram is the one to memorise. Backup and restore, pilot light, warm standby, multi-site active/active — in that order, cheap-and-slow to expensive-and-fast. Exam questions almost always give you a stated RTO or RPO and ask which strategy fits, and the mapping is direct: hours → backup and restore, tens of minutes → pilot light, minutes → warm standby, near-zero → active/active.
The distinction people mix up: RTO is how long you’re down, RPO is how much data you lose. A system can have an excellent RTO and a terrible RPO — fail over in thirty seconds to a replica that’s an hour stale.
Where your Auto Scaling question fits: change management, under adapting to demand. And the reason zone balance outranks age in the termination policy connects to failure management — fault isolation only works if the isolation survives scale-in.
Two things not in either diagram that are worth knowing for the same domain: static stability, meaning the system survives a failure without needing a control-plane action to recover, and cell-based architecture, where you partition into independent cells so a failure takes out one cell rather than the fleet. Both appear under failure management, and both are increasingly common in exam scenarios.
This is the topic to follow next!
