AWS Disaster Recovery Strategies Explained: RPO, RTO, Pilot Light vs Warm Standby
Disaster recovery planning answers one question: if your primary AWS environment goes down, how do you get back online, and how much data do you lose in the process? This page walks through the four AWS DR strategies, explains how RPO and RTO drive the choice, and gives you concrete guidance for picking the right one.
What this page helps you decide
After reading this page you’ll be able to:
- Define RPO and RTO in plain language and explain why they’re the starting point for every DR decision
- Explain the difference between disaster recovery, high availability, and backups
- Compare the four AWS DR strategies and understand when each is appropriate
- Identify the AWS services that support each DR pattern
- Know what to test and what commonly breaks when DR plans are put into practice
If you’re about to make an architecture decision about resilience, whether for a new system or to improve an existing one, this page gives you the context to make that call.
Disaster recovery in plain terms
Disaster recovery is what happens when normal failover isn’t enough. It’s the plan for getting back online after a major failure, not a crashed process or a single overloaded server, but a scenario where your primary environment is gone or severely compromised.
Examples of what disaster recovery addresses:
- An entire AWS region becomes unavailable due to a large-scale infrastructure event
- A database is corrupted by a bad deployment, and the corruption has already reached your standbys
- A human error such as a dropped table or a misconfigured security group takes down production and can’t be reversed quickly
DR is not the same as regular high availability, which handles routine failures like a single EC2 instance dying or one AZ going offline. DR covers the situations where your primary region is the problem, not just a component inside it.
Disaster recovery vs high availability vs backups
Multi-AZ is not disaster recovery. It handles single-AZ failures within one region. If the entire region goes down, or if data gets corrupted across all replicas, Multi-AZ provides no protection. Disaster recovery is a separate strategy that requires separate infrastructure.
These three concepts overlap but solve different problems.
| Concept | What it addresses | Typical scope | Example |
|---|---|---|---|
| High availability | Routine component failures | Single region, multi-AZ | RDS Multi-AZ failover when one AZ goes down |
| Disaster recovery | Large-scale or catastrophic events | Cross-region or data corruption | Failing over to us-west-2 when us-east-1 is unavailable |
| Backups | Data corruption, accidental deletion, compliance | Point-in-time recovery | Restoring an RDS snapshot from before a bad migration |
Multi-AZ vs Multi-Region is the sharpest distinction to understand:
- Multi-AZ keeps your system running when one data center in a region fails. RDS Multi-AZ automatically fails over to a synchronous standby in another AZ within the same region, typically in 60 to 120 seconds with no manual intervention. It handles AZ failures, not region failures.
- Multi-Region is what most people actually mean by disaster recovery. Your recovery environment sits in a completely separate AWS region, isolated from whatever caused the primary failure.
You need both. Multi-AZ handles day-to-day resilience. A cross-region DR strategy handles the scenarios that Multi-AZ doesn’t protect against.
Backups are a safety net beneath all of this. Even if you have a warm standby running in a second region, backups protect against data corruption that replicates instantly to your standby. That’s a problem your DR strategy alone cannot solve.
How RPO and RTO actually drive the decision
Every DR choice follows from two numbers. Define them before choosing a strategy.
RPO (Recovery Point Objective) is the maximum amount of data loss your business can tolerate, expressed as time. An RPO of 24 hours means you accept losing up to one day of transactions. An RPO of 5 minutes means you need near-continuous replication.
RTO (Recovery Time Objective) is the maximum acceptable downtime. An RTO of 4 hours means the system can be unavailable for 4 hours during a disaster. An RTO of 15 minutes means you need pre-deployed infrastructure in a recovery region that can start serving traffic within 15 minutes.
RPO is like a save point in a video game. If you save at level 5 and get knocked out at level 7, you lose two levels of progress. That lost progress is your RPO. RTO is how long it takes to reboot, reload, and get back into the game.
A business that processes financial transactions typically needs an RPO in seconds. A blog with static content might accept 24 hours without meaningful impact.
The key relationship: lower RPO and RTO cost significantly more money. A 24-hour RPO with 8-hour RTO costs a fraction of a 1-minute RPO with 15-minute RTO. Your job as an architect is to find out what the business actually needs, not what sounds most resilient, and build to that.
Business translation#
Ask two questions with your stakeholders:
- “How much data can we lose?” This is RPO. The answer is often “none!” until you show them what near-zero RPO infrastructure actually costs.
- “How long can we be down?” This is RTO. The answer changes when you explain the cost difference between 15-minute RTO and 4-hour RTO.
Workload examples#
| Workload | Practical RPO | Practical RTO | Why |
|---|---|---|---|
| Internal reporting app | 24 hours | 8 hours | Delayed reports are inconvenient, not catastrophic |
| E-commerce site | 15 to 60 minutes | 30 to 60 minutes | Revenue impact but customers can retry; recovery within an hour is acceptable |
| Financial transaction system | Seconds | Minutes | Every lost transaction is a compliance and financial liability |
AWS disaster recovery strategies at a glance
| Strategy | Typical RTO | Typical RPO | Cost | Complexity | Best fit | Main trade-off |
|---|---|---|---|---|---|---|
| Backup and Restore | Hours to days | Hours to days | Very low | Low | Non-critical systems, dev/test | Long recovery time; no pre-deployed infrastructure |
| Pilot Light | 30 min to 2 hours | Minutes to 1 hour | Low | Medium | Apps where the DB is the critical component | Compute must spin up during failover |
| Warm Standby | 10 to 30 minutes | Seconds to minutes | Medium | Medium to High | Production apps with moderate uptime SLAs | Ongoing cost of running scaled-down secondary |
| Multi-Site Active-Active | Seconds | Seconds | High | High | Mission-critical, revenue-sensitive systems | Distributed write complexity; full second-region cost |
How each AWS DR strategy works
Backup and Restore
Simple explanation: Take regular backups, store them somewhere safe, and provision new infrastructure from scratch if disaster strikes.
How it works in AWS: Backups are stored in S3, either directly or via AWS Backup. If the primary region fails, you provision new infrastructure in the recovery region using your infrastructure as code templates, then restore data from the most recent backup.
Typical AWS services:
- AWS Backup for centralized backup management across RDS, DynamoDB, EBS, and EFS
- RDS automated backups and snapshots with daily snapshots restorable to any region
- EBS snapshots copied to a second region
- S3 versioning for object-level rollback
Best use cases: Cost-sensitive workloads where hours of downtime are acceptable: internal tools, dev environments, content archives.
When not to use it: Any customer-facing production system with an RTO under a few hours.
Pros: Very low ongoing cost. Simple to implement and reason about.
Limitations: Long RTO. Provisioning infrastructure from scratch takes 2 to 4 hours before data restoration even begins. RPO is limited by backup frequency.
Pilot Light
Simple explanation: Keep the most critical component, almost always the database, running and synced in the recovery region. Everything else is off. During failover, start the compute layer and redirect traffic.
A gas furnace has a small pilot flame that burns continuously. The furnace itself doesn’t run until you need it, but because that flame is always there, the furnace lights in seconds. Pilot Light DR works the same way: the database (the flame) runs continuously in the recovery region, so when disaster strikes, you’re not starting from zero.
How it works in AWS: The database replicates continuously to the recovery region via read replicas. Compute resources are not running, but AMIs and launch templates are pre-built in the recovery region. Route 53 health checks are configured but pointing to the primary.
Typical AWS services:
- RDS read replica in the recovery region, kept current via async replication
- S3 Cross-Region Replication for application assets
- AMIs pre-built in the recovery region
- Route 53 failover routing
Best use cases: Applications where the database is the critical stateful component and 30 to 90 minute RTO is acceptable.
When not to use it: When you need RTO under 15 minutes (compute startup time adds too much delay) or when your app has multiple stateful components beyond just the database.
Pros: Low ongoing cost because compute isn’t running. The database stays current.
Limitations: Failover involves manual steps: promote replica, launch instances, update DNS. RTO depends on how long compute takes to start and warm up.
Warm Standby
Simple explanation: Run a scaled-down but fully functional copy of your production environment in the recovery region. During failover, scale it up.
How it works in AWS: Both the compute and database layers are running in the recovery region at reduced capacity, typically 20 to 30% of production. The secondary database is an RDS read replica receiving continuous replication. The compute tier is live and has been exercised, so its configuration is validated before any disaster occurs.
Amazon CloudWatch monitoring the ReplicaLag metric tells you your actual RPO exposure at any moment. Set an alert on it if lag exceeds your RPO threshold.
A realistic failover scenario: Production runs in us-east-1. A warm standby runs 2 EC2 instances and an RDS read replica in eu-west-1. Route 53 has a failover routing policy pointing all traffic to us-east-1.
A major networking event hits us-east-1. Route 53 detects health check failures (30 to 60 seconds), updates DNS to eu-west-1. An on-call engineer promotes the RDS read replica in eu-west-1 to a writable primary (about 5 minutes) and scales the Auto Scaling Group from 2 to 6 instances (about 5 minutes). Total time to recovery: roughly 12 to 15 minutes. Transactions from the last 30 to 60 seconds before the failure that hadn’t yet replicated are lost. That’s the actual RPO.
Best use cases: Production applications where 10 to 30 minute RTO and sub-5-minute RPO are required. The most practical choice for many SaaS and e-commerce workloads.
When not to use it: When even 10 minutes of downtime causes unacceptable business or regulatory consequences.
Pros: Fast RTO. Lower risk than pilot light because the standby environment is already running and validated.
Limitations: Ongoing cost of running a second environment, even at reduced scale.
Multi-Site Active-Active
Simple explanation: Run full production capacity in two or more regions simultaneously, with live user traffic distributed across all of them. Both regions serve real traffic all the time.
How it works in AWS: Route 53 latency routing or weighted routing distributes traffic across regions. If one region degrades, Route 53 health checks redirect all traffic to the healthy region within seconds. Both regions are full-scale and independently capable of handling 100% of production traffic.
Typical AWS services:
- DynamoDB Global Tables for multi-region, multi-primary replication with last-writer-wins conflict resolution
- Aurora Global Database with low-latency replication and fast failover (about 1 minute)
- Route 53 latency or weighted routing
- CloudFront for edge distribution
Best use cases: Mission-critical systems where even minutes of downtime is unacceptable: financial platforms, high-traffic marketplaces, real-time systems.
When not to use it: When the infrastructure and engineering cost is not justified by the business’s actual RTO and RPO requirements. Most applications can meet their SLAs with Warm Standby at a fraction of the cost.
Pros: Near-zero RTO and RPO. No failover event per se. Degraded region traffic routes away automatically.
Active-active does not protect you from bad data. If a deployment corrupts your database records, that corruption lands in your second region within seconds. Replication doesn’t know the difference between a valid write and a destructive one. Point-in-time backups are the only recovery path when data itself is the problem.
Limitations: Write conflict management is genuinely complex. Full second-region infrastructure cost is real. Operational complexity is high.
Pilot Light vs Warm Standby: the actual difference
People confuse these two because they’re both active-passive strategies with infrastructure in a recovery region. The difference is what’s already running before you declare a disaster.
| Pilot Light | Warm Standby | |
|---|---|---|
| Database in recovery region | Running (read replica) | Running (read replica) |
| Compute in recovery region | Off (AMIs and templates only) | Running at reduced scale |
| What happens during failover | Promote DB + launch compute + update DNS | Promote DB + scale up compute + update DNS |
| Typical time to recover | 30 min to 2 hours | 10 to 30 minutes |
| Ongoing cost | Lower (no running compute) | Higher (compute is running) |
| Confidence in recovery environment | Lower (compute not validated) | Higher (compute has been exercised) |
A common misconception: because warm standby has more running infrastructure, people assume failover is fully automatic. It isn’t. Both pilot light and warm standby require manually promoting the read replica to a writable primary. That step takes 3 to 5 minutes and must be documented in your runbook before you need it.
Why warm standby is faster: The compute layer is already running, configured, and validated. There’s no boot time, no AMI launch delay, no uncertainty about whether the launch configuration is current.
Why teams choose pilot light anyway: Cost. Keeping a scaled-down compute layer running in a second region 24/7 adds up. Pilot light keeps the recovery region cheap because you’re only paying for a read replica and stored AMIs, as long as you’re disciplined about testing.
Which to choose:
- Pilot Light: workloads with RTO tolerance of 30 minutes to a few hours, cost is a constraint, and you run regular DR tests
- Warm Standby: production apps where 10 to 30 minute RTO matters and you want higher confidence that the recovery environment actually works when you need it
AWS services commonly used in DR
These are the services that appear most often in real AWS DR plans, with context on what they actually do in that role.
AWS Backup centralizes backup management for RDS, DynamoDB, EBS, EFS, and S3. You define retention policies, copy backups across regions, and audit coverage across accounts. Most useful in Backup/Restore strategies and as a safety net beneath higher-tier DR.
Amazon RDS (automated backups and read replicas) is the core of most AWS DR strategies. RDS automated backups run daily and enable point-in-time recovery up to 5 minutes before an event. Read replicas replicate changes from the primary with low lag. The distinction matters: automated backups protect against data corruption via point-in-time restore, while read replicas support fast failover but replicate corruption instantly.
Amazon S3 (versioning and Cross-Region Replication) covers your object storage. S3 versioning retains previous object versions, protecting against accidental deletion. Cross-Region Replication keeps buckets in sync across regions automatically.
EBS Snapshots are incremental point-in-time copies of volumes, useful for EC2-backed workloads. EBS snapshots can be copied to a second region. For database-backed workloads, use RDS automated backups rather than snapshotting the underlying volume.
Route 53 handles DNS-based failover routing. Health checks detect endpoint failures and update routing records automatically.
Route 53 DNS TTL controls how long resolvers cache your record. A TTL of 300 seconds means clients keep routing to the old endpoint for up to 5 minutes after you update DNS. Before a planned DR test, lower the TTL to 60 seconds. After the test, set it back to 300.
Auto Scaling scales compute capacity in the recovery region during failover. In a warm standby setup, you scale up an existing ASG. In a pilot light setup, you launch new instances from pre-built AMIs. Both require that your launch configuration is current and tested in the recovery region.
Amazon CloudWatch lets you monitor the ReplicaLag metric on RDS read replicas to understand your actual RPO exposure at any moment. Pair this with alerts that fire when lag exceeds your RPO threshold.
Infrastructure as Code (Terraform, CloudFormation) is not optional for a reliable DR plan. If your recovery region infrastructure was built by clicking through the console, it will diverge from production silently. Terraform for AWS and CloudFormation let you reproduce infrastructure deterministically and detect drift before you need it.
AWS Resilience Hub assesses your application against defined RTO and RPO targets, identifies gaps, and tracks configuration drift over time. Useful for teams that want continuous visibility rather than point-in-time audits.
AWS Elastic Disaster Recovery (AWS DRS) is a server-level replication service primarily used for lift-and-shift DR or when incorporating on-premises workloads into an AWS DR plan. DRS continuously replicates servers to AWS and lets you launch recovery instances in minutes. Most relevant for VM-based workloads rather than cloud-native architectures built around managed services.
How to choose the right strategy
The right strategy follows directly from your RPO and RTO requirements and the business consequences of downtime.
Scenario 1: Internal reporting tool or admin dashboard
Recommended strategy: Backup and Restore. A few hours of downtime inconveniences the team but doesn’t affect customers or revenue. Daily backups with 8-hour RTO is acceptable. Document that the business accepts this and get sign-off from stakeholders.
Scenario 2: Marketing site or content blog
Recommended strategy: Backup and Restore or Pilot Light. The site is mostly read-only. A 1 to 2 hour RTO is typically acceptable. If the site generates meaningful revenue, the modest cost of pilot light may be justified. If not, Backup/Restore is the right call.
Scenario 3: SaaS application with a 99.9% uptime SLA
Recommended strategy: Warm Standby. A 10 to 30 minute RTO and sub-5-minute RPO is usually sufficient for 99.9% availability targets. Warm standby gives you confidence the recovery environment works and keeps failover fast enough to meet the SLA. Budget for the ongoing cost of a second-region environment before committing to that SLA.
Scenario 4: Mission-critical transactional system (payments, financial data)
Recommended strategy: Multi-Site Active-Active. Every minute of downtime is a financial and regulatory liability. Near-zero RPO and RTO is required. The infrastructure cost is justified by the business consequences of downtime. Validate the requirement before committing to the complexity this involves.
Testing your DR plan
An untested DR plan is a plan you cannot rely on. Failover procedures drift from reality every time a dependency changes, a configuration is updated, or the team member who wrote the runbook moves on.
What breaks most often in untested DR plans:
- Database promotion works, but the application config still points to the old primary endpoint
- Compute scales up but can’t reach the new database because security group rules weren’t updated for the recovery region’s CIDR
- The recovery region hits service quota limits when you try to scale up to production capacity
- Application dependencies such as third-party APIs or internal services only have configuration pointing to the primary region
- The runbook was written by someone who has since left the team
DR test checklist:
- RPO and RTO requirements documented and signed off by stakeholders
- Recovery region infrastructure matches IaC templates (no console-only resources)
- Route 53 health checks configured, tested, and pointing to correct endpoints
- DNS TTL reduced before the test
- Database promotion tested end-to-end
- Application successfully connects to the promoted database in the recovery region
- Service quotas verified for production-scale compute, IPs, and other resources in recovery region
- CloudWatch alerts active for ReplicaLag and health check failures
- Full DR test timed: was the actual RTO within the target?
- Failback to the primary region tested and documented
- Runbook updated after every test to reflect what actually happened
Minimum: once per year. For critical systems: quarterly. Always time the test and compare it against your documented RTO target. A plan that works but takes 2 hours when your RTO is 30 minutes is a failing plan.
Common mistakes
- Choosing a strategy before defining RPO and RTO. “We need to be resilient” is not a requirement. Get specific numbers from business stakeholders. The cost difference between a 4-hour RTO and a 15-minute RTO is large, and stakeholders need to understand that before signing off on the architecture.
- Confusing Multi-AZ with disaster recovery. Multi-AZ is high availability within a region. It handles AZ failures automatically. It does not protect against region-wide events, accidental data deletion, or data corruption. If you have Multi-AZ and no cross-region DR strategy, you have high availability, not disaster recovery.
- Assuming replication alone is enough. Replication copies changes continuously, including bad ones. A corrupted write, a dropped table, or a bad migration replicates to your read replica immediately. Replication protects against infrastructure failure. Backups protect against data mistakes. Keep automated backups enabled even if you have cross-region replication.
- Never testing the failover procedure. Configurations change, dependencies shift, and people move teams. A procedure that worked 12 months ago may not work today. Test it, time it, and compare the result against your documented RTO target.
- Ignoring service quotas in the recovery region. EC2 instance limits, Elastic IP limits, and other service quotas are per-region and don’t automatically match your primary. Request quota increases in your recovery region before you need them, not during a disaster.
- Not storing infrastructure as code. If your recovery region infrastructure was built by hand through the console, it will silently diverge from production. Use infrastructure as code so you can deploy the recovery environment deterministically and detect drift during regular testing.
- Using vague recovery objectives. “We should be back up quickly” is not an RTO. Without measurable objectives, you can’t test against them, can’t communicate SLAs to customers, and can’t justify the right DR tier to stakeholders.
Summary
- RPO defines acceptable data loss; RTO defines acceptable downtime. Define both before choosing a DR strategy and get business stakeholder sign-off on the numbers.
- High availability (Multi-AZ) and disaster recovery (Multi-Region) are different. You need both. HA handles routine failures; DR handles catastrophic ones.
- The four strategies form a cost vs recovery speed spectrum: Backup/Restore, Pilot Light, Warm Standby, Multi-Site Active-Active. Most production apps land at Warm Standby.
- Pilot Light and Warm Standby are both active-passive. The difference is that Warm Standby keeps compute running in the recovery region; Pilot Light keeps only the database running.
- Backups matter even in active-active setups. Replication doesn’t protect against corrupted writes. Only point-in-time backups do.
- Test your DR plan at least annually, time it, and compare against your documented RTO target. Untested plans routinely fail when needed.
Frequently asked questions
What is the difference between RPO and RTO?
RPO (Recovery Point Objective) is the maximum amount of data loss your business can tolerate, expressed as time. An RPO of 1 hour means you accept losing up to 1 hour of transactions. RTO (Recovery Time Objective) is the maximum acceptable downtime. An RTO of 4 hours means the system can be unavailable for 4 hours during a disaster. RPO drives your backup frequency and replication lag tolerance. RTO drives how quickly your recovery infrastructure must be ready to serve traffic.
Is Multi-AZ the same as disaster recovery?
No. Multi-AZ handles AZ-level failures automatically within a single region. Disaster recovery addresses region-level failures, data corruption, or catastrophic loss. Multi-AZ is high availability. The four DR strategies on this page cover scenarios that take out an entire region or corrupt your data in ways that HA cannot handle.
What is the difference between pilot light and warm standby?
In a pilot light setup, only the most critical components (usually the database) are running in the recovery region. Compute is off or minimal. In warm standby, a scaled-down but fully functional copy of your environment is running. Warm standby is faster to fail over to because less infrastructure needs to start, but it costs more to maintain continuously.
Do I still need backups if I use multi-region replication?
Yes. Replication copies your data continuously, including mistakes. If a bad deployment corrupts records or someone drops a table, that corruption replicates instantly. Backups (point-in-time snapshots) let you recover data from before the corruption. Replication and backups solve different problems and you need both.
How often should I test a DR plan?
At minimum, test once per year. For critical systems, test quarterly. Untested DR plans routinely fail when needed because dependencies change, configurations drift, and procedures that seemed clear on paper turn out to be ambiguous under pressure. DR tests should be on your operational calendar, not a one-time exercise.