Multi-cloud Active-Active

Write-global, write-local, write-partitioned. The three real choices for cross-region writes.

Overview

Writes are the hard part

True multi-cloud active/active is rare; most "multi-cloud" deployments are one primary cloud plus one DR target. When you do go fully active/active, the traffic split is the easy part: global load balancers (AWS Global Accelerator, GCP Global LB, Azure Front Door, Cloudflare) handle it. The hard problem is that every region accepts writes. How do they reconcile?

Three write strategies (AWS DR whitepaper)

None is free. Pick the one that matches your data model.

  • Write-global — All writes go to one Region; others are read-only — Aurora Global Database and similar — Writers in non-primary regions pay cross-region RTT
  • Write-local — Writes go to the nearest region; replication is last-writer-wins (LWW) — DynamoDB Global Tables and similar — Concurrent writes to one key in two regions silently overwrite by timestamp. Fine when conflicts are rare, not for critical state
  • Write-partitioned — Each partition key has a home region; all its writes route there — Sharded multi-region setups — Routing layer becomes the SPOF; cross-partition transactions are expensive or impossible

Cross-region traffic primitives

  • Global LBs / Anycast — AWS Global Accelerator, GCP Global LB, Azure Front Door, Cloudflare — IP-level anycast routes the user to the nearest healthy region
  • DNS-based failover — Route 53 with health checks; AWS ARC — ARC gives data-plane failover that avoids the regional control plane during a regional incident
  • CDN origin failover — CloudFront origin failover — Routes around bad origins automatically

> [!TIP] Pick the write strategy first. The traffic layer is a solved problem; the data model is not.

Key concepts

Write-global
All writes to one region; others read-only. Conflict-free, cross-region writers pay RTT. e.g. Aurora Global Database.
Write-local
Writes go to nearest region; conflict resolution by last-writer-wins. Fast but lossy on concurrent writes. e.g. DynamoDB Global Tables.
Write-partitioned
Partition key determines write region. No conflicts, routing layer becomes SPOF. Used by sharded deployments.
Anycast / Global LB
IP-level traffic routing to nearest healthy region. AWS Global Accelerator, GCP Global LB, Cloudflare. The transport layer; doesn't solve writes.
AWS Application Recovery Controller (ARC)
Data-plane failover service. Avoids dependency on regional control plane during incidents — critical because the control plane itself can be the thing that's failing.

When to use it

  • Every active/active design — pick the write strategy before drawing diagrams
  • Data model reviews — does the application tolerate LWW conflicts? If no, write-local is wrong.
  • Cost reviews of multi-cloud — multi-region write infra is the biggest line item, validate the choice
  • Capacity planning — write-global means write capacity is bottlenecked by one region

Interview questions

  • Walk me through the three multi-cloud write strategies and when you'd pick each.
  • Why is automatic regional failover dangerous?
  • How do you handle the regional control plane being the thing that's failing?

Sign up free to read the full topic

More SRE topics

Start free on Cariara · Coding problems · System design studio