How to set up multi-region disaster recovery on AWS

Start here

Decide how long you can be down and how much data you can lose, then buy the cheapest topology that meets those two numbers. Most teams do the reverse: they pick active-active because it sounds strongest, discover the cost and the write-conflict problem six weeks in, and end up with a half-built second region that has never been tested. Multi-AZ inside one region already survives the failure mode you are most likely to hit. A second region is for the case where the whole region goes, and that case has to be worth paying for.

The rest of this page is how I approach it, drawn from a QSR e-commerce order pipeline doing 5M+ orders a month, built active-passive across a primary and a standby region with a global control plane that moves traffic.

Start with RTO and RPO, not topology

RTO is how long the business can be down. RPO is how much data it can afford to lose. Every architecture decision below follows from those two numbers, and they are business decisions, not engineering ones. Set them per workload and get them in writing. Order capture and a nightly analytics job almost never deserve the same targets, and pretending they do is how a DR budget triples. When someone asks for zero on both, price the two designs and let the number make the argument for you.

Write them down per workload before anyone opens a diagramming tool. A DR design without stated targets cannot be reviewed, because there is no way to tell whether it is over-built or under-built.

The four patterns, and their real cost

Backup and restore is the cheapest: snapshots replicated to a second region, infrastructure rebuilt from code when you need it. RTO is measured in hours, which is fine for a workload that can be down that long. Pilot light keeps the data layer replicating and the compute switched off, so you pay for storage and replication but not idle servers. Warm standby runs a scaled-down copy of everything, so failover means scaling up what is already running. That buys you minutes where pilot light costs you hours. Active-active serves from both regions at once and removes failover time entirely, at the price of solving write conflicts and testing twice the surface.

The honest cost comparison is not the AWS bill alone. Every pattern past backup and restore adds a second copy of your IAM, your secrets, your network, and your deploy pipeline, and all of it has to stay in step with the primary. That ongoing drift is the real expense, and it is the reason a pattern you can actually maintain beats a stronger one you cannot.

Replication, and the RPO you get

Every region can run the same code. None of them can invent data they never received, which is why replication design decides what your RPO actually is rather than what you wrote down. On the QSR pipeline the data layer is the part that earns the design: DynamoDB global tables replicate the order state across regions, Aurora runs a cross-region replica, and a multi-region KMS key means the standby region can actually decrypt what it receives. That last one is a detail teams miss until the failover test fails: replicated ciphertext is useless in a region that cannot reach the key.

Match the replication mechanism to the RPO you agreed. Asynchronous replication means a non-zero RPO by definition, and you should know roughly what the replication lag is under load, not at idle. If the business genuinely needs zero data loss, that is a much more expensive conversation involving synchronous writes and the latency they add to every request.

Making failover automatic

A failover that depends on a person being awake is not a failover. On the QSR pipeline the control plane is explicit about this: CloudWatch raises the alarm, EventBridge routes it as a failover trigger, and a dedicated failover Lambda performs the Route 53 DNS update. CloudTrail records the whole thing. The point of that chain is not automation for its own sake; it is that the decision becomes an auditable event with a known code path, instead of an engineer editing a DNS record from a phone under pressure.

Give the same care to failing back. Returning to the primary region after it recovers is the step teams never write down, and it is the one where data written to the standby gets lost if nobody planned the reconciliation.

A reference active-passive shape

The shape that has held up for me: CloudFront at the edge, a primary region carrying all writes, a standby region kept warm with the data replicating into it continuously, and a global control plane that sits outside both. Route 53 owns failover DNS. DynamoDB global tables and an Aurora cross-region replica carry the state. A multi-region KMS key makes the standby able to read it. CloudWatch, EventBridge, and a failover Lambda make the cutover a code path rather than a manual procedure, and CloudTrail keeps the audit trail across both.

Everything in that topology is defined in code and deployed to both regions by the same pipeline. If the standby is provisioned by hand, it will drift from the primary, and you will find out during the incident.

An untested DR plan is not a plan

Run the failover on a schedule, against production, and measure the real recovery time against your stated RTO. The first test always finds something: a region hardcoded in a config, an IAM role that only ever existed in the primary, a secret that was never replicated, a health check that passes while the application underneath is broken. Those are cheap findings in a drill and expensive ones at 3 AM.

The related discipline is deploy safety, because most outages are self inflicted, not regional. On the QSR migration a bad service release rolled back in under 30 seconds through blue-green with no customer impact. Fast rollback prevents far more downtime than a second region ever will, and it is a fraction of the cost. The overall design targets 99.99% through multi-AZ, blue-green, and observability-first design, with the second region reserved for the regional failure case.

When multi-region is the wrong answer

If you do not have multi-AZ, tested restores, and a rollback measured in seconds, a second region is the wrong next purchase. It roughly doubles the infrastructure you have to keep in step while doing nothing about the failure modes that actually take teams down: a bad deploy, an expired certificate, a saturated database, a dependency that has no timeout. I have seen more downtime caused by the complexity of an unfinished DR build than prevented by it. Fix the common failures first, then buy the second region when a regional outage is genuinely the thing that would end the business.

Where DR plans fall over

• Choosing a topology before anyone has written down RTO and RPO per workload.
• Replicating the data but not the KMS key, so the standby cannot decrypt it.
• Building the standby region by hand, so it drifts from the primary in silence.
• Automating failover and never planning the fail-back reconciliation.
• Health checks that pass while the application behind them is broken.
• Buying a second region before multi-AZ, tested restores, and fast rollback exist.
• Writing a DR runbook that nobody has ever executed end to end.