Disaster recovery on AWS: the four strategies and how to pick one.
AWS describes four disaster recovery (DR) strategies: backup and restore, pilot light, warm standby, and multi-site active/active. Each one buys faster recovery by keeping more of a second Region running. This page explains each strategy, how to choose one per workload, the AWS services behind it, and why a DR plan you have never tested is not a plan.
- AWS DR is a ladder of four strategies. Backup and restore is the cheapest and slowest (recovery in hours). Pilot light keeps the data live in a second Region (tens of minutes). Warm standby runs a small copy of the whole stack (minutes). Multi-site active/active serves traffic from two Regions (near zero). Each step up costs more.
- Pick a strategy per workload, not per company. Payments and login may justify warm standby; an internal dashboard is fine on backup and restore. Base it on what an hour of downtime and an hour of lost data cost you.
- A DR plan is only real once it has been tested. Restore your backups end to end, run a game day against a stopwatch, and make backups immutable so a compromised admin account cannot delete them.
IRTO and RPO: the two numbers that decide your DR design
Every DR design comes down to two numbers per workload. Set them first and the architecture mostly chooses itself.
RTO (Recovery Time Objective) is how long you can be down, from failure to serving traffic again. The four strategies compete mainly on RTO.
RPO (Recovery Point Objective) is how much data you can afford to lose. It is set by how often you back up or replicate: continuous replication gives seconds, hourly snapshots up to an hour, nightly backups up to a day.
Real RTO includes the slow human parts: someone has to notice, decide to fail over, and run the steps, and DNS and caches need time. A design that can fail over quickly on paper often takes longer in practice. A test is the only way to learn your real number.
For each critical system, answer two questions in dollars: what does an hour of downtime cost? and what does an hour of lost data cost? If both are large, look at warm standby or active/active. If downtime is costly but some data loss is survivable, pilot light. If both are cheap, backup and restore is the right answer.
IIThe four AWS DR strategies, from cheapest to fastest
AWS's <a href="https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html">disaster recovery whitepaper</a> groups DR into four approaches. The dividing line is how much of the second Region is already running when the primary fails.
Backup and restore (recovery in hours)
Nothing runs in the recovery Region until you need it. You copy backups (EBS and RDS snapshots, AMIs, S3 data) to another Region and rebuild from them during a disaster. AWS stresses deploying with infrastructure as code here: without it, rebuilding is slow and error-prone. RPO is the age of your last backup.
The cheapest tier: you pay for storage and cross-Region transfer, not idle compute. Right for internal tools, analytics, dev and staging, and for new startups that cannot yet justify a live second Region.
Pilot light (recovery in tens of minutes)
The data layer is always on and replicated (RDS read replicas, Aurora Global Database, S3 Replication, DynamoDB global tables). Application servers are defined but switched off. On failover you switch them on and scale out. RPO is seconds to minutes, set by replication lag.
You pay continuously for the replicated data stores, not for idle application servers. Right for production systems that cannot lose recent data but can tolerate a short recovery.
Warm standby (recovery in minutes)
A scaled-down but fully working copy of the whole stack runs in the second Region. AWS's distinction: pilot light cannot serve requests until you act, while warm standby can serve traffic at reduced capacity right away and only needs scaling up.
Costs more than pilot light because real compute runs in two Regions. Right for revenue-critical and customer-facing systems such as payments, login and the core API.
Multi-site active/active (near zero)
Two or more Regions serve live traffic. If one fails, the others absorb the load. AWS calls it the most complex and costly approach. The hard part is data: you choose a write pattern (for example Aurora Global Database with write forwarding, or DynamoDB global tables with last-writer-wins). Data corruption still needs point-in-time backups, so recovery from that is never zero.
Right for systems where downtime is catastrophic or contractually ruled out. Most startups do not need it early.
IIIHow to choose: per workload, not per company
The most common mistake is one strategy for everything. The second is choosing the most expensive one out of anxiety. The right design is usually a mix.
- Tier 1, revenue-critical: Warm standby, or active/active if an SLA demands near-zero recovery.
- Tier 1, cannot lose data but can wait: Pilot light: data replicated, compute off.
- Tier 2, important but survivable: Pilot light or a well-automated backup and restore.
- Tier 3, non-critical: Backup and restore. Do not keep staging warm in two Regions.
An Availability Zone failure and a Region failure are different problems. AWS notes that for a well-architected, highly available workload, losing one data center may only need backup and restore. Multi-AZ deployments are the baseline; cross-Region DR is a deliberate, costed decision for each critical workload.
IVThe AWS services behind each strategy
Each DR tier is built from a small set of AWS services. The skill is in wiring them together and proving the seams hold.
- AWS Backup: Central, policy-based backups for EBS, EC2, RDS and Aurora, DynamoDB, EFS and more, with cross-Region and cross-account copy. The base of backup and restore and the safety net under every other tier.
- AWS Elastic Disaster Recovery: Continuous block-level replication of servers from on-premises, another cloud or EC2 into a low-cost staging area. AWS describes it as a pilot light approach. Product page.
- Aurora Global Database and RDS read replicas: The data engine for pilot light and above. AWS says Aurora Global Database typically replicates to a secondary Region in under a second and can promote a secondary in under a minute. Docs.
- DynamoDB global tables: Multi-Region, multi-writer tables for active/active designs.
- S3 Replication and Versioning: Continuous object replication to another Region, with S3 Replication Time Control to monitor replication times, plus versioning and Object Lock for tamper-resistant copies.
- Route 53, Application Recovery Controller and Global Accelerator: Traffic steering: health-check failover, manual failover switches on the data plane, and weighted or latency routing for active/active.
- Infrastructure as code: CloudFormation, CDK, Terraform or OpenTofu. Not a DR service, but what makes backup and restore and pilot light fast and repeatable.
Teams replicate the database and forget the rest: secrets, parameters, TLS certificates, DNS records, IAM roles, KMS keys and launch templates in the recovery Region. A perfectly replicated database is useless if the recovery Region cannot decrypt it. Replicate the supporting pieces too, or keep them in code.
VRunbooks and game days: an untested DR plan is a guess
AWS says your backup strategy must include testing your backups, and its whitepaper has a section on <a href="https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/testing-disaster-recovery.html">testing disaster recovery</a>. This is where most DR programs quietly fail.
- Write the runbook for someone who did not build it: Who declares the disaster, the exact steps in order, how to verify the recovery Region is healthy, and how to fail back.
- Test the restore, not only the backup: Restore end to end on a schedule and confirm the application comes up on the restored data. Common surprises: a missing KMS key or an untested restore path.
- Run game days: Inject a realistic failure (stop the primary database, cut off a Region) and recover against a stopwatch. AWS Fault Injection Service is built for this. Quarterly is a reasonable cadence for critical systems.
- Record the real RTO and RPO: Measure time from failure to serving traffic and the actual data-loss window. If you miss the target, change the design or the automation, not the spreadsheet.
VIImmutable backups: surviving ransomware and stolen credentials
A Region outage is not the only disaster. Ransomware or a compromised admin account can delete your data and your backups. A backup an attacker can delete is not a backup.
- AWS Backup Vault Lock in compliance mode: Makes recovery points write-once: once the lock is in place, no user can delete them or shorten retention until they expire. Docs.
- S3 Object Lock and Versioning: The same protection for object data.
- A separate backup account: Copy critical backups into a locked-down account whose credentials are used for nothing else. AWS notes cross-account backup helps against insider threats and account compromise.
- Separate KMS keys: Encrypt backups with keys that are not used in production.
Ask: "If an attacker had full admin in our production account right now, could they delete our backups?" If the answer is not a clear "no, the vault is locked and in a separate account", your backups are inside the blast radius.
VIICompliance, and who builds and tests it
SOC 2, ISO 27001, HIPAA and PCI DSS all expect defined RTO and RPO for critical systems, a written recovery procedure, and evidence that you tested it. A dated game-day report is exactly that evidence.
A typical first-audit sequence: multi-AZ everywhere, RTO and RPO for critical systems, AWS Backup with cross-Region copy and Vault Lock, runbooks, and one real game day before the audit window.
CloudRoute matches you with one vetted AWS partner who can design the DR mix, build it as infrastructure as code, write the runbooks and run the first game day. DR work on its own is paid by you at the partner's rates.
If the DR build is part of a move to AWS, or part of a new workload you are launching on AWS, your matched partner can check MAP or incremental workload (IW) funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. AWS Activate credits, which you apply for yourself, can pay AWS usage such as the second Region, but not partner fees. CloudRoute is free for startups.
AWS DR strategies compared
Read top to bottom as more cost buying faster recovery. Recovery times follow AWS's DR whitepaper; costs are relative.
| Strategy | Recovery time | Data loss (RPO) | What runs in the recovery Region | Relative cost | Best for |
|---|---|---|---|---|---|
| Backup and restore | Hours | Age of the last backup | Nothing; rebuild from backups | $ | Tier 2 and 3, dev and staging, early startups |
| Pilot light | Tens of minutes | Seconds to minutes | Data live and replicated; compute off | $$ | Cannot lose data, can wait a little |
| Warm standby | Minutes | Seconds | A small but working full stack | $$$ | Revenue-critical tier 1 |
| Multi-site active/active | Near zero | Near zero (backups still needed for corruption) | Full stack serving live traffic | $$$$ | Downtime is catastrophic |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks which funding fits
Your matched partner scopes the work with you. Then it checks which partner-filed funding fits: MAP if you are moving to AWS, POC if you want to test something, or incremental workload (IW) funding if you are already on AWS and launching new work.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is the difference between RTO and RPO?
What are the four AWS disaster recovery strategies?
Which AWS DR strategy is right for my startup?
What is the difference between pilot light and warm standby?
How do I make AWS backups resistant to ransomware?
Can AWS funding pay for disaster recovery work?
Get your AWS DR designed, built and tested.
CloudRoute matches you with one vetted AWS partner who sets your RTO and RPO, builds the right strategy as infrastructure as code, writes the runbooks and runs the game day. CloudRoute is free for startups.