beginnerintermediateadvanced

AWS · Disaster Recovery

Disaster Recovery

The four strategies, RPO and RTO, testing recovery, and multi-AZ versus multi-Region

Four strategies, rising costbackup/restore → pilot light → warm standby → active/active
RPO = data lost, RTO = time downboth per workload, both checked against the mechanism
Test the restore, not the backupa restore never run has an unknown duration
Multi-AZ ≠ a weak multi-Regiondifferent failures, different mechanisms

1.The Four DR Strategies

AWS groups disaster recovery into four approaches, from cheapest and slowest to most expensive and fastest. Backup and restore keeps copies and rebuilds. Pilot light keeps the data replicated and the core infrastructure provisioned but switched off. Warm standby keeps a scaled-down but running copy. Multi-site active/active runs everywhere at once, so there is no failover at all.

Key features

AWS's own distinction between pilot light and warm standby: pilot light cannot process requests without action being taken first, whereas warm standby can handle traffic immediately at reduced capacity
Backup and restore requires redeploying infrastructure, configuration, and application code in the recovery Region — which is why AWS says to always deploy with infrastructure as code
Pilot light keeps data replication and core stores always on, with application servers deployed but "switched off"; the best practice for switched off is not to deploy it and to have the capability to deploy on demand
Warm standby extends pilot light by being always-on, which also makes continuous testing of the recovery path practical
With multi-site active/active there is no failover — testing focuses on whether traffic routes away from a failed Region and whether the others can absorb it
Hot standby is active/passive at full capacity, and AWS notes most customers who build a full second environment end up using it active/active instead; whichever you pick, use only data plane operations during failover, because data planes have higher availability design goals than control planes

The four strategies compared

The four strategies compared
Strategy	What is running in the DR Region	Cost and complexity
Backup and restore	Backups only	Lowest — storage plus a tested rebuild path
Pilot light	Data stores and replication; servers deployed but off	Low — storage, replication, and deployment discipline
Warm standby	A scaled-down but fully functional copy	Moderate — you pay for the running copy
Hot standby	Full capacity, no traffic	High — statically stable, no Auto Scaling dependency at failover
Multi-site active/active	Full capacity, serving traffic	Highest — plus the hardest data-consistency design

Four strategies, cheapest first

Backup and restore

Data copied; infrastructure and code redeployed at failover. Hours.

Pilot light

Data replicated continuously, core infrastructure provisioned but off. Tens of minutes.

Warm standby

Scaled-down but fully functional and serving-capable. Minutes.

Multi-site active/active

Running everywhere; no failover step exists. Near zero.

Signature

backup/restore < pilot light < warm standby < hot standby < multi-site active/active

Backup and restore (rebuild), pilot light (data live, servers off), warm standby (scaled-down but serving), active/active (no failover at all). Cost buys speed and, more importantly, a path you have proven. Use only data plane operations at failover, and never mistake replication for backup.

2.RPO and RTO

RPO — recovery point objective — is how much data you can afford to lose, measured in time. RTO — recovery time objective — is how long you can afford to be down. Both are business decisions expressed as numbers, and they are what pick the DR strategy: the strategy does not come first and produce them.

Key features

RPO is bounded by backup or replication frequency: hourly snapshots mean an RPO of up to an hour, no matter how fast recovery is
RTO is bounded by the slowest step in the recovery path, which is usually rebuilding infrastructure rather than restoring data
Continuous replication drives RPO toward zero but does not improve RTO by itself — the standby still has to be promoted and traffic still has to move
AWS notes recovery time and recovery point are always greater than zero, which is why automatically-triggered failover on a false alarm imposes a real cost
Aurora global database can promote a secondary Region to read/write in under a minute even during a complete regional outage, and typical cross-Region replication latency is under a second
Both objectives are per workload, not per company — the marketing site and the payments ledger do not deserve the same numbers or the same spend

What each objective is actually bought with

What each objective is actually bought with
Objective	Set by	Buy a smaller number with
RPO ≈ 24 h	Daily snapshots	More frequent snapshots
RPO ≈ minutes	Frequent snapshots or log shipping	Point-in-time recovery
RPO ≈ seconds	Continuous cross-Region replication	Aurora global database, DynamoDB global tables, S3 replication
RTO ≈ hours	Rebuild from backups	Infrastructure as code, tested restores
RTO ≈ tens of minutes	Pilot light	Pre-provisioned core infrastructure
RTO ≈ minutes	Warm standby	An always-running scaled-down copy

RPO and RTO around a disaster

02:00
Last usable recovery point
The most recent backup or replicated state
02:47
Disaster
Everything after the recovery point is lost — this gap is the RPO
02:52
Detected and declared
Detection time counts toward RTO
03:20
Service restored
Disaster to restored is the RTO

Signature

RPO = data loss window (backup/replication frequency) · RTO = downtime window (detect + decide + restore + cut over)

RPO = how much data you can lose (set by backup or replication frequency). RTO = how long you can be down (set by the slowest recovery step, including detection and decision). Set them per workload, then check the mechanism actually delivers them.

3.Designing and Testing Recovery Procedures

A backup you have never restored is a guess. A failover you have never performed is a plan. The only way to know your RTO is to run the recovery end to end, on a schedule, and measure it — which also converts the runbook from a document into something people have actually done.

Key features

AWS states it is critical to regularly assess and test the DR strategy so you have confidence in invoking it, and names AWS Resilience Hub for continuously validating whether RTO and RPO targets are likely to be met
Backup strategy must include testing the backups — a restore that has never been run has an unknown success rate and an unknown duration
AWS recommends scheduled periodic data restore because restoring from backup is a control plane operation that may be unavailable during a disaster
AWS Backup offers restore but does not currently schedule or automate it, so automatic restore testing has to be built with the SDK
Manually-initiated failover is common precisely because a false-alarm automatic failover still costs real data and availability loss
Automate the steps of a manual failover so the human decision is one action rather than a sequence under pressure — and note that even multi-site active/active needs testing: does traffic route away from a failed Region, and can the others absorb all of it?

Rehearsal levels, cheapest first

Rehearsal levels, cheapest first
Level	What it proves	Frequency
Restore a backup into a scratch account	The backup is readable and complete	Automated, continuous
Restore and run integrity checks	The data is usable, not just present	Weekly or monthly
Failover a database in staging	The application reconnects correctly	Each release cycle
Full DR drill in the recovery Region	The end-to-end RTO, including decisions	Quarterly or half-yearly
Production failover in a low window	The plan works on the real system	Annually, once the drills pass

A recovery rehearsal that is worth running

Declare the scenario

Region loss, data corruption, or account compromise — they have different answers

Start the clock at the failure

Not at the moment engineers start working

Follow the runbook as written

Every improvisation is a bug in the runbook

Validate, do not just start

A service that boots but serves wrong data has not recovered

Record the real RTO and RPO

Compare against the target, and fix the gap or the target

Signature

automated restore tests → integrity checks → staged drills → full DR drill → production failover

Test the restore, not the backup. Start the clock at the failure, not at the response. Rehearse on a schedule and record the real RTO. Automate every failover step but keep the decision human — and expect DR-Region quotas and departed runbook owners to be your first two findings.

4.Multi-AZ vs Multi-Region Recovery

Multi-AZ protects against losing one data centre and is mostly automatic, synchronous, and cheap. Multi-Region protects against losing a whole Region and is manual, asynchronous, and expensive. They are answers to different questions, and multi-AZ — which almost every production workload should already have — is not a weaker form of multi-Region.

Key features

AWS notes that for a disaster limited to the disruption or loss of one data centre in a well-architected, highly available workload, backup and restore may be all the DR you need
If your definition of a disaster extends to a Region — or regulation requires it — that is when pilot light, warm standby, or multi-site active/active become relevant
Multi-AZ replication for RDS is synchronous within a Region; cross-Region replication is asynchronous, which is why multi-Region RPO is greater than zero
AZs within a Region have low-latency links, so cross-AZ calls are ordinary; cross-Region calls are not, and an application spanning Regions has to be designed for the latency
Nearly every AWS resource is regional: a multi-Region posture means duplicating VPCs, IAM-adjacent configuration, images, secrets, and quotas in a second Region
Aurora global database can promote a secondary Region in under a minute even during a complete regional outage, which is the exception rather than the norm across services

What each posture actually gives you

What each posture actually gives you
Aspect	Multi-AZ	Multi-Region
Protects against	Loss of one Availability Zone	Loss of an entire Region
Replication	Synchronous (RDS Multi-AZ)	Asynchronous — RPO is greater than zero
Failover	Largely automatic	Deliberate, usually manually initiated
Latency between sites	Low, single-digit milliseconds	Tens to hundreds of milliseconds
Cost	Modest — often a checkbox	Substantial — duplicate everything
Typical posture	The production baseline	A business decision, per workload

Command

text

# The sequence almost every workload should follow
1. Multi-AZ everywhere in production          (baseline)
2. Cross-Region backups                        (cheap, protects the data)
3. Pilot light or warm standby, if RTO demands it
4. Active/active, only where the business case is explicit

Multi-AZ: synchronous, automatic, cheap, survives losing one data centre — the production baseline. Multi-Region: asynchronous, deliberate, expensive, survives losing a Region — a per-workload business decision. Cross-Region backups sit between them and are usually the right second step.

Spotted a mistake on this page? Tell us.

Read Sheet