Architecture patterns
Multi-region architecture
Active-passive, active-active and cell-based designs for latency, disaster tolerance and data residency, with the recovery, consistency and cost trade-offs each one carries.
A single cloud region is already redundant. Its availability zones are separate data centers with independent power and networking, a few kilometers apart, so a service spread across three zones survives a data-center fire. What a single region does not survive is the whole region having a bad day: a control-plane bug, a regional DNS failure, a bad configuration push. These are rare, but every provider has them. On October 20, 2025, a DNS automation problem affecting DynamoDB's regional endpoint in AWS us-east-1 cascaded into hours of disruption for many services that depended on that region.
Going multi-region means running the system in two or more regions, so it survives a regional failure, serves users closer to where they are, or keeps data inside legal borders. It is also one of the most expensive and complex things an engineering organization can take on. The pages below start with why, then cover the main patterns, how globally consistent databases fit, how cells limit blast radius, and why an untested failover plan is close to no plan at all.
Concepts in this section
| Step | Concept | What it answers |
|---|---|---|
| 1 | Why go multi-region | What do you gain, and what does it cost? |
| 2 | Active-passive, RPO and RTO | How much is lost, and how long are you down, if one region fails? |
| 3 | Active-active and home regions | Where do writes go when every region is live? |
| 4 | Globally consistent databases | Which data must be consistent everywhere, and what does that cost? |
| 5 | Cells and regional isolation | How do you limit the damage from your own changes? |
| 6 | Failover testing | How do you know failover will work? |
Common mistakes
- Going multi-region without a requirement. Name the target: an availability number, a latency budget or a residency rule.
- Calling another region in the request path. A synchronous cross-region call adds about 80 ms and ties the two regions' availability together.
- Forgetting the copies of data. Residency covers every replica, backup, log and search index, not only the primary database.
- Never failing over. Replication can break quietly, and standby capacity drifts. Find that out in a drill, not in an outage.
Key takeaways
- Start with multiple zones. Go multi-region when a specific requirement demands it.
- Active-passive is simpler. Its RPO equals replication lag, and its RTO is set by detection and decisions.
- Active-active usually partitions writes by home region, which avoids write conflicts.
- Globally consistent databases pay at least one cross-region round trip per write, so use them only where needed.
- Cells and failover drills limit the blast radius and prove the plan works.
Further learning
This AWS re:Invent session covers current best practice for multi-region design, including when not to do it and how to structure failover.
An older talk walks through building an active-active architecture step by step, covering replication and routing choices.
Start with why go multi-region.
Related
Replication
Keeping copies of the same data on several machines, the three topologies that databases use, and the anomalies that replication lag causes. Start here for the replication map.
Disaster recovery and chaos engineering
RPO and RTO, backups that restore, game days and region drills, and deliberate failure injection, so confidence comes from measured recovery. Start here for the map of disaster recovery pages.
CAP, PACELC and consistency models
What "consistent" means once data lives on several replicas, from linearizable to eventual, what each guarantee costs, and how to pick one per feature.