Multi-Region Active-Active and Active-Passive

Multi-AZ protects against single AZ failures, but an entire AWS Region can become unavailable during large-scale disasters, major outages, or regulatory requirements. Multi-region architectures address this by running workloads in two or more geographically separated regions. There are two main patterns: active-passive (one region serves traffic while another waits on standby) and active-active (both regions simultaneously serve traffic).

In an active-passive multi-region setup, the primary region handles all production traffic. The secondary region runs a scaled-down but functional copy that stays warm and ready. Data is replicated from primary to secondary continuously. When the primary fails, you promote the secondary to active using Route 53 failover routing. This pattern offers lower cost than active-active but has higher RTO (time to promote and scale the standby).

In an active-active setup, both regions simultaneously serve production traffic. Route 53 with latency-based routing or weighted routing distributes users to the nearest or most appropriate region. When one region fails, Route 53 health checks detect the failure and route all traffic to the healthy region. Active-active provides the best RTO (near-zero), reduces latency for globally distributed users, and improves throughput by spreading load across regions.

The hardest part of multi-region architecture is keeping data consistent across regions. Key tools: S3 Cross-Region Replication (CRR) replicates S3 objects asynchronously to a bucket in another region. DynamoDB Global Tables provide multi-master, multi-region replication with eventual consistency. Aurora Global Database replicates from one primary region to up to five secondary regions with under 1 second lag. Each replication mechanism has different consistency guarantees and lag characteristics.

DynamoDB Global Tables enable true active-active, multi-region, multi-master replication. Your application can write to DynamoDB in any region, and the changes replicate to all other regions within typically 1 second. Conflict resolution uses last-writer-wins based on timestamps. This makes Global Tables ideal for globally distributed applications like gaming leaderboards, user profiles, and session stores where low-latency local reads and writes are critical.

Aurora Global Database spans multiple AWS regions with a single primary region handling writes and up to five secondary regions handling reads with under 1 second replication lag. For DR, you can promote a secondary region to primary in under 1 minute, making it suitable for active-passive with aggressive RTO. The secondary regions can also serve low-latency read traffic, making this a hybrid active-active for reads, active-passive for writes pattern.

Multi-region failover relies on Route 53 health checks to detect regional failures. Health checks can monitor an endpoint (HTTP/HTTPS/TCP), a CloudWatch alarm, or be calculated from other health checks. Route 53 continuously polls your endpoints from multiple locations around the world. When a check fails, Route 53 automatically stops returning that region's records and redirects traffic to healthy regions within the DNS TTL period.

AWS Global Accelerator provides two static Anycast IP addresses that route traffic through AWS's global network to the optimal endpoint. Unlike Route 53 DNS failover (which depends on TTL), Global Accelerator detects endpoint failures within 1-3 seconds and instantly reroutes traffic — much faster than DNS propagation. Use Global Accelerator when you need sub-second failover, consistent IPs for whitelisting, or when DNS TTL-based routing is too slow for your RTO.

Active-active multi-region architectures face a fundamental challenge: write conflicts. If two regions simultaneously update the same record, which update wins? DynamoDB Global Tables uses last-writer-wins. Application-level conflict resolution strategies include: event sourcing (append-only logs with CRDT merge), versioning (reject writes with stale version numbers), or partitioned writes (each region owns a shard of data and only writes to its shard). Design your data model to minimise cross-region write conflicts.

Multi-region architectures significantly increase cost and complexity. You pay for resources in multiple regions, data replication costs (cross-region data transfer), health check costs, and often need duplicate operational tooling in each region. Active-passive is more cost-effective because the standby runs at reduced capacity. Active-active costs the most but provides the best user experience and RTO. Always weigh the cost against the business value of additional regional resilience.

Choose your multi-region pattern based on business requirements: If RTO > 1 hour and cost is the priority, use Backup and Restore to another region. If RTO is minutes, use active-passive with warm standby. If RTO < 1 minute and users are globally distributed, use active-active. Consider regulatory requirements — some industries require data to stay in specific regions, which may limit your replication options. Document your architecture decision with the trade-offs explicitly.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: active-passive runs a standby region that activates on failure, active-active serves traffic from multiple regions simultaneously, and DynamoDB Global Tables and Aurora Global Database are key services for multi-region data replication. Route 53 health checks and Global Accelerator handle traffic routing decisions. Next up we explore health checks, circuit breakers, and retry logic.