Resilience & DR¶

Every dial on this page turns on the same trade: how much of the recovery environment you keep running before disaster strikes, in exchange for how little RTO and RPO you're left paying for after it does. The four DR strategies are just four settings on that dial; Multi-AZ and cross-region replicas are the same dial applied one scope down; and backups are the mechanism that has to actually work for any setting on that dial to deliver on its promise.

Scope: the AWS module page named RTO/RPO as the two numbers every resilience conversation reduces to, and listed the four DR strategies as a straight cost/speed dial — backup & restore → pilot light → warm standby → multi-site. This page goes one layer deeper: what RTO/RPO actually measure on a timeline, what standing infrastructure each DR strategy keeps running (and why that's what drives its cost), how the Multi-AZ/read-replica material from the storage page maps onto this same ladder, and the backup mechanisms — snapshots and point-in-time recovery — that make any of it possible.

TL;DR — in 30 seconds:

RTO and RPO are two independent dials measuring the same outage in opposite directions — RPO (backward: how much data you'd lose) and RTO (forward: how long you're down) — a strategy can be tight on one and loose on the other.
The four DR strategies are a cost/speed dial, not a maturity ladder: Backup & Restore (nothing runs) → Pilot Light (core data services idle) → Warm Standby (full stack, scaled down) → Multi-Site Active/ Active (full stack, live) — moving down buys tighter RTO/RPO at higher standing cost.
Multi-AZ and read replicas are this same ladder one scope down: Multi-AZ is a same-region warm standby (automatic failover); a cross-region read replica's promotion is a pilot-light- or warm-standby-style manual failover.

1. RTO and RPO — two different questions about the same outage¶

An outage forces two separate questions, and conflating them is the most common DR mistake:

RPO (Recovery Point Objective) — how much data can you afford to lose? It's measured backward from the moment of failure to your last durable copy.
RTO (Recovery Time Objective) — how long can you afford to be down? It's measured forward from the moment of failure to the moment service is restored.

flowchart LR
    LastBackup["Last durable<br/>copy taken"] -->|"RPO — data<br/>you could lose"| Failure["Failure<br/>happens"]
    Failure -->|"RTO — time<br/>until restored"| Restored["Service<br/>restored"]

They're independent dials. A strategy can have a tight RPO (you replicate continuously, so you'd lose almost nothing) but a loose RTO (nobody has actually rehearsed standing the failed-over environment back up, so it takes hours to get traffic flowing again) — or the reverse. The four DR strategies below are really four different answers to "how much do I pre-pay, in standing infrastructure, to pull both dials tighter."

2. The four DR strategies — what's actually running while nothing is wrong¶

Each strategy is defined by how much of the recovery environment already exists, and is already running, before the disaster happens:

flowchart LR
    BR["Backup & Restore<br/>(nothing runs — only backups exist)"] --> PL["Pilot Light<br/>(core services idle, minimally sized)"]
    PL --> WS["Warm Standby<br/>(full stack runs, scaled down)"]
    WS --> MS["Multi-Site Active/Active<br/>(full stack runs, full scale, serving traffic)"]

Backup & Restore — the only thing that exists ahead of time is the backup itself. Recovering means provisioning infrastructure from scratch (or from an IaC template) and restoring data into it. Cheapest to maintain, slowest and least precise to recover from.
Pilot Light — the core, hard-to-recreate-quickly pieces (typically the database) run continuously in a minimal, low-cost form in the recovery region; everything else (compute, load balancers) is defined but not running, and gets scaled up only during a failover.
Warm Standby — a scaled-down but fully functional copy of the whole stack runs continuously in the recovery region. Failover means scaling it up to full capacity and redirecting traffic, not building it.
Multi-Site Active/Active — a full-scale copy runs continuously in more than one region and is already serving live traffic. "Failover" is really just routing more traffic to the sites that remain, since there's no distinction between "standby" and "production."

Strategy	What's running beforehand	Relative RTO	Relative RPO	Relative cost
Backup & Restore	nothing — only backups	highest (hours+)	highest	lowest
Pilot Light	core data services only, minimally sized	high	moderate	low
Warm Standby	full stack, scaled down	low	low	moderate–high
Multi-Site Active/Active	full stack, full scale, live	lowest (near-zero)	lowest (near-zero)	highest

Moving down this ladder buys a tighter RTO and RPO by keeping more infrastructure warm (or hot) at all times — it is a cost dial, not a maturity ladder: a workload that can tolerate an hour of downtime has no business paying for multi-site active/active.

3. Where Multi-AZ and read replicas sit on this same ladder¶

The storage page's database rule — Multi-AZ is a synchronous standby for automatic failover; read replicas are asynchronous and exist for read scaling — is this exact ladder, one region down:

A Multi-AZ database is a same-region warm standby: a synchronous copy is always running, and failover is automatic and fast. It answers "an AZ went down," not "a region went down."
A cross-region read replica (asynchronous) can be promoted to a standalone primary during a regional outage — that promotion is a pilot-light- or warm-standby-style failover, depending on how much compute you keep running alongside it in that region.
Multi-Region active/active setups extend the same idea to the entire stack, not just the database — which is exactly the multi-site strategy in §2.

The pattern repeats at every scope: decide what failure domain you're protecting against (AZ vs region), then pick how much of the recovery side you're willing to keep warm for it.

4. Backups — the mechanism that makes any of this possible¶

Every strategy above still depends on backups actually existing and actually being restorable:

Snapshots (EBS, RDS) are typically incremental after the first one — only the blocks that changed since the last snapshot are copied, which is what makes frequent snapshotting affordable.
Point-in-time recovery (RDS/Aurora) goes beyond periodic snapshots: the database continuously ships its transaction log to durable storage, so you can restore to any second within the retention window, not just to the moment of the last snapshot. This is what lets RPO shrink well below "however often we remembered to snapshot." (Go deeper: the RDS point-in-time recovery guide — optional, not required to defend this page.)
Cross-region copies of snapshots or backups are what turn a same-region backup into something a pilot-light or warm-standby strategy in another region can actually restore from — a backup that only exists in the region that just went down protects against nothing.

A restore is only as good as the last time it was tested — a backup strategy nobody has practiced restoring from is really an untested hypothesis about RTO, not a number you can defend.

5. How this connects¶

This extends the AWS module page's Resilience theme (RTO/RPO framing the DR conversation, the four strategies as a cost/speed dial) with what each dial point actually keeps running, how the storage page's Multi-AZ/read-replica material is the same ladder at AZ-vs-region scope, and the snapshot/point-in-time mechanisms that make any recovery target achievable in the first place.
The Prove gate's DR question — what's your move if an entire AZ goes down, versus your broader DR plan — draws directly on §3's AZ-vs-region distinction and the cost/RTO table in §2.

Common gotchas

Picking multi-site active/active because it has the best RTO/RPO. Fix: it's also the most expensive point on the dial — a workload that can tolerate an hour of downtime has no business paying for continuously-running, full-scale infrastructure in multiple regions.
Treating a backup strategy as proven because backups exist. Fix: a backup nobody has practiced restoring from is an untested hypothesis about RTO, not a number you can defend — the restore has to actually be rehearsed.
Assuming a same-region backup protects against a regional outage. Fix: a backup that only exists in the region that just went down protects against nothing — cross-region copies are what make a pilot-light or warm-standby strategy in another region actually restorable.
Conflating RPO and RTO in a DR conversation. Fix: they're measured in opposite directions from the same failure point (RPO backward to the last durable copy, RTO forward to service restored) and move independently — naming one number without the other leaves half the recovery target undefined.
Relying on periodic snapshots alone for a tight RPO target. Fix: a snapshot only protects back to the last snapshot taken; point-in-time recovery (continuous transaction-log shipping) is what lets RPO shrink to "any second within the retention window" instead of "however often we remembered to snapshot."

Check yourself — a strategy has a tight RPO but a loose RTO. What does that mean concretely, and how could that happen?

You'd lose almost no data (replication is near-continuous), but recovery would still take a long time — e.g. data replicates continuously to a recovery region, but nobody has rehearsed actually standing that environment back up to serving traffic, so RTO stays high even though RPO is tight.

Check yourself — an entire AWS Region goes down. Does your Multi-AZ RDS failover cover you? Why or why not?

No — Multi-AZ answers "an AZ went down," not "a region went down"; its synchronous standby lives in a different AZ of the same region. Surviving a full regional outage needs a cross-region read replica promoted to primary, or a multi-region active/active setup, depending on the RTO/RPO target.

You can defend this when you can explain RTO and RPO as two different questions measured in two different directions from the same failure point; place any DR approach on the four-strategy ladder by naming what's actually running before the disaster hits; explain why a Multi-AZ database and a cross-region read replica sit at different points on that same ladder; and say why point-in-time recovery achieves a tighter RPO than periodic snapshots alone.