Multi-Site Active-Active with Global Tables and Route 53

Multi-Site Active-Active is the highest tier of disaster recovery, where your application runs at full production capacity in two or more AWS regions simultaneously. Unlike active-passive where a standby waits to take over, in active-active both regions serve live user traffic at all times. When one region fails, the other absorbs 100% of traffic immediately with no failover delay. This pattern also reduces latency for globally distributed users by serving them from the nearest region.

DynamoDB Global Tables is the data backbone of active-active architectures. Global Tables enable multi-master, multi-region replication — applications in any region can read and write to a local DynamoDB table, and changes replicate to all other regions within approximately 1 second. You enable Global Tables by specifying which regions the table should exist in. AWS handles all replication, conflict resolution (last-writer-wins), and failover automatically.

Aurora Global Database provides active-active reads but active-passive writes. All secondary regions serve reads with under 1 second replication lag, while only the primary region accepts writes. This is ideal for read-heavy applications that want low-latency reads globally with a clear write primary. During a regional failure of the primary, you can promote a secondary to primary in under 1 minute, achieving low RTO for the write tier. Compare with DynamoDB Global Tables which supports active-active writes in all regions.

Route 53 is the traffic director for multi-site active-active architectures. Use latency-based routing to send each user to the region with the lowest network latency from their location. Attach health checks to each regional record — when a region fails its health check, Route 53 automatically removes it from DNS responses, sending all traffic to the remaining healthy regions. Set DNS TTL to 60 seconds or less to minimise the time it takes for users to fail over to the healthy region.

When one region fails in an active-active setup, the surviving region must handle 2x (or more) its normal traffic. Your Auto Scaling Group must have sufficient max capacity and scale-out policies that react quickly. Configure target tracking scaling based on ALB request count per target, so the ASG adds instances automatically as traffic doubles. Also consider pre-warming: during failover drills, observe how quickly your ASG scales out and ensure it can reach the required capacity within your RTO target.

In a single-region architecture, user sessions can be stored locally on application servers. In active-active multi-region, users may bounce between regions on subsequent requests, breaking server-side sessions. Solutions: 1) Stateless sessions — store session data in a signed JWT or cookie that any server in any region can validate. 2) DynamoDB Global Tables for sessions — store sessions centrally with millisecond access from any region. 3) ElastiCache with Global Datastore — Redis replication across regions for session storage.

The biggest challenge in active-active with multi-master writes is write conflicts. If two users in different regions simultaneously update the same record, which update wins? DynamoDB Global Tables uses last-writer-wins based on the timestamp of the write. This works well for most use cases but can cause data loss for competing updates (e.g., two users simultaneously incrementing a counter). Design your data model to avoid concurrent writes to the same item by different regions using conditional writes or by partitioning data ownership by region.

For object storage in active-active, use S3 Cross-Region Replication with bidirectional replication (available on buckets with versioning enabled). Unlike one-way CRR, bidirectional replication keeps both region buckets in sync — objects written in either region are automatically replicated to the other. This is critical for applications that write user-uploaded files to their local region's S3 bucket but need those files accessible globally. Enable S3 Replication Time Control (RTC) to guarantee 99.99% of objects replicate within 15 minutes.

Use CloudFront with origin groups to create an active-active CDN with automatic failover. Configure a primary origin (ALB in us-east-1) and a secondary origin (ALB in eu-west-1). CloudFront automatically fails over to the secondary origin when the primary returns 5xx errors. For static assets served from S3, configure origin groups pointing to S3 buckets in multiple regions with bidirectional replication. This adds a CDN-level resilience layer on top of your Route 53 active-active routing.

Active-active architectures require robust monitoring to ensure both regions are healthy and traffic is balanced as expected. Key metrics: Route 53 HealthCheckPercentageHealthy per region, DynamoDB ReplicationLatency for Global Tables lag, ALB RequestCount per region to verify traffic distribution, and CloudWatch cross-account/cross-region dashboards for a unified view. Set alarms when replication lag exceeds your RPO threshold or when traffic distribution becomes severely unbalanced.

Active-active is appropriate when: users are globally distributed and latency to a single region is unacceptable. RTO must be near-zero — the business cannot tolerate even minutes of downtime. High write throughput requires spreading writes across regions. Regulatory requirements mandate in-country data processing. The cost is substantially higher than other DR tiers, so only choose active-active when the business requirements and economics clearly justify it. For many workloads, Warm Standby is sufficient and far cheaper.

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

In this lesson you learned: DynamoDB Global Tables enables multi-master writes across regions for true active-active, Route 53 latency routing with health checks directs users to the nearest healthy region, and session management must be stateless or use globally replicated storage in active-active. Active-active provides near-zero RTO and RPO but at significantly higher cost. Next up we explore the Well-Architected Framework's Operational Excellence and Security pillars.