On this page
The most over-engineered decision in the cloud
Someone in a planning meeting says "we should be multi-region." It sounds unarguable, who's going to advocate for being *less* resilient? So the team commits, and six months later they're drowning in replication lag bugs, doubled infrastructure bills, and a failover process nobody trusts. Meanwhile the actual uptime requirement could have been met by Multi-AZ in a single region for a tenth of the cost.
Multi-region is sometimes exactly right. For a global product, a payments platform, or anything where a regional outage is an existential event, it's non-negotiable. But it is never free, and the costs are mostly hidden until you're deep in. This article is the honest version: what multi-region actually costs, the two architectures (active-passive and active-active), and a clear test for whether you genuinely need it or are about to over-engineer.
Who this is for
Engineers and architects weighing a multi-region build, or maintaining one and wondering why it's so painful. You should understand regions, availability zones, and database replication. Read [HA & DR (RTO/RPO)](/blog/high-availability-disaster-recovery-rto-rpo) first if those terms aren't second nature.
What multi-region actually means
Multi-region architecture means running your system across two or more geographically separate regions, so the failure of an entire region, or distance from your users, doesn't take you down.
There are two distinct reasons to go multi-region, and confusing them leads to building the wrong thing:
Resilience-driven multi-region is about disaster recovery: a standby region that takes over if the primary dies. Latency-driven multi-region is about putting compute close to a global user base so a user in Sydney isn't routed to Virginia. They lead to different designs, and the hardest part of both, keeping data consistent across thousands of miles, is identical.
Active-passive vs active-active
Two fundamental shapes. Active-passive is simpler and cheaper and covers most resilience needs. Active-active is the full global build, more capable, dramatically harder.
| Active-passive | Active-active | |
|---|---|---|
| Traffic | One region serves; other on standby | Both regions serve live traffic |
| Data flow | One-way replication (primary→standby) | Multi-directional, both regions write |
| Hardest problem | Failover reliability | Write conflict resolution |
| Latency benefit | None (single active region) | Yes, users hit the nearest region |
| Cost | Standby infra (often scaled down) | Full capacity in every region |
| Use it for | DR with low/zero RPO needs | Global products needing low latency everywhere |
The killer difference is in the data layer. Active-passive has one writer, so there are no conflicts, the standby just receives a replication stream. The risk is concentrated in failover: can you promote the standby cleanly and fast? Active-active has multiple writers, which means two regions can modify the same record simultaneously and you must resolve the conflict. That's a genuinely hard distributed-systems problem, and it's why most teams that *think* they need active-active actually need active-passive.
Active-active with global routing
When you do need active-active, a global product where Sydney and London users both deserve low latency, it looks like this: a global router (latency-based DNS or anycast) sends each user to their nearest region, both regions serve full traffic, and the data layer replicates bidirectionally with a conflict-resolution strategy underneath.
Active-active across two regions. Latency-based global routing sends each user to their nearest region; both serve full live traffic. The data layer replicates bidirectionally (dashed), which is exactly where conflict resolution and consistency trade-offs live.
- 1
A user makes a request
The global router resolves to the region with the lowest latency for that user, EU users land in eu-west-1, US users in us-east-1. This is the latency win that justifies active-active.
- 2
The nearest region serves it fully
Each region has a complete stack, load balancer, app tier, database. The request is handled locally, end to end, with no cross-region hop on the hot path.
- 3
Writes replicate across regions
A write in EU must eventually appear in US and vice versa. This replication is asynchronous, so for a window the regions disagree, the source of eventual-consistency behaviour your app must tolerate.
- 4
Conflicts get resolved
If both regions write the same record in that window, a strategy decides the winner, last-write-wins, CRDTs, or app-level merge. Getting this right is the entire difficulty of active-active.
Pro tip
Before going active-active on your primary database, ask whether you can keep a single-writer region for transactional data and only replicate read-heavy or naturally-partitioned data globally. Most apps have far less truly-global mutable state than they assume, and sidestepping write conflicts is worth a lot.
Do you actually need it? A decision test
Before committing, run these questions honestly. If you're answering "well, it'd be nice" rather than "yes, with a number attached," you're probably over-engineering.
- Does your RTO/RPO actually require surviving a full region loss? Get the business to confirm in real money. Many "critical" systems are fine with a few hours of region-outage downtime, which Multi-AZ plus a backup-and-restore DR plan handles far cheaper.
- Is your user base genuinely global with latency complaints? If 95% of users are in one geography, multi-region for latency is solving a problem you don't have. A CDN at the edge probably gets you most of the win.
- Can your data model tolerate eventual consistency? If your domain demands strong consistency on every write (think account balances), active-active is a research project, not a sprint. Be honest about this before you start.
- Do you have the operational maturity to run two regions? If you're not already running solid observability, automated deploys, and regular game days, multi-region will amplify every operational weakness you have.
Pro tip
The cheap middle ground most teams skip: Multi-AZ in your primary region for HA, plus backup-and-restore or pilot-light DR into a second region. You get region-failure survival without paying the active-active consistency tax. Reach for full multi-region only when the decision test above genuinely says yes.
Takeaways
The whole article in eight lines
- Multi-region is sometimes essential and usually over-chosen. Default to skepticism.
- Two reasons to go multi-region: resilience (survive a region) and latency (serve users close).
- The hidden costs are data consistency, cross-region egress, doubled infra, failover trust, and an operational tax.
- CAP is not optional: across regions, a partition forces you to choose availability or consistency.
- Active-passive = one writer, simple, solves resilience. Active-active = multiple writers, hard, also solves latency.
- The difficulty of active-active is write-conflict resolution, not the routing.
- Most teams that think they need active-active actually need active-passive or just Multi-AZ + DR.
- Run the decision test in real money. "It'd be nice" is not a reason to double your bill.
Where to go next
Multi-region only makes sense once your single-region HA and DR story is solid. Build down before you build out.
- Designing for HA & DR (RTO/RPO), the resilience foundation and the cheaper alternatives to multi-region.
- Multi-region (concept lab), hands-on routing and replication patterns.
- How Netflix built its streaming pipeline, a real global, multi-region system at extreme scale.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.