Overview

Multi-region resilience on AWS requires choosing the right replication model for each layer — compute, data, events, and DNS. This article covers the four core AWS services for multi-region data replication and the full-stack pattern that composes them into a resilient architecture.

Why It Matters

A single-region architecture has a single point of failure at the regional level. AWS regions do fail — not often, but when they do, the impact is total for single-region apps. Multi-region architecture distributes that risk, enabling either active/active (both regions serve traffic simultaneously) or active/passive (one region is live, one is standby) resilience models.

Where It Fits

DOP-C02 Domain 3 — Resilient Cloud Solutions (capstone pattern)

User | v Route 53 (latency or failover routing) | +– us-east-1 (primary) | ALB → ASG → App → Aurora Global (primary) | DynamoDB Global Table | +– us-west-2 (secondary) ALB → ASG → App → Aurora Global (secondary, promoted on failover) DynamoDB Global Table

The Big Picture

Layer Service Replication Model

DNS Route 53 Failover/latency routing + health checks Compute ASG + ALB Independent per region, same Launch Template Relational DB Aurora Global Database Active/passive, ~1s lag, <1min promotion NoSQL DB DynamoDB Global Tables Active/active, sub-second, last-writer-wins Object Storage S3 + CRR Async replication, versioning required Events EventBridge Global Automatic failover between regional buses

Core Concepts

DynamoDB Global Tables — active/active:

us-east-1 ←── replication (~<1s) ──→ us-west-2 | | reads + writes reads + writes

• Any region can read AND write simultaneously
• Conflict resolution: last-writer-wins (timestamp-based)
• Exam trigger: “multi-region app needs low-latency reads AND writes globally”

Aurora Global Database — active/passive:

us-east-1 (primary) ──── ~1s lag ────→ us-west-2 (secondary) reads + writes reads only promote in <1 minute on failure

• Only primary accepts writes
• Secondary can be promoted to primary in under 1 minute
• Exam trigger: “multi-region relational DB with fast failover”
• Exam trap: Multi-AZ ≠ multi-region — Multi-AZ is same-region HA only

S3 Cross-Region Replication (CRR):

us-east-1 bucket (source, versioning enabled) | v async us-west-2 bucket (destination, versioning enabled)

• Replication is async — not instantaneous
• Versioning must be enabled on both source and destination
• Exam trigger: “replicate S3 objects to another region for DR or compliance”

EventBridge Global Endpoints:

Event → Global Endpoint | +── Primary event bus (us-east-1) ← healthy +── Secondary event bus (us-west-2) ← automatic failover

• Routes events to the healthy regional bus automatically
• Exam trigger: “event-driven architecture needs to survive regional failure”

Real-World Example

No live lab — multi-region setup requires resources in multiple regions (two ALBs, two ASGs, Aurora Global cluster) with real cost implications.

Decision framework — pick the right service:

Need multi-region writes (NoSQL)? → DynamoDB Global Tables Need multi-region SQL + fast failover? → Aurora Global Database Need multi-region object storage? → S3 CRR Need multi-region event routing? → EventBridge Global Endpoints Need DNS-level regional failover? → Route 53 Failover routing

Aurora vs DynamoDB — the common exam trap:

Scenario: “globally distributed app, users write from any region” Answer: DynamoDB Global Tables (active/active writes)

Scenario: “existing MySQL workload, need regional DR with <1min RTO” Answer: Aurora Global Database (active/passive, fast promotion)

Engineering Analogy

Your platform-foundation is a single-region active architecture — one VPC, one ops instance, one set of services. Multi-region is the equivalent of running a complete second copy of platform-foundation in us-west-2 with data replication between them. The challenge is not the compute (ASG handles that identically in any region) — it’s the data layer. Stateless compute scales easily; stateful data requires careful replication model selection.

Best Practices

• Match replication model to write pattern — active/active (DynamoDB) for global writes, active/passive (Aurora) for single-writer SQL
• Always enable versioning before enabling S3 CRR — CRR requires it, and enabling CRR on a non-versioned bucket fails
• Use Route 53 latency routing for active/active multi-region — users automatically hit the closest region
• Use Route 53 failover routing for active/passive — primary gets all traffic until health check fails
• Design for promotion — Aurora secondary promotion is fast (<1min) but requires a runbook; test it before you need it

Common Mistakes

• Confusing Multi-AZ with multi-region — Multi-AZ is same-region HA, not DR across regions
• Using DynamoDB Global Tables when only reads need to be global — unnecessary complexity if writes are single-region
• Forgetting to enable versioning on S3 buckets before enabling CRR
• Assuming S3 CRR is synchronous — it is async; there is replication lag

Pro Tip

Aurora Global Database promotion to a new primary is fast (<1 minute) but it is a manual operation by default — you must call failover-global-cluster via CLI or console. For fully automatic failover, pair it with Route 53 health checks and a Lambda that triggers promotion when the primary health check fails.

Key Takeaways

• DynamoDB Global Tables = active/active (any region writes); Aurora Global = active/passive (promote secondary on failure)
• Multi-AZ ≠ multi-region — know the difference, the exam tests it directly
• S3 CRR requires versioning enabled on both buckets and is async
• The full multi-region stack: Route 53 → ALB → ASG → Aurora Global / DynamoDB Global Tables
• Stateless compute (ASG) is easy to multi-region; stateful data layer requires careful replication model selection

Related Articles

• DevOpsPro-Route53-Resilience-Routing-Policies-and-Failover.md
• DevOpsPro-ALB-Target-Groups-and-ASG-Integration.md
• DevOpsPro-AWS-Auto-Scaling-Groups-The-Self-Healing-Control-Loop.md

References

• AWS Documentation: Amazon DynamoDB Global Tables
• AWS Documentation: Amazon Aurora Global Database
• AWS Documentation: Amazon S3 Cross-Region Replication
• AWS Documentation: Amazon EventBridge Global Endpoints