AWS disaster recovery strategies
AWS describes four disaster recovery strategies. They form a single spectrum: as you move along it, recovery gets faster and the standing bill gets larger. Choosing between them is therefore a business decision expressed in two numbers — the Recovery Point Objective (how much data you can afford to lose) and the Recovery Time Objective (how long you can afford to be down) — and a third, the budget.
Comparison
Section titled “Comparison”| Strategy | RPO | RTO | Standing cost | Typical building blocks |
|---|---|---|---|---|
| Backup and restore | Hours, set by backup frequency | Hours to a day or more | Lowest | AWS Backup, S3 with lifecycle to Glacier, EBS snapshots, AMIs |
| Pilot light | Minutes to hours | Tens of minutes to hours | Low | Replicated database, stopped or minimal compute, maintained AMIs |
| Warm standby | Minutes | Minutes | Moderate | Scaled-down but running stack, Route 53, Auto Scaling groups |
| Multi-site active/active | Near zero | Near zero | Highest | Full stack in both Regions, Route 53 health checks, DynamoDB global tables or Aurora Global Database |
1. Backup and restore
Section titled “1. Backup and restore”The simplest strategy: data is copied to AWS and the environment is rebuilt from it when needed. Minimal configuration, low implementation risk, lowest cost, longest recovery.
Implementation. AWS Backup as the orchestration layer; S3 as the durable target, with Cross-Region Replication for geographic separation and lifecycle rules moving older recovery points to S3 Glacier storage classes; EBS snapshots and AMIs for compute; AWS DataSync to move data in from on-premises storage; Storage Gateway Tape Gateway where an existing backup product expects to write to tape.
Limitations. It is an offsite backup and behaves like one. Recovery is largely manual, the recovery environment does not exist until you build it, and the RTO is dominated by how long that build takes — which is why an untested backup-and-restore plan is usually much slower in reality than on paper.
2. Pilot light
Section titled “2. Pilot light”A minimal footprint is kept running so that the core of the system is always present, in the way a pilot light keeps a gas heater ready to fire. Data replicates continuously; compute is provisioned but stopped, or running at the smallest viable size.
Implementation. A small replicated database instance; EC2 instances that exist but are stopped, or AMIs kept current and ready to launch; the network, IAM and DNS scaffolding fully built.
Recovery. Start the stopped instances; scale the database up to production capacity; redirect traffic; validate.
What makes or breaks it. AMI currency. A pilot light whose images are six months stale recovers into a configuration nobody has run, and the RTO becomes whatever debugging that takes. Regular rehearsal is not optional.
3. Warm standby
Section titled “3. Warm standby”A complete but scaled-down copy of the environment runs continuously. Everything is deployed and serving health checks; there is simply less of it.
Implementation. An active load balancer, running web and application instances at reduced count or size, a replicated database, and Route 53 managing where traffic goes.
Recovery. Scale up — increase instance counts and sizes, raise database capacity — and shift DNS. Because the stack is already running and already validated, the failure modes that bite a pilot light have mostly been eliminated in advance.
Secondary benefit. A warm standby doubles as a staging or shadow environment, which is also the most reliable way to keep it honest: an environment that is used is an environment that works.
4. Multi-site active/active
Section titled “4. Multi-site active/active”A full production environment runs in both locations and both take live traffic. Failover is the removal of one from rotation rather than the construction of anything.
Implementation. Full-scale compute in both Regions, active database replication (DynamoDB global tables, Aurora Global Database, or application-level replication), and Route 53 health checks with latency or weighted routing.
Recovery. Route 53 stops answering with the impaired endpoint; traffic follows. The practical floor on recovery time is DNS TTL plus health-check interval, not the time to bring anything up.
Costs and complications. It is the most expensive option and it is the hardest to get right: bidirectional data replication forces you to answer conflict-resolution questions that the other three strategies let you defer. Standing capacity that is never “used” for failover is also the most visible line item to challenge, which is worth pre-empting with the availability requirement it buys.
Choosing and keeping it working
Section titled “Choosing and keeping it working”Selection. Start from the RTO and RPO the business will actually commit to, in writing, per workload — different systems in the same estate usually warrant different strategies. Then check the budget and the team’s capacity to operate what you have chosen.
Operation. Every strategy above degrades silently if it is not exercised. Test failover on a schedule, keep AMIs and infrastructure code current, document the runbook, automate the steps that can be automated, and monitor replication lag so the RPO you are quoting is the RPO you have.