AWS Multi-Region Active-Active Architecture — Overview
A multi-region active-active architecture serves traffic from multiple AWS regions simultaneously, providing near-zero RTO/RPO, global low-latency access, and resilience against full region failures. This is the most advanced availability pattern and is heavily tested on SAP-C02 for mission-critical workloads.
Route 53 (latency/weighted routing + health checks) | CloudFront (edge caching) | Global Accelerator (anycast)
Data Layer — Active-Active Options
| Service | Multi-Region Model | Consistency | Failover |
|---|---|---|---|
| DynamoDB Global Tables | Multi-master (read-write in all regions) | Eventually consistent cross-region (~1s). Last-writer-wins conflict resolution. | Automatic — other regions continue serving read-write |
| Aurora Global Database | Single writer + read replicas in other regions | <1s replication lag. Strong consistency in writer region. | Managed failover promotes secondary to writer (~1 min). Planned switchover with zero data loss. |
| Aurora DSQL | Multi-region active-active with strong consistency | Strongly consistent across regions (distributed transactions) | Automatic — no failover needed, all regions active |
| ElastiCache Global Datastore | Active primary + read replicas cross-region | Async replication (<1s typical) | Promote secondary to primary (~minutes) |
| S3 Cross-Region Replication | Async object replication (one-way or bidirectional) | Eventually consistent (seconds to minutes for replication) | Access replica bucket directly — no failover action needed |
When to Use Which Database
- DynamoDB Global Tables: True active-active (write in any region), key-value/document workloads, can tolerate eventual consistency and last-writer-wins
- Aurora Global: Relational workloads needing SQL/joins, single-writer acceptable (reads globally), fast managed failover
- Aurora DSQL: Need strong consistency with active-active writes across regions (newest option, distributed SQL)
Global Traffic Routing
| Service | How It Routes | Failover Mechanism | Best For |
|---|---|---|---|
| Route 53 Latency Routing | Routes to region with lowest latency for user | Health checks remove unhealthy region | Latency-optimized global distribution |
| Route 53 Weighted Routing | Split traffic by percentage (e.g., 70/30) | Health checks remove 0-weight | Gradual migration, canary between regions |
| Route 53 Failover Routing | Primary → Secondary (active-passive) | Health check fails → switch to secondary | Active-passive DR (not active-active) |
| CloudFront | Edge caching + origin failover | Origin group: primary fails → secondary origin | Static/dynamic content with edge caching |
| Global Accelerator | Anycast IPs → nearest healthy endpoint | Health checks → instant reroute (no DNS TTL delay) | TCP/UDP apps needing static IPs + instant failover |
Route 53 vs Global Accelerator for Failover
- Route 53: DNS-based — failover speed depends on TTL (typically 60s). Client caches DNS. Good for most web applications.
- Global Accelerator: Network-layer — failover in seconds (no DNS caching issue). Static anycast IPs never change. Better for latency-sensitive or non-HTTP applications.
Key Challenges & Solutions
1. Data Consistency
- Problem: Two regions writing to the same record simultaneously → conflict
- DynamoDB solution: Last-writer-wins (timestamp-based). Application must tolerate this. Use conditional writes for critical operations.
- Aurora solution: Single writer region eliminates write conflicts. Use write-forwarding for reads-everywhere, writes-to-primary.
- Aurora DSQL: Distributed transactions with strong consistency (no conflicts, correctness guaranteed)
2. Session Management
- Problem: User session created in Region A, next request routes to Region B
- Solutions:
- ElastiCache Global Datastore for cross-region session replication
- DynamoDB Global Tables for session storage (available everywhere)
- Sticky sessions (Route 53 geo/latency keeps user in same region)
- Stateless JWT tokens (no server-side session needed)
3. Split-Brain Prevention
- Problem: Network partition between regions — both think they’re the primary
- Solution: DynamoDB Global Tables handle this natively (multi-master, no split-brain). Aurora uses managed failover with fencing (old writer is demoted). For custom logic: use DynamoDB conditional writes as a distributed lock.
4. Deployment Consistency
- Problem: Application versions must be identical across regions
- Solution: CI/CD pipeline deploys to all regions simultaneously (CodePipeline cross-region actions). Use CloudFormation StackSets for infrastructure. Container images replicated via ECR cross-region replication.
Cost Considerations
- Compute: Full production capacity in 2+ regions (2x baseline compute cost)
- Data transfer: Cross-region replication incurs data transfer fees ($0.02/GB between regions)
- DynamoDB Global Tables: Pay for write capacity in each replica region (replicated writes charged)
- Aurora Global: Read replicas in secondary region are cheaper than full writer clusters
- Optimization: Use CloudFront to reduce origin requests (cache hit → no cross-region call). Compress data before replication.
Active-Active vs Active-Passive
| Aspect | Active-Active | Active-Passive |
|---|---|---|
| Traffic | Both regions serve production traffic simultaneously | Only primary serves traffic; secondary is standby |
| RTO | Near-zero (no failover action needed) | Minutes (failover must be triggered) |
| RPO | Near-zero (data in both regions) | Seconds-minutes (replication lag) |
| Cost | 2x (full infrastructure in both regions) | 1.3-1.5x (reduced standby in secondary) |
| Complexity | High (consistency, conflicts, session management) | Medium (straightforward failover) |
| Use case | Mission-critical (financial, global SaaS, healthcare) | Important but can tolerate brief outage |
Exam Tips
| Exam | Key Points |
|---|---|
| SAP-C02 | “Zero downtime even during region failure” → Active-Active. “Read-write in any region” → DynamoDB Global Tables. “Relational + fast failover” → Aurora Global. “Instant failover without DNS delay” → Global Accelerator. “Lowest latency for global users” → Route 53 latency + CloudFront. Watch for data consistency trade-offs in answers. |
AWS Certification Exam Practice Questions
Question 1:
A global financial platform requires users in US and Europe to have read-write access to the same data with sub-5ms latency. The system must continue operating with zero downtime even if an entire AWS region fails. Which database architecture supports this?
- Aurora Global Database with write-forwarding from European reader
- DynamoDB Global Tables with replicas in us-east-1 and eu-west-1
- RDS Multi-AZ with cross-region read replicas and manual promotion
- ElastiCache Global Datastore with application-level write routing
Show Answer
Answer: B — DynamoDB Global Tables provide multi-master replication: both regions accept writes with single-digit millisecond latency locally. If one region fails, the other continues with zero intervention. Aurora Global only has one writer region (write-forwarding adds latency). RDS read replicas require manual promotion (downtime).
Question 2:
A company uses Route 53 latency-based routing for multi-region active-active. During a regional outage, they notice some users still route to the failed region for up to 60 seconds due to DNS TTL caching. How can they achieve faster failover?
- Reduce Route 53 TTL to 1 second
- Replace Route 53 with AWS Global Accelerator
- Add CloudFront in front with origin failover group
- Use Route 53 health checks with faster interval (10s)
Show Answer
Answer: B — Global Accelerator uses anycast IPs at the network layer (not DNS). When a region fails, traffic is rerouted at the AWS edge in seconds without waiting for DNS TTL expiry. The static anycast IPs never change for clients. Reducing DNS TTL helps but can’t eliminate the caching delay entirely (resolvers may not honor very low TTLs).
Question 3:
A multi-region active-active application using DynamoDB Global Tables discovers that two regions occasionally write to the same item simultaneously, causing data inconsistency. The business logic requires that only the FIRST write wins (not last). How should they handle this?
- Switch to Aurora Global Database (single writer prevents conflicts)
- Use DynamoDB conditional writes with version attribute (reject if version changed)
- Configure DynamoDB Global Tables to use first-writer-wins instead of last-writer-wins
- Add SQS queue to serialize all writes through a single region
Show Answer
Answer: B — DynamoDB conditional writes with a version attribute (optimistic locking) ensure that a write only succeeds if the item hasn’t been modified since it was last read. The first write succeeds; the second write’s condition fails (version mismatch) and the application can retry or reject. DynamoDB Global Tables only support last-writer-wins natively — you must implement first-writer-wins at the application level.
Question 4:
A company wants to deploy a multi-region active-active web application. They need users globally to experience <50ms response time for static content and <200ms for dynamic API calls. Which combination of services achieves this?
- Route 53 latency routing → ALB in each region (both static and dynamic)
- CloudFront (static + dynamic caching) + Route 53 latency routing → ALB for API + Global Accelerator for WebSocket
- Global Accelerator for everything (static + dynamic)
- CloudFront with Lambda@Edge processing all requests
Show Answer
Answer: B — CloudFront caches static content at 400+ edge locations (<50ms globally). For dynamic API calls, Route 53 latency routing directs to the nearest region’s ALB (<200ms). Global Accelerator handles WebSocket/TCP connections needing static IPs and instant failover. This layered approach optimizes each traffic type differently.
Question 5:
An active-active application stores user sessions in ElastiCache Redis. When a user’s requests route to a different region (due to Route 53 latency changes), they lose their session and must re-authenticate. How should this be fixed?
- Use sticky sessions in Route 53 (geolocation routing to keep user in one region)
- Replace ElastiCache with DynamoDB Global Tables for session storage
- Use ElastiCache Global Datastore to replicate sessions cross-region
- Store sessions in client-side JWT tokens (stateless, no server session)
Show Answer
Answer: D — Stateless JWT tokens stored client-side eliminate the cross-region session problem entirely. The token is sent with every request regardless of which region handles it. DynamoDB Global Tables (B) and ElastiCache Global Datastore (C) also work but add latency and complexity. JWTs are the simplest and most scalable solution for active-active session management.
Related Architecture Patterns
- Disaster Recovery – All 4 Strategies
- Hybrid Cloud Networking
- Data Lake & Analytics Architecture
- All Architecture Patterns – Hub
References
- DR Architecture Part IV: Multi-Site Active/Active — AWS Blog
- DynamoDB Global Tables Developer Guide
- Aurora Global Database for HA — AWS Blog
- Global Accelerator Performance — AWS Blog
Frequently Asked Questions
Does active-active mean both regions handle writes?
It depends on the database. With DynamoDB Global Tables: yes, both regions accept writes (multi-master). With Aurora Global: only one region writes (single-master), other regions serve reads with fast failover to become writer. True multi-region active-active writes require DynamoDB Global Tables or Aurora DSQL.
How much does active-active cost compared to single-region?
Roughly 2x for compute (full capacity in both regions) + cross-region data transfer fees ($0.02/GB). DynamoDB Global Tables charge for replicated write capacity. The cost premium is justified only for mission-critical workloads where any downtime has severe business impact. Consider Warm Standby (1.3x cost) as a cheaper alternative if minutes of RTO is acceptable.
What is the difference between Global Accelerator and CloudFront for multi-region?
CloudFront is a CDN that caches content at edge locations — best for HTTP/HTTPS with cacheable content. Global Accelerator is a network-layer accelerator with static anycast IPs — best for non-cacheable traffic, TCP/UDP applications, or when you need instant failover without DNS delays. Use both together: CloudFront for static/cacheable, Global Accelerator for real-time APIs/WebSocket.