Key Takeaways
- High availability (HA) protects against component-level failure within a region (AZ outage); disaster recovery (DR) protects against regional or catastrophic failure.
- Your RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets determine which of AWS's four DR strategies — backup & restore, pilot light, warm standby, or multi-site active-active — fits your workload.
- A true multi-region architecture requires data replication (DynamoDB Global Tables, Aurora Global Database, S3 Cross-Region Replication) and traffic routing (Route 53 failover or latency-based routing) working together.
- Multi-AZ is not the same as multi-region — Multi-AZ protects against data center-level failure; multi-region protects against regional AWS service disruption.
- Regularly test your failover, not just design it — an untested DR plan is a hypothesis, not a plan.
Business continuity planning on AWS comes down to one question: how much downtime and data loss can your business tolerate, and how much are you willing to pay to reduce it? This guide walks through the standard AWS DR strategies and the architecture choices behind each.
RTO and RPO: The Two Numbers That Drive Everything
- RTO — how long can the system be down before it's unacceptable?
- RPO — how much data can you afford to lose (measured in time since last successful backup/replication)?
Lower RTO/RPO costs more — both in infrastructure spend and architectural complexity. There's no universally "right" answer; it's a business risk decision.
The Four AWS DR Strategies
1. Backup and Restore
Lowest cost, highest RTO/RPO. Regular backups (AWS Backup, S3, EBS snapshots) stored in a second region; infrastructure is provisioned only when disaster strikes.
2. Pilot Light
Core infrastructure (databases, critical config) runs at minimal scale in the DR region continuously; compute scales up only on failover.
3. Warm Standby
A scaled-down but fully functional copy of the full environment runs continuously in the DR region, ready to scale up and take full traffic.
4. Multi-Site Active-Active
Full production capacity runs simultaneously in two or more regions, with traffic routed to both under normal operation. Lowest RTO/RPO, highest cost and complexity.
Route 53 Failover Configuration
aws route53 create-health-check \
--caller-reference primary-health-check-2025 \
--health-check-config '{
"Type": "HTTPS",
"ResourcePath": "/health",
"FullyQualifiedDomainName": "primary.example.com",
"Port": 443,
"RequestInterval": 30,
"FailureThreshold": 3
}'
aws route53 change-resource-record-sets \
--hosted-zone-id Z1D633PJN98FT9 \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "primary",
"Failover": "PRIMARY",
"HealthCheckId": "abc123-health-check-id",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "primary-alb-123.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}]
}'DynamoDB Global Tables for Multi-Region Data
aws dynamodb create-global-table \
--global-table-name OrdersTable \
--replication-group RegionName=us-east-1 RegionName=eu-west-1This gives you active-active, multi-region replicated DynamoDB tables with last-writer-wins conflict resolution — a key building block for warm standby and active-active architectures.
Terraform: Aurora Global Database
resource "aws_rds_global_cluster" "global" {
global_cluster_identifier = "app-global-db"
engine = "aurora-postgresql"
engine_version = "15.4"
}
resource "aws_rds_cluster" "primary" {
cluster_identifier = "app-primary"
engine = "aurora-postgresql"
engine_version = "15.4"
global_cluster_identifier = aws_rds_global_cluster.global.id
master_username = "admin"
master_password = var.db_password
}
resource "aws_rds_cluster" "secondary" {
provider = aws.eu_west_1
cluster_identifier = "app-secondary"
engine = "aurora-postgresql"
engine_version = "15.4"
global_cluster_identifier = aws_rds_global_cluster.global.id
}Multi-AZ vs. Multi-Region: Don't Confuse Them
Multi-AZ (e.g., RDS Multi-AZ, ALB across 3 AZs) protects against a single data center failure within a region — AWS handles most of this automatically for managed services. Multi-region protects against a regional-scale event (rare, but not impossible) and requires you to design the replication and failover yourself.
Most workloads need solid Multi-AZ architecture as the baseline. Multi-region is an additional investment justified by business-critical RTO/RPO requirements, not a default.
Testing: The Step Most Teams Skip
Run scheduled failover drills (AWS Fault Injection Simulator helps here), measure actual RTO/RPO against targets, and fix gaps before a real incident reveals them. A DR architecture diagram with no test history is unproven.
FAQ
Q: What's the difference between high availability and disaster recovery? A: HA handles routine, smaller-scale failures (an AZ outage) automatically within a region. DR handles larger-scale, less frequent events (regional outage) and typically requires explicit failover action.
Q: Which DR strategy should I start with? A: Backup and restore for most non-critical workloads; pilot light or warm standby once RTO requirements drop below a few hours; active-active only for mission-critical, revenue-impacting systems.
Q: Does S3 Cross-Region Replication happen automatically? A: No — it must be explicitly configured on the bucket with a replication rule; it's not enabled by default.
Q: How often should DR failover be tested? A: At minimum quarterly for warm standby/active-active architectures; annually at a minimum for pilot light and backup/restore tiers.
Design a DR Strategy That Matches Your RTO/RPO
F9infotech's AWS architecture team assesses your continuity requirements and designs the right-sized DR strategy — from backup and restore to full multi-region active-active. Talk to our team about your business continuity plan.