The Only Honest Reason to Go Multi-Region on AWS

On a system I worked on, we ran a failover drill for a two-region setup. It worked. Traffic moved and the application kept serving. Then someone asked what had happened to the writes that were in flight when we cut over, and the room went quiet. Nobody had an answer, and it took a moment to realise that nobody had ever had one.

That second region existed for availability. Someone had declared a regional outage unacceptable, so a warm standby was built and sat idle long enough that the hardest question about it never came up. I've come to think the idleness is the whole problem. A second region that never takes real traffic lets a team postpone the data decision indefinitely, and a drill is where the postponement gets called in. So my position is narrower than the usual "you probably don't need multi-region." Run one region, or run two that both do real work. The warm standby in between is the worst of the three.

The availability case rests on a whole AWS region going dark. That happens, and us-east-1 has had days that took a good slice of the internet down with it. But it's rare next to the failures that actually reach most teams, which are one Availability Zone or one service wide. And when a whole region goes, so does half your vendor list, and that's the one outage users forgive.

The clearest recent example is the US-East-1 thermal event in May 2026. A cooling failure took down one AZ, and Coinbase's matching engine went with it, because all five of its Raft nodes were pinned to that zone for latency. Trading halted for hours. The fix was not a second region. It was the second AZ they had chosen not to use. Their case was harder than most, since they ran their own consensus cluster. For a stack like mine, ECS across zones and RDS with Multi-AZ, the same class of failure costs a checkbox and a bigger database bill.

Compute is the easy half of a second region. The hard half is the data, and it stays hidden until you're cut over. Every managed database option AWS sells for this is asynchronous: a cross-region Postgres read replica, Aurora Global Database, DynamoDB global tables. They differ in lag, and the newer ones keep it to a second or so, but the shape is the same. The standby is behind. A failover loses whatever hadn't crossed yet, and someone has to know how much and what to do about it.

"A second of writes" sounds like nothing until you ask which second. The orders placed in it. The user who saw a success page for a row that no longer exists. The team in that drill had no reconciliation plan for that, and the managed products don't come with one. They come with a small number and an implied shrug.

It's the shape I see most often when people draw multi-region setups in DesignBeaver, too: two regions and one arrow between the databases, with nothing on the diagram about what happens on that arrow. The compute is drawn carefully. The data is a line.

DesignBeaver runs in one region. ECS on Fargate across Availability Zones and RDS Postgres with Multi-AZ. Nothing in a second region. For a product with one engineer, that's the whole resilience budget, spent on the failure most likely to happen.

The honest gap is that I've never forced a Multi-AZ failover on purpose to watch what the application does while the standby is promoted. Which means my single-region story is exactly as tested as that two-region system was before the drill. I'd rather spend an afternoon on that than a quarter on a second region.

There is one reason to go multi-region that I'd defend without hedging, and it's latency. If a real cohort of your users is far enough from your region that they feel the round trip on every request, that's a measurable fact about physics. You can measure it today, and the number doesn't depend on an outage that may never come.

Latency-driven multi-region also forces the right design. Serving users locally means both regions take real traffic from day one, so where writes live and how they reconcile has to be answered before launch. Data residency works the same way for legal reasons rather than physical ones: a rule about which users' data lives where forces the partitioning decision up front. Both are honest because both make you decide.

Availability-driven multi-region makes you decide nothing, because the second region never does anything, and that is the whole of its appeal.

If your justification is availability, take the second region off the diagram and spend the afternoon it frees on two things: forcing a Multi-AZ failover, and restoring a backup into a fresh account end to end. If a customer contract demands a DR region anyway, build it and call it what it is, a sales asset, and don't let anyone on the team believe it's resilience.

If your justification is latency, you didn't need this post. Your users have been making the case for you.

Multi-region is a latency tool that's been sold as a resilience tool. Buy it for the first reason or don't buy it.