Single-Region vs Multi-Region Deployment

TL;DR. Single-region multi-AZ is the correct default. It gives you strong consistency, sub-millisecond cross-AZ replication, and one deployment pipeline. Multi-region is the single most expensive architectural choice available: 2-3x infrastructure cost, 10-20% of your AWS bill in cross-region transfer alone^[1], and mandatory conflict resolution or cross-region consensus latency (68-110 ms per RTT^[2]). Go multi-region only when RTO requirements, global latency SLOs, or data-residency regulations force it. When you do, prefer regional pinning over true active-active.

Learning Objectives#

• Compare single-region multi-AZ, active-passive, active-active, and regional pinning across RTO, RPO, cost, and consistency dimensions.
• Identify the workload characteristics that justify the cost and complexity of multi-region deployment.
• Justify regional pinning as the hybrid path that delivers multi-region availability without conflict resolution.
• Evaluate Netflix, Shopify, and the 2021 us-east-1 outage to explain when each approach succeeds or fails.

The Core Trade-off#

The fundamental tension is physics. A round trip between us-east-1 and eu-west-1 is 68 ms; to eu-central-1, 91 ms; to eu-north-1, 110 ms^[2:1]. Any protocol requiring cross-region acknowledgment on the write path adds that latency to every commit. You choose one of three responses:

1. Keep writes local, accept eventual consistency (DynamoDB Global Tables MREC, Cassandra LOCAL_QUORUM). Writes are fast; conflicts are your problem.
2. Pay the cross-region round trip for strong consistency (Spanner, CockroachDB REGION survival, DynamoDB MRSC). Writes are slow; correctness is guaranteed.
3. Pin each user to one region so cross-region writes never happen (Shopify pods, Stripe regional pinning). Writes are fast and consistent; cross-user analytics are eventually consistent.

The metric that moves in opposite directions: as you widen your deployment geography, write latency rises or consistency weakens. You cannot have both low latency and strong consistency across regions. CAP and PACELC formalized this; deployment geography is where you live with the consequences.

The deployment geography spectrum: each step right trades more money and complexity for a smaller blast radius or lower global latency.

Side-by-Side Comparison#

The table misleads on RTO. "Hours to days" for single-region assumes you have no DR at all. Adding Aurora Global Database (active-passive warm standby) drops RTO to a few minutes^[7:1] without the full complexity of active-active. Most teams should evaluate the middle tiers before jumping to the rightmost column.

The cost row understates the real expense. Cross-region data transfer alone can account for 10-20% of a replicating architecture's total AWS bill per industry analysis^[1:2]. A 5 TB database replicating at 10 MB/s change rate costs roughly $520/month in transfer fees before you count duplicated compute, storage, or managed-service charges.

When to Pick Single-Region#

Your users are geographically concentrated. A B2B SaaS serving North American enterprises does not need eu-west-1. A user in New York hitting us-east-1 pays 5 ms; the same user hitting eu-west-1 pays 68 ms^[2:3]. Do not add latency to solve a problem you do not have.

RTO > 1 hour is contractually acceptable. Internal tools, staging environments, analytics platforms, and early-stage products can tolerate a regional outage followed by a restore-from-backup recovery. Most startups fall here.

Strong consistency is a hard requirement and cross-region latency is unacceptable. Spanner regional configurations deliver 99.99% availability across three zones with single-digit-millisecond commits^[3:1]. If you need linearizability and low latency, stay in one region and accept the regional blast radius.

Operational capacity is limited. Multi-region doubles your deployment surface. If your team cannot rehearse failover quarterly, the DR region will be stale when you need it^[6:2].

When to Pick Multi-Region#

Contractual availability demands exceed what one region can deliver. Spanner multi-region publishes 99.999% SLA, 10x the four-nines of regional^[3:2]. Financial services, healthcare, and global e-commerce with SLAs measured in minutes of annual downtime need multi-region.

Global user latency is a product requirement. Sub-100 ms p99 for users on multiple continents is physically impossible from a single region. Netflix serves three regions (us-east-1, us-west-2, eu-west-1) so every user hits a nearby endpoint^[6:3].

Data-residency regulations force it. GDPR, PDPA, and sovereignty laws require personal data to stay inside a jurisdiction. A single EU region plus a single US region, each serving only its own users, satisfies the requirement without active-active complexity^[10].

The December 2021 us-east-1 outage is your threat model. Eight hours of control-plane failure knocked out Netflix (which survived via active-active^[6:4]), Disney+, Venmo, Ring, and Amazon's own Connect service^[9:1]. If your product cannot tolerate that scenario, you need at least active-passive DR.

The Hybrid Path#

Regional pinning is the architecture most production systems actually run. Each user (or tenant) is deterministically assigned to a home region. All writes for that user happen locally. Cross-region traffic on the hot path is zero.

Shopify's pod architecture is the canonical example. The Sorting Hat (Lua on OpenResty) maps each shop to a pod via X-Sorting-Hat-PodId. Each pod has its own MySQL shard, Redis, and Memcached. Pod Mover fails over a pod between datacenters in approximately one minute. At BFCM 2025, this architecture handled 489 million edge requests per minute with 99.99%+ uptime^[11].

Regional pinning gives single-leader consistency per user with pod-scoped blast radius; cross-pod reads flow through an eventually-consistent CDC pipeline.

The key insight: regional pinning gives you multi-region availability (a pod failure affects only that pod's tenants) without conflict resolution (each user has exactly one writer). Cross-user operations (global search, analytics) accept eventual consistency through a CDC pipeline running at ~65K records/s with P99 < 10 s^[11:1].

Real-World Examples#

Netflix (active-active, 3 regions). Three AWS regions serve live traffic behind geo-DNS. Cassandra replicates asynchronously with LOCAL_QUORUM reads. EVCache invalidates cross-region via SQS. Each region is provisioned to absorb the full load of a failed peer. Chaos Kong drills validate this assumption regularly. During the December 2021 us-east-1 outage, Netflix remained functional by evacuating traffic to the surviving regions^[6:5].

Shopify (regional pinning, 100+ pods). 489M edge RPM at BFCM 2025. Per-pod failover in ~1 minute. Ghostferry migrates shops between pods with seconds of downtime. No cross-pod writes, ever. The architecture was born from a pattern where a single shared Redis could crash and take down every shop, catalyzing full per-pod isolation^[11:2].

AWS us-east-1 (December 7, 2021). An automated scale-up triggered a surge that overwhelmed internal-to-main networking devices. The regional control plane (EC2 launch, STS, Route 53 API, monitoring) was impaired for 8 hours. Running EC2 instances and DynamoDB data plane stayed up, but any team that needed to launch capacity, rotate credentials, or read monitoring was blind^[9:2]. The lesson: multi-AZ protects against zone failures, not regional control-plane failures.

Common Mistakes#

Decision Checklist#

• What is your contractual RTO and RPO, not the aspirational one?
• Where are your users geographically, and what is the p99 latency SLO?
• Do data-residency regulations (GDPR, PDPA) force multi-region, or does a single in-jurisdiction region suffice?
• Can you afford 2-3x infrastructure cost plus 10-20% of spend in cross-region transfer?
• Can regional pinning give you multi-region availability without conflict-resolution complexity?
• When did you last actually fail over to your DR region? If the answer is "never," you are not ready.

Decision flowchart: start from single-region as the default and justify each step up. Most teams land on active-passive or regional pinning, not full active-active.

Key Takeaways#

• Single-region multi-AZ is the correct default. It gives strong consistency, low latency, and one deployment pipeline. Justify every step beyond it.
• Multi-region is the most expensive architectural choice: 2-3x compute, $0.02/GB cross-region transfer, and mandatory conflict resolution or consensus latency.
• Regional pinning (Shopify pods, Cloudflare Durable Objects) is the dominant real-world middle ground: multi-region availability with single-leader consistency per user.
• The December 2021 us-east-1 outage is the canonical threat model. Multi-AZ did not help; regional control-plane failure took down services for 8 hours.
• If you have not failed over to your DR region in the last quarter, it will not work when you need it. Rehearse or accept the risk.

Further Reading#

• AWS Disaster Recovery Whitepaper: canonical definition of the four DR tiers (backup/restore, pilot light, warm standby, multi-site active/active) with RTO/RPO ranges.
• AWS us-east-1 Post-Incident Report, December 2021: the single best document for understanding why regional control planes matter and what "multi-AZ" does not protect against.
• Netflix: Active-Active for Multi-Regional Resiliency: how Netflix went multi-region, Zuul routing, Cassandra replication, EVCache SQS invalidation, and Chaos Kong drills.
• Shopify: A Pods Architecture To Allow Shopify To Scale: regional pinning at scale, Sorting Hat, Pod Mover, Ghostferry, and per-pod isolation.
• CockroachDB Multi-Region Overview: practical docs on SURVIVE ZONE vs SURVIVE REGION and regional-by-row table locality.
• DynamoDB Global Tables MRSC: the managed zero-RPO primitive with witness replicas, GA June 2025.

Flashcards#

References#