Every architecture eventually faces "what happens when this fails?" Disaster recovery (DR) isn't about preventing failures — it's about recovering from them within acceptable time and data loss thresholds.
AWS provides four DR strategies with progressively lower RTO/RPO at progressively higher cost. The art is matching the right strategy to each workload's business criticality — not over-engineering (expensive) or under-investing (risky).
This post covers all four strategies, when to use each, the AWS services that implement them, and practical automation patterns for reliable failover.
RTO and RPO: The Two Numbers That Drive Everything
| Metric | Definition | Question It Answers |
|---|---|---|
| RTO (Recovery Time Objective) | Maximum acceptable downtime | How long can we be down? |
| RPO (Recovery Point Objective) | Maximum acceptable data loss | How much data can we lose? |
Data Loss Downtime
◄──────────────────► ◄──────────────────────►
Last backup Disaster Recovery Normal ops
│ │ │ │
▼ ▼ ▼ ▼
────┼──────────────┼───────────┼────────────┼────
│ │ │ │
│◄── RPO ─────►│ │ │
│◄── RTO ──►│
The Four DR Strategies
Cost / Complexity →
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Backup & │ │ Pilot │ │ Warm │ │ Multi-Site │
│ Restore │ │ Light │ │ Standby │ │Active-Active│
└────────────┘ └────────────┘ └────────────┘ └────────────┘
RTO: Hours RTO: 10s min RTO: Minutes RTO: Near-zero
RPO: Hours RPO: Minutes RPO: Seconds RPO: Near-zero
Cost: $ Cost: $$ Cost: $$$ Cost: $$$$
Strategy 1: Backup and Restore
RTO: 1-24 hours | RPO: 1-24 hours | Cost: Lowest
The simplest strategy: back up data and configurations to another region. When disaster strikes, restore from backups and rebuild infrastructure.
Implementation
| Component | Backup Method | Target |
|---|---|---|
| EC2/EBS | EBS Snapshots (cross-region copy) | DR Region S3 |
| RDS | Automated snapshots + cross-region replication | DR Region |
| S3 | Cross-Region Replication (CRR) | DR Region bucket |
| DynamoDB | Point-in-time recovery + on-demand backups | DR Region |
| EFS | AWS Backup with cross-region copy | DR Region |
| Configuration | CloudFormation/Terraform templates in S3 | DR Region |
AWS Backup: Centralized Policy
AWS Backup provides a single place to manage backup policies across services:
Backup Plan
├── Rule: Daily backups (retain 30 days)
├── Rule: Weekly backups (retain 90 days)
├── Rule: Monthly backups (retain 1 year)
└── Cross-region copy: All backups → DR region
Recovery Process
- Deploy infrastructure from IaC templates (CloudFormation/Terraform)
- Restore data from latest backups
- Update DNS to point to new resources
- Validate application health
- Redirect traffic
When to Use
- Non-critical workloads where hours of downtime are acceptable
- Development/staging environments
- Compliance archives (data must exist in DR, but recovery speed isn't critical)
- Tightest budget constraints
Strategy 2: Pilot Light
RTO: 10 minutes - 1 hour | RPO: Minutes | Cost: Low-Medium
Keep the core infrastructure "lit" in the DR region — databases replicated, AMIs ready — but no compute running until needed. On failover, spin up compute and scale.
What's Always Running (the "pilot light")
- RDS read replica or Aurora Global Database (data continuously replicated)
- Core networking (VPC, subnets, security groups, Transit Gateway attachments)
- IAM roles and policies
- Route53 health checks monitoring primary region
What Starts on Failover
- EC2 instances (launch from pre-configured AMIs or Auto Scaling Groups)
- ECS/EKS services (scale from 0 to required capacity)
- Load balancers (ALB/NLB with target groups)
- Caches (ElastiCache — cold start, data rebuilds from DB)
Architecture
PRIMARY REGION DR REGION (Pilot Light)
┌─────────────────┐ ┌─────────────────┐
│ EC2 / ECS │ │ (Stopped/Zero) │
│ ALB │ │ (No ALB yet) │
│ RDS Primary │───replication────→ │ RDS Replica │
│ ElastiCache │ │ (Not running) │
│ S3 Bucket │───CRR───────────→ │ S3 Bucket │
└─────────────────┘ └─────────────────┘
│ │
Route53 ─── health check fails ──→ trigger failover
Failover Automation
Route53 health check fails
│
▼
EventBridge rule triggers
│
▼
Step Function: DR Failover
├── Promote RDS replica to primary
├── Launch EC2 / scale ECS to target capacity
├── Create ALB + register targets
├── Wait for health checks to pass
└── Update Route53 to DR region endpoints
Strategy 3: Warm Standby
RTO: Minutes | RPO: Seconds | Cost: Medium-High
A scaled-down but fully functional copy of your production environment runs in the DR region at all times. On failover, scale up to full production capacity.
What's Always Running
- Full application stack at reduced scale (e.g., 1 instance instead of 10)
- Database with synchronous or near-synchronous replication
- Load balancers actively health-checking
- Caches warm with subset of data
- Background workers at minimum capacity
Architecture
PRIMARY REGION (Full Scale) DR REGION (Warm Standby)
┌──────────────────────┐ ┌──────────────────────┐
│ ALB (100% traffic) │ │ ALB (0% traffic) │
│ EC2: 10 instances │ │ EC2: 2 instances │
│ RDS Multi-AZ │──async repl──→ │ RDS Read Replica │
│ ElastiCache 3-node │ │ ElastiCache 1-node │
│ Workers: 5 │ │ Workers: 1 │
└──────────────────────┘ └──────────────────────┘
Failover Process
- Route53 weighted routing shifts traffic (or health check triggers automatic failover)
- Auto Scaling scales DR from warm (2 instances) to hot (10 instances)
- RDS replica promoted to primary (Aurora Global: ~1 minute)
- Caches warm up from database (transient latency spike)
- Full production capacity achieved in minutes
Key Services for Warm Standby
| Service | DR Capability |
|---|---|
| Aurora Global Database | <1 second replication lag, ~1 minute failover |
| DynamoDB Global Tables | Multi-region active-active replication |
| ElastiCache Global Datastore | Cross-region Redis replication |
| S3 Cross-Region Replication | Continuous object replication |
| ECS/EKS | Scale from minimum to target in DR region |
Strategy 4: Multi-Site Active-Active
RTO: Near-zero | RPO: Near-zero | Cost: Highest
Both regions serve production traffic simultaneously. No failover required — if one region fails, the other absorbs traffic automatically.
Architecture
┌──────────────┐
│ Route53 │
│ (Latency or │
│ Weighted) │
└──────┬───────┘
│
┌────────────┼────────────┐
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ REGION A (Active)│ │ REGION B (Active)│
│ ALB + EC2/ECS │ │ ALB + EC2/ECS │
│ Aurora Global │◄────►│ Aurora Global │
│ DynamoDB Global │◄────►│ DynamoDB Global │
│ ElastiCache │◄────►│ ElastiCache │
└──────────────────┘ └──────────────────┘
Design Challenges
| Challenge | Solution |
|---|---|
| Data conflicts | DynamoDB Global Tables (last-writer-wins) or application-level conflict resolution |
| Session state | Stateless applications + DynamoDB/ElastiCache for session store |
| Database writes | Aurora Global: single writer region with read replicas, or DynamoDB Global Tables for multi-writer |
| Data consistency | Eventual consistency between regions (acceptable for most workloads) |
| Cost | 2x infrastructure — only justified for business-critical, zero-downtime requirements |
AWS Elastic Disaster Recovery (DRS)
For lift-and-shift DR of EC2 workloads and on-premises servers, AWS Elastic Disaster Recovery provides continuous block-level replication:
- Continuous replication — sub-second RPO via block-level data sync
- No impact on source — lightweight agent, no snapshots needed
- Point-in-time recovery — recover to any point within retention window
- Automated failover — launch recovery instances with pre-configured settings
- DR drills — test recovery without impacting production
- Supports up to 3,000 servers per target account
DRS Architecture
Source Region/On-Prem DR Region
┌─────────────────┐ ┌─────────────────┐
│ Source Server │ │ Staging Area │
│ (DRS Agent) │──continuous─→│ (Low-cost EBS) │
│ │ replication │ │
└─────────────────┘ │ On failover: │
│ Launch recovery │
│ instances with │
│ correct config │
└─────────────────┘
When to Use DRS vs Native DR
| Workload | Use DRS | Use Native DR |
|---|---|---|
| Legacy EC2 apps (no IaC) | ✅ | Hard to rebuild |
| On-premises servers | ✅ | Not applicable |
| RDS databases | ❌ | Cross-region replicas |
| Containerized apps (ECS/EKS) | ❌ | Redeploy from images |
| Serverless (Lambda, Step Functions) | ❌ | Multi-region deploy from IaC |
AWS Resilience Hub: Validate Your DR
Resilience Hub continuously assesses whether your applications meet RTO/RPO targets:
- Define application — map resources and their dependencies
- Set targets — specify RTO/RPO per application tier
- Assess — Resilience Hub evaluates your architecture against targets
- Recommendations — suggests improvements (add cross-region replication, implement multi-AZ, etc.)
- Drift detection — alerts when changes degrade resilience posture
Service-Specific DR Patterns
| Service | DR Pattern | RPO | RTO |
|---|---|---|---|
| Aurora | Global Database (read replicas in DR) | ~1 second | ~1 minute |
| RDS | Cross-region read replica + promotion | Minutes | Minutes |
| DynamoDB | Global Tables (multi-region active) | Near-zero | Near-zero |
| S3 | Cross-Region Replication | Minutes | Seconds |
| EFS | AWS Backup + cross-region restore | Hours | Hours |
| ElastiCache Redis | Global Datastore | Seconds | Minutes |
| Lambda | Multi-region deploy from CI/CD | Near-zero | Near-zero |
| ECS/EKS | Multi-region service with Route53 | Depends on DB | Minutes |
| SQS/SNS | Recreate from IaC (stateless) | N/A | Minutes |
DR Strategy Selection Framework
START
│
├── Can you tolerate hours of downtime?
│ └── YES → Backup & Restore ($)
│
├── Need recovery in under 1 hour?
│ └── YES → Pilot Light ($$)
│
├── Need recovery in minutes?
│ └── YES → Warm Standby ($$$)
│
└── Need zero downtime?
└── YES → Active-Active ($$$$)
Per-workload approach: Most organizations use different strategies for different tiers:
- Tier 1 (revenue-generating): Active-Active or Warm Standby
- Tier 2 (business operations): Pilot Light
- Tier 3 (internal tools): Backup & Restore
DR Testing: The Part Everyone Skips
A DR plan that hasn't been tested is a DR plan that doesn't work. Schedule regular drills:
- Monthly: Verify backups are restorable (pick random backup, restore, validate data)
- Quarterly: Pilot Light / Warm Standby failover drill (trigger failover, measure RTO)
- Annually: Full region failover exercise (for Active-Active workloads)
Use DRS non-disruptive drills — launches recovery instances in isolation without affecting production or replication.
Automate with Resilience Hub — define test schedules, track results, alert on degradation.
Summary
AWS DR isn't one-size-fits-all. Match strategy to business criticality:
- Backup & Restore — hours of RTO, lowest cost. Use for non-critical workloads.
- Pilot Light — database replicated, compute on-demand. 10 min - 1 hour RTO.
- Warm Standby — scaled-down copy always running. Minutes RTO.
- Active-Active — both regions serve traffic. Near-zero RTO/RPO. 2x cost.
The critical success factors:
- Automate failover — manual runbooks at 3 AM don't work. Step Functions + Route53 health checks.
- Test regularly — monthly backup validation, quarterly failover drills.
- Use Resilience Hub — continuous validation that architecture meets RTO/RPO targets.
- Tier your workloads — not everything needs active-active. Spend where it matters.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS infrastructure automation and resilient cloud architecture. Connect on LinkedIn.
Top comments (0)