AWS Disaster Recovery: RTO, RPO and the 4 Strategies Compared
"The cloud is reliable" and "our data is safe" are two different sentences. AWS gives you extraordinary building blocks for resilience — and none of them are turned on by default. We design and operate DR setups for clients, including immutable cross-account backup vaults built specifically because of incidents we have responded to; this guide condenses that field experience into the decisions that actually matter: two numbers, four strategies, and the mistakes we keep seeing.
The two numbers that drive everything: RTO and RPO
- RTO (Recovery Time Objective): How long can you be down? "The system must be back within 4 hours" is an RTO of 4 hours.
- RPO (Recovery Point Objective): How much data can you afford to lose? "At most the last 15 minutes" is an RPO of 15 minutes.
Every DR decision is a price tag on these two numbers — lower numbers cost more, roughly exponentially. The most expensive mistake is not choosing a slow strategy; it is never having asked the business what the numbers actually are. Ask per system: your marketing site and your payment pipeline do not share an RTO.
The 4 AWS DR strategies
| Strategy | How it works | Typical RTO | Typical RPO | Relative cost |
|---|---|---|---|---|
| Backup & restore | Regular backups to another region/account; rebuild on disaster | Hours | Hours (last backup) | $ — storage only |
| Pilot light | Core data replicated continuously; minimal infrastructure idles, scaled up on disaster | Tens of minutes to hours | Minutes | $$ |
| Warm standby | A scaled-down but fully functional copy runs continuously; scale up + switch traffic | Minutes | Seconds to minutes | $$$ |
| Multi-site active/active | Full capacity in multiple regions serving live traffic; failure just shifts traffic | Near zero | Near zero | $$$$ |
Honest guidance: most companies need backup & restore done properly for most systems, and pilot light or warm standby for the one or two systems that genuinely cannot wait. Multi-site active/active is for revenue-per-minute businesses; buying it for everything is how DR budgets die. Infrastructure as code (see our IaC and GitOps guide) is what makes the cheaper strategies credible — "rebuild from scratch" is only fast if the rebuild is a pipeline, not a person's memory.
Backups that survive the bad day
The strategies above assume your backups exist when you need them. Three rules from incidents we have actually worked:
- Cross-account, not just cross-region. If backups live in the same account as production, an attacker with account access deletes both — we have seen exactly this attempted. A separate, locked-down backup account with its own credentials and minimal trust is the single highest-value DR upgrade. Our AWS compromise playbook shows the attack side of this argument.
- Immutable, not just copied. S3 Object Lock in compliance mode makes backups undeletable for a set retention — by anyone, including root, including ransomware with admin credentials. We run this pattern in production for clients precisely because "the attacker deleted the backups too" is a real failure mode, not a thought experiment.
- 3-2-1 still applies: three copies, two different systems, one off-site (in cloud terms: another account and region). RDS automated backups alone are one copy in one place.
An untested DR plan is a hope, not a plan
The restore test is the plan. Schedule it: quarterly, restore a database backup to a fresh instance and measure the time; yearly, run a game day that simulates losing the primary region. Every DR document we have ever been handed contained at least one step that no longer worked — an expired credential, a renamed resource, a runbook referencing a person who left. You find those on a calm Tuesday or during the disaster; there is no third option.
The mistakes that turn incidents into disasters
- Backups in the blast radius — same account, same credentials, deletable by the same attacker or the same fat-fingered script.
- RDS snapshots mistaken for a DR plan — they cover data, not the VPC, IAM, DNS, secrets, and configuration needed to actually serve traffic.
- DNS as an afterthought — failover that requires manually editing records under pressure adds an hour to every RTO. Health-checked Route 53 failover routing is cheap.
- Secrets that don't fail over — the standby region is useless if the application cannot authenticate there. Replicate secrets deliberately.
- One person owns the plan — if the runbook lives in someone's head, your real RTO includes their vacation schedule.
Frequently asked questions
What is the difference between RTO and RPO?
RTO is how long recovery may take (downtime tolerance); RPO is how much recent data you may lose (backup/replication frequency). They are set per system by the business, and every DR architecture decision prices against them.
Which AWS DR strategy should we choose?
Properly executed backup & restore for most systems, pilot light or warm standby for the few that genuinely cannot wait hours. Choose per system based on real RTO/RPO, not one strategy for everything.
Do backups protect against ransomware?
Only if the attacker cannot delete them: cross-account isolation plus S3 Object Lock immutability is the pattern that holds. Same-account deletable backups fail exactly when you need them most.
How often should DR be tested?
Restore tests quarterly with measured timings; a full failover game day at least yearly. An untested plan reliably contains steps that no longer work.
Bottom line
DR is not a product you buy; it is two numbers you choose and then honestly engineer against: cross-account immutable backups as the foundation, the right strategy tier per system, DNS and secrets included, and a restore test on the calendar. Do that, and most "disasters" become incidents with a runbook.
Want your DR posture reviewed by people who run this in production? Backup and DR design is part of our AWS Managed Services, and the Security Audit (fixed €8,000) covers backup isolation and immutability among its 98 checks. A free health scan will tell you quickly whether your backups would survive your worst day.