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¹, and mandatory conflict resolution or cross-region consensus latency (68-110 ms per RTT²). 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². 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.

flowchart LR
    A["Single-Region Multi-AZ<br/>Strong consistency<br/>~1 ms cross-AZ<br/>Cost: 1x"] --> B["Active-Passive<br/>Warm standby<br/>RPO ~1 s<br/>Cost: 1.5-2x"]
    B --> C["Regional Pinning<br/>Per-user consistency<br/>Local writes<br/>Cost: 1.5-2.5x"]
    C --> D["Active-Active Async<br/>Eventual consistency<br/>LWW conflicts<br/>Cost: 2-3x"]
    D --> E["Active-Active Sync<br/>Strong consistency<br/>68-110 ms writes<br/>Cost: 3x+"]
    classDef cheap fill:#d4edda,stroke:#155724
    classDef mid fill:#fff3cd,stroke:#856404
    classDef expensive fill:#f8d7da,stroke:#721c24
    class A cheap
    class B,C mid
    class D,E expensive

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⁷ 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¹. 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². 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³. 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⁶.

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³. 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⁶.

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¹⁰.

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⁶), Disney+, Venmo, Ring, and Amazon’s own Connect service⁹. 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¹¹.

flowchart TD
    Client["Client request"] --> LB["Load Balancer"]
    LB --> SH["Sorting Hat<br/>(Lua on OpenResty)"]
    SH -->|"X-Sorting-Hat-PodId: 4"| App["Shared stateless app pool"]
    App --> P1["Pod 1<br/>MySQL + Redis + Memcached"]
    App --> P4["Pod 4<br/>MySQL + Redis + Memcached"]
    App --> PN["Pod N<br/>MySQL + Redis + Memcached"]
    P1 -.->|binlog| CDC["Debezium + Kafka<br/>~65K rec/s"]
    P4 -.->|binlog| CDC
    CDC --> Analytics["Analytics<br/>(eventually consistent)"]

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¹¹.

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⁶.

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¹¹.

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⁹. 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.

flowchart TD
    Start["New system design"]
    Q1{"Users on<br/>multiple continents<br/>with < 100 ms SLO?"}
    Q2{"RTO < 1 minute<br/>required?"}
    Q3{"Data residency<br/>regulation?"}
    Q4{"Can you afford<br/>3x cost + conflict<br/>resolution?"}
    Q5{"Per-user writes<br/>stay in one region?"}
    Single["Single-Region Multi-AZ"]
    Passive["Active-Passive<br/>(Aurora Global)"]
    Pinning["Regional Pinning<br/>(Shopify pods)"]
    ActiveActive["Active-Active<br/>(Netflix model)"]
    Start --> Q1
    Q1 -->|no| Q2
    Q1 -->|yes| Q4
    Q2 -->|no| Single
    Q2 -->|yes| Q3
    Q3 -->|yes| Pinning
    Q3 -->|no| Passive
    Q4 -->|no| Q5
    Q4 -->|yes| ActiveActive
    Q5 -->|yes| Pinning
    Q5 -->|no| Passive

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