Designing Multi-Region Disaster Recovery on Amazon EKS
This design came out of an infrastructure assessment for a dealer-facing platform where downtime translates directly into lost transactions. The client's first question wasn't "how fast can it fail over" — it was "what happens if a whole AWS region has a bad day." That question shapes the entire architecture.
The constraint that shaped the design
Active/active across two regions is the more resilient answer on paper, but it means reconciling writes happening in two places at once — a real engineering cost, not just a bigger bill. For this workload's traffic pattern, that cost wasn't justified. I went with active/passive: one region takes all writes, the second stays warm and ready. The honest trade-off is that failover isn't instant — there's a cutover window, and I said so plainly in the Solution Design Document rather than letting the diagram imply otherwise.
Why EKS and Karpenter, not plain EC2 Auto Scaling
The workload is containerized microservices, which makes EKS the natural fit over managing EC2 fleets directly. I chose Karpenter over the standard Cluster Autoscaler because it provisions nodes faster and bin-packs more efficiently — during a traffic spike, the difference between Karpenter and a slower autoscaler is the difference between absorbing the spike and queuing requests behind it.
The database is the hard part
Primary Aurora in the active region, a cross-region read replica in the standby region. The caveat I make sure every client understands: cross-region Aurora replication is asynchronous. If the primary region fails hard, the replication lag window is your actual recovery point objective — it is not zero. Being upfront about that number, even when it's small, matters more than a diagram that quietly implies a lossless failover.
Guardrails around the edge
CloudFront and Route 53 handle global entry and DNS failover, AWS WAF sits in front of the ALB, and the workload reaches AWS services through VPC endpoints instead of the public internet where it doesn't need to.
Why CloudFormation and Terraform both appear on the diagram
CloudFormation StackSets handle the account and region guardrails that the client's Control Tower landing zone expects. Terraform owns everything at the workload layer — VPC, EKS, Aurora — because the application team needed a tool built for iterating on infrastructure, not one built for one-time account bootstrapping.
A DR design is only honest if you can say out loud what it doesn't protect against.
What I'd change with more budget
If the client's tolerance for data loss ever drops to near-zero, the next conversation is Aurora Global Database with tighter replication, or synchronous multi-region writes — at a materially higher cost. That trade-off, named out loud, is what a Well-Architected review is actually for: reliability is a thing you buy, at a price, on purpose.