dr aws reliability claude-curated
The two numbers that anchor every disaster recovery conversation. They translate vague phrases like “we need to be resilient” into measurable targets that you can architect against and test.
Definitions
- RPO (Recovery Point Objective) — the maximum acceptable amount of data loss, measured in time. “We can lose at most 1 hour of data” means RPO = 1 hour. It defines how often you must capture state.
- RTO (Recovery Time Objective) — the maximum acceptable downtime. “We must be back online within 4 hours” means RTO = 4 hours. It defines how fast you must recover.
A useful way to remember: RPO looks backward from the failure (how much do we lose?), RTO looks forward from the failure (how long until we’re back?).
Setting them
RPO and RTO are business-driven, not engineering-driven. Engineering implements them; the business owns them. They typically vary by system tier:
| Tier | Example | Typical RPO | Typical RTO |
|---|---|---|---|
| Tier 0 — critical revenue path | Payments, checkout | seconds | minutes |
| Tier 1 — customer-facing | Main app, auth | minutes | < 1 hour |
| Tier 2 — internal but important | Reporting, admin tools | hours | hours |
| Tier 3 — batch / non-urgent | Analytics, archival | 24 hours | 24+ hours |
If every system claims Tier 0, none of them are. The exercise of forcing tiers exposes hidden assumptions about what really matters.
The cost curve
Tighter targets cost more, and the cost curve is non-linear. Halving RPO often roughly doubles cost because you move from snapshots to continuous replication, then from single-region replication to cross-region, then to multi-region active-active.
Cost
│ ╱ active-active
│ ╱
│ ╱ warm standby
│ ╱ pilot light
│ ──── backup & restore
└──────────────────────── Tightness (RPO/RTO ↓)
Spending more than the impact of an outage is a failure of design, not a virtue.
Categories of failure
Different failure modes have different natural RPO/RTO and demand different defences:
- Single instance — hardware failure, OOM, kernel panic. Multi-AZ deployment + auto-restart. RTO seconds, RPO zero.
- Availability Zone — power, network, datacentre event. Multi-AZ resources. RTO minutes, RPO zero with sync replication.
- Region — rare, but real (control plane outages, fibre cuts, large-scale events). Cross-region replication. RTO minutes to hours, RPO seconds to minutes.
- Account compromise — credentials leaked, malicious insider. Backups in a separate account with vault lock. RTO hours, RPO depends on backup cadence.
- Ransomware / data corruption — application or attacker writes garbage that replicates everywhere. Immutable backups, point-in-time restore. RTO hours to days, RPO depends on detection time.
- Human error — accidental delete, bad migration. Versioning, soft-delete, PITR. RTO minutes to hours, RPO near-zero with PITR.
A common mistake is designing for region failure (rare) while leaving human error (common) wide open. See Multi-Failure Defence Patterns for layered defence design.
DR strategies (AWS terminology)
AWS frames four strategies, ordered cheapest/slowest to most expensive/fastest:
| Strategy | RPO | RTO | What it is |
|---|---|---|---|
| Backup & Restore | hours | hours–days | Backups in another region. Restore on demand. No infra running. |
| Pilot Light | minutes | tens of minutes | Core data replicated and idle services pre-provisioned. Scale up on failover. |
| Warm Standby | seconds | minutes | Scaled-down full copy running in DR region. Scale up on failover. |
| Multi-Site Active/Active | ~zero | ~zero | Full capacity in multiple regions, traffic split live. |
Mapping strategies to targets
- RPO 24h, RTO 24h → Backup & Restore is sufficient and cheapest.
- RPO 1h, RTO 4h → Pilot Light, with cross-region replication for stateful services.
- RPO minutes, RTO minutes → Warm Standby with Route 53 failover.
- RPO ~0, RTO ~0 → Active-active, multi-region writes (DynamoDB Global Tables, Aurora Global Database with managed failover).
The strategy is a target, not a label. You need to test that the architecture actually meets the numbers — most teams discover their RTO is 3x what they assumed the first time they run a real drill.
Common pitfalls
- Setting RPO/RTO without business sign-off, then under-investing or over-investing.
- Treating RPO/RTO as static. They drift as the product changes; revisit annually.
- Not testing — an estimated RTO is a guess until proven.
- Forgetting that DNS TTLs, certificate renewals, and third-party dependencies all eat into RTO.
- Calculating RPO from backup start time instead of completion time. A 2-hour backup taken every 4 hours has RPO closer to 6 hours.
See also
- Disaster Recovery Concept
- AWS Backup vs PITR
- Cross-Region Replication
- Multi-Failure Defence Patterns