How do you design a multi-region disaster recovery architecture on AWS?

Designing multi-region disaster recovery (DR) on AWS requires understanding two critical metrics: Recovery Time Objective (RTO) — how long you can afford to be down, and Recovery Point Objective (RPO) — how much data you can afford to lose. A payment processing system might need RTO of 30 seconds and RPO of zero. A marketing analytics dashboard might tolerate RTO of 4 hours and RPO of 24 hours. These requirements drive the architecture and cost.

AWS defines four DR strategies, each increasing in cost and decreasing in recovery time

Backup and Restore is the simplest and cheapest. You regularly back up data to another region — S3 Cross-Region Replication for objects, RDS automated backups or snapshots copied cross-region, DynamoDB global tables or point-in-time recovery exports, and AMI copies for EC2 configurations. During a disaster, you spin up infrastructure from these backups. Think of it like having a storage unit in another city with copies of all your important documents — if your house burns down, you can rebuild, but it takes days. RTO is typically 4-24 hours. RPO depends on backup frequency — if you back up hourly, you lose up to an hour of data. Cost is minimal because you only pay for storage in the secondary region.

Pilot Light keeps the minimal core infrastructure running in the DR region — typically just databases with continuous replication. Application servers, load balancers, and other compute resources are pre-configured but not running. Think of it like a gas stove with the pilot light always burning — you can fire up the full flame quickly but it is not heating anything until you turn the knob. During failover, you launch the pre-configured compute resources (from AMIs or Infrastructure as Code), update DNS, and the application comes online. RTO is typically 10-30 minutes. RPO depends on replication lag, usually seconds to minutes with asynchronous replication.

Warm Standby runs a fully functional but scaled-down copy of the production environment in the DR region. All components are active — web servers, application servers, databases — but at a fraction of production capacity. Think of it like having a fully furnished guest house that is smaller than your main house. During failover, you scale up the DR region to production capacity (Auto Scaling groups increase desired count), update DNS routing, and you are operational. RTO is typically 1-10 minutes. RPO is near-zero with synchronous or near-synchronous replication. The ongoing cost is significant — you are running infrastructure 24/7 in two regions.

Multi-Site Active/Active runs full production capacity in two or more regions simultaneously, with traffic split across them using Route 53 latency-based or geolocation routing. Both regions are serving live production traffic at all times. If one region fails, the other absorbs all traffic. Think of it like having two fully staffed offices — if one office has a fire, the other seamlessly handles all customers. RTO is near-zero (just DNS failover time, typically 30-60 seconds). RPO is zero with DynamoDB Global Tables or Aurora Global Database. The cost is roughly double because you run full capacity in both regions.

Critical components of any multi-region DR architecture

DNS failover with Route 53 health checks is the traffic steering mechanism. Route 53 monitors endpoints in both regions and automatically shifts traffic when the primary fails. For Active/Active, use latency-based routing. For Active/Passive, use failover routing.

Data replication strategy depends on the database. Aurora Global Database provides cross-region replication with under 1 second lag and supports managed failover. DynamoDB Global Tables provide active-active multi-region replication with eventual consistency. RDS read replicas can be promoted to standalone instances during failover, but this is a manual process.

Infrastructure as Code (Terraform or CloudFormation StackSets) ensures both regions have identical infrastructure definitions. Never manually configure the DR region — drift between regions is the number one cause of DR failures.

Regular DR testing is non-negotiable. Chaos engineering tools like AWS Fault Injection Simulator (FIS) can simulate region-level failures. Many organizations discover during an actual disaster that their DR plan does not work because they never tested it. Netflix's Chaos Monkey philosophy applies here — if you have not tested your failover, you do not have a failover.