A second region protects against a regional failure only if nothing on the recovery path still depends on the first one, and it is not cheap: AWS’s own guidance says a hot standby roughly doubles the cost and that most availability and RTO/RPO goals can be met inside one region. When the goal really needs two, the first design question is not “active/active or active/passive” but for each dataset, which region may accept writes right now, and how every other region knows it. Replication lag, conflicts and split brain all follow from that answer.
| Topology | Who accepts writes | Data at risk on regional loss | What you must build |
|---|---|---|---|
| Active/passive, async replication | One primary region | Writes not yet replicated; they are stranded until the old region returns | Promotion with fencing of the old primary, reconciliation of stranded writes, rehearsed failback |
| Partitioned ownership (region as a cell) | Each shard's home region | Unreplicated writes of the shards homed in the failed region only | Shard-aware routing, per-shard failover; a regional failure hits only the shards homed there |
| Active/active, async, multi-writer | Any region | Unreplicated writes, plus concurrent writes silently resolved by the conflict rule | A conflict rule the business accepts (last writer wins drops one update), idempotent writes, invariants that hold per region |
| Synchronous quorum across three regions | Any region, via the quorum | None for acknowledged writes (RPO zero) | Cross-region round trips on every write, a third region or witness, retries on write conflicts |
Failover is a split-brain problem. Promoting the standby while the old primary may still be alive and reachable by some clients produces two writers. DNS does not fence: answers are cached, and a client that already resolved the old address keeps using it. The promoted side needs an epoch that the storage itself checks, or the old primary must be made unable to accept writes before promotion (66). In an active/active table the equivalent trap is quieter: DynamoDB global tables in the default eventual mode resolve concurrent updates of one item by the latest timestamp, and their transactions are atomic only inside the region that ran them — a cross-row invariant from 90 does not survive the trip.
The recovery path must not live in the failed region. AWS’s example: the Route 53 control plane is hosted in us-east-1, so a failover that needs a DNS record change is a poor mechanism when the primary is us-east-1. Prefer pre-provisioned capacity and switches that need no control-plane change on the recovery path (101); keep certificates, keys, secrets and parameters region-local, with staggered expiry so one renewal failure cannot hit both; forbid cross-region calls inside a user journey and fail the whole journey over together. Deploy one region at a time, so a bad release cannot take both (27, 72).
Decision rule. Start from per-workload RTO and RPO (97). If waiting out a regional outage meets them, stay in one region with backups in another. Otherwise pick the simplest row of the table that meets the RPO, write down who owns each dataset’s writes and how ownership moves, monitor replication lag as an SLI, and keep the failover automated but the decision human. A failover that has not been run — both ways, with the same runbook as in a real event — is a hope, not a capability.