Multi-Region Architectures
Key concepts
Active-active vs active-passive
Global databases
Cross-region replication
Latency-based routing
Data sovereignty considerations
Overview
Multi-Region architectures distribute applications and data across multiple AWS Regions to provide disaster recovery, reduce latency for global users, and meet data sovereignty requirements. Unlike Multi-AZ (which protects against data center failures), Multi-Region protects against entire regional outages and natural disasters.
For the SAA-C03 exam, understanding when to use Multi-Region versus Multi-AZ is critical. You need to know the trade-offs between active-active and active-passive patterns, how different services replicate across regions, and the RPO/RTO implications of each approach.
Core Principle
Multi-Region provides global disaster recovery and reduced latency for users worldwide. It uses asynchronous replication (with some exceptions) and requires careful consideration of data consistency, cost, and complexity trade-offs.
Multi-Region questions often focus on: choosing the right routing policy (latency vs geolocation vs failover), understanding replication lag implications, and selecting appropriate DR strategies based on RPO/RTO requirements.
Architecture Diagram
The following diagram illustrates a typical Multi-Region active-passive architecture:
Key Concepts
Active-Active vs Active-Passive
Multi-Region Deployment Patterns
Active-Active (Multi-Site)
- Both regions serve live traffic simultaneously
- Requires bidirectional data replication
- Lowest RTO (near-zero) but highest complexity
- Must handle conflict resolution for concurrent writes
- Examples: DynamoDB Global Tables, S3 with bidirectional CRR
Active-Passive (Standby)
- Primary region handles all traffic
- Secondary region is standby (warm or cold)
- Simpler to implement, lower cost
- Higher RTO (minutes to hours depending on strategy)
- Examples: Aurora Global Database with read-only secondary
Active-Active vs Active-Passive Comparison
| Aspect | Active-Active | Active-Passive |
|---|---|---|
| Traffic Distribution | Both regions serve traffic | Only primary serves traffic |
| RTO | Near-zero (instant failover) | Minutes to hours |
| RPO | Near-zero to seconds | Seconds to minutes |
| Complexity | High (conflict resolution) | Lower (simpler failover) |
| Cost | Higher (full capacity in both) | Lower (reduced standby) |
| Data Consistency | Eventually consistent | Can be strongly consistent |
| Use Case | Global apps, zero downtime | DR, cost-sensitive workloads |
RPO and RTO Fundamentals
Recovery Objectives
RPO (Recovery Point Objective)
- Maximum acceptable data loss measured in time
- "How much data can we afford to lose?"
- Determined by replication lag and backup frequency
- Lower RPO = more frequent replication = higher cost
RTO (Recovery Time Objective)
- Maximum acceptable downtime after failure
- "How quickly must we recover?"
- Determined by failover automation and infrastructure readiness
- Lower RTO = more standby resources = higher cost
DR Strategy RPO/RTO Comparison
| Strategy | RPO | RTO | Cost | Description |
|---|---|---|---|---|
| Backup & Restore | Hours | Hours | $ (Lowest) | Restore from backups in DR region |
| Pilot Light | Minutes | 10s of minutes | $$ | Core infrastructure running, scale up on failover |
| Warm Standby | Seconds-Minutes | Minutes | $$$ | Scaled-down but functional copy running |
| Multi-Site Active-Active | Near-zero | Near-zero | $$$$ (Highest) | Full capacity in multiple regions |
How It Works
Route 53 Multi-Region Routing
Route 53 is essential for directing traffic in Multi-Region architectures:
Route 53 Routing Policies for Multi-Region
| Policy | Use Case | How It Works |
|---|---|---|
| Latency-based | Best performance for users | Routes to region with lowest network latency |
| Geolocation | Content localization, compliance | Routes based on user continent/country |
| Geoproximity | Traffic shaping with bias | Routes to nearest region, adjustable with bias values |
| Failover | Active-passive DR | Routes to primary; fails over to secondary on health check failure |
| Weighted | Blue-green, canary deployments | Distributes traffic by assigned weights |
Latency vs Geolocation vs Geoproximity
Latency-Based Routing
- Routes based on actual network latency measurements
- Best for: Performance optimization
- Note: Nearest region geographically may not have lowest latency
Geolocation Routing
- Routes based on user's geographic location (continent/country)
- Best for: Content localization, regulatory compliance, restricting access
- Requires default record for unmatched locations
Geoproximity Routing
- Routes to closest resource with adjustable bias
- Bias values (-99 to +99) expand/shrink routing region
- Best for: Traffic shaping, gradual migration between regions
- Requires Route 53 Traffic Flow
Aurora Global Database
Aurora Global Database
Aurora Global Database provides cross-region disaster recovery with:
Key Characteristics:
- Storage-level replication (not instance-level)
- Sub-second replication lag (typically < 1 second)
- Up to 5 secondary regions with up to 16 read replicas each
- RPO of ~1 second, RTO of < 1 minute
Failover Options:
- Switchover (planned): Zero data loss, synchronizes before switching
- Failover (unplanned): Potential data loss equal to replication lag
Write Forwarding:
- Secondary region can forward writes to primary
- Reduces application complexity
- Adds latency for write operations from secondary
Planned Switchover (maintenance, migration):
1. Secondary syncs with primary (RPO = 0)
2. Primary becomes read-only
3. Secondary promoted to read-write
4. Old primary rejoins as secondary
Unplanned Failover (disaster):
1. Detect primary region failure
2. Promote secondary to primary (< 1 minute)
3. Update application endpoints
4. Potential data loss = replication lag at failure timeDynamoDB Global Tables
DynamoDB Global Tables
DynamoDB Global Tables provide multi-region, multi-active database:
Key Characteristics:
- Active-active: Read/write in any region
- Automatic replication: Typically < 1 second
- 99.999% availability SLA
- Last-writer-wins conflict resolution
Consistency Modes:
- MREC (Multi-Region Eventual Consistency): Default, async replication
- MRSC (Multi-Region Strong Consistency): Sync replication, higher latency
Conflict Resolution:
- Uses timestamps to resolve concurrent writes
- Last write (by timestamp) wins
- Can implement custom logic via DynamoDB Streams + Lambda
Avoiding DynamoDB Conflicts
To avoid conflicts in Global Tables:
- Single-region writes: Use one region for writes, others for reads
- Partition by region: Different items written in different regions
- Application-level locking: Implement distributed locks
- Idempotent operations: Design for safe retries
S3 Cross-Region Replication (CRR)
S3 Cross-Region Replication
S3 CRR asynchronously replicates objects between buckets in different regions:
Requirements:
- Versioning enabled on source and destination
- IAM role with replication permissions
- Different destination bucket (can be same or different account)
Replication Options:
- Entire bucket or prefix/tag filters
- Replica ownership: Keep original or change to destination account
- Storage class: Can change during replication
- Delete markers: Optional replication
Replication Time Control (RTC):
- SLA: 99.99% of objects replicated within 15 minutes
- Enables predictable replication for compliance
- Additional cost for RTC
S3 Replication Options
| Feature | Same-Region (SRR) | Cross-Region (CRR) |
|---|---|---|
| Use Case | Compliance, log aggregation | DR, latency reduction |
| Latency | Lower | Higher (cross-region) |
| Cost | No data transfer charges | Data transfer charges apply |
| Bidirectional | Supported | Supported (with replica sync) |
AWS Global Accelerator
AWS Global Accelerator
Global Accelerator improves availability and performance for multi-region apps:
Key Features:
- Two static anycast IPs (announced from all edge locations)
- AWS global network routing (avoids public internet)
- Automatic failover based on endpoint health
- Traffic dials for gradual region migration
vs CloudFront:
- CloudFront: Caches content at edge (HTTP/HTTPS only)
- Global Accelerator: Routes to origin (TCP/UDP, no caching)
Endpoint Types:
- Application Load Balancers
- Network Load Balancers
- EC2 instances
- Elastic IP addresses
Decision Guide
Use Cases
Use Case 1: Global E-Commerce Platform
Scenario: Online retailer with customers in North America, Europe, and Asia requiring low latency and high availability.
Solution:
- DynamoDB Global Tables for product catalog and cart (active-active)
- Aurora Global Database for orders and inventory (primary in US, read replicas in EU/Asia)
- S3 with CRR for static assets
- CloudFront for content delivery
- Route 53 latency-based routing
Use Case 2: Financial Services DR
Scenario: Banking application requiring < 1 hour RTO and < 5 minute RPO for regulatory compliance.
Solution:
- Aurora Global Database (RPO ~1 second, RTO < 1 minute)
- S3 CRR with RTC for documents (15-minute SLA)
- Route 53 failover routing with health checks
- Warm standby infrastructure in DR region
- AWS Backup for cross-region backup copies
Use Case 3: Content Platform with Regional Restrictions
Scenario: Streaming service with content licensing restrictions by country.
Solution:
- Route 53 geolocation routing to direct users to appropriate region
- Regional S3 buckets with region-specific content
- CloudFront with geo-restriction
- DynamoDB Global Tables for user data
- Lambda@Edge for real-time access control
Best Practices
Multi-Region Best Practices
- Start with Multi-AZ, add Multi-Region for DR - Don't over-engineer; Multi-AZ handles most failures
- Automate failover testing - Use AWS Fault Injection Simulator regularly
- Consider data sovereignty - Some data may not be allowed to leave certain regions
- Plan for replication lag - Design applications to handle eventual consistency
- Use infrastructure as code - Deploy identical stacks across regions with CloudFormation StackSets
- Monitor replication metrics - Set CloudWatch alarms for replication lag
- Document runbooks - Clear procedures for manual failover if needed
- Cost awareness - Data transfer between regions is expensive
Common Exam Scenarios
Exam Scenarios and Solutions
| Scenario | Solution | Why |
|---|---|---|
| Global users need lowest latency | Route 53 latency-based routing | Routes to region with best network performance, not just nearest |
| Content must stay in specific countries | Route 53 geolocation routing | Enforces geographic restrictions for compliance |
| Need zero-downtime failover for database | Aurora Global Database | Sub-second RPO, < 1 minute RTO with automatic failover |
| Active-active database across regions | DynamoDB Global Tables | Built-in multi-region active-active with conflict resolution |
| Static IP for multi-region app | AWS Global Accelerator | Provides static anycast IPs that route to healthy regional endpoints |
| Replicate S3 within 15 minutes guaranteed | S3 CRR with Replication Time Control | RTC provides SLA for predictable replication timing |
| Gradual migration between regions | Route 53 geoproximity with bias | Bias values allow shifting traffic percentage between regions |
Common Pitfalls
Pitfall 1: Ignoring Replication Lag
Mistake: Assuming data is immediately consistent across regions after write.
Why it fails:
- Cross-region replication is asynchronous (seconds to minutes)
- Reads from secondary region may return stale data
- Failover may lose recent writes
Correct Approach:
- Design for eventual consistency
- Use read-after-write consistency where available (DynamoDB strong consistency)
- Accept potential data loss equal to replication lag in DR scenarios
Pitfall 2: Using Geolocation When Latency is the Goal
Mistake: Using geolocation routing to "route users to nearest region" for performance.
Why it fails:
- Geolocation routes by country/continent, not network performance
- Nearest geographic region may not have lowest latency
- Users near region boundaries may be misrouted
Correct Approach:
- Use latency-based routing for performance optimization
- Use geolocation only for compliance or content restrictions
- Use geoproximity when you need both location awareness and traffic control
Pitfall 3: Underestimating Multi-Region Costs
Mistake: Not accounting for cross-region data transfer costs.
Why it fails:
- Data transfer between regions: $0.02/GB (varies by region pair)
- S3 CRR, Aurora replication, DynamoDB Global Tables all incur transfer costs
- Costs can exceed compute costs for data-heavy workloads
Correct Approach:
- Calculate data transfer costs before implementing
- Use compression where possible
- Consider if Multi-Region is truly necessary vs Multi-AZ
- Use VPC endpoints and PrivateLink to reduce NAT costs
Pitfall 4: No Failover Testing
Mistake: Implementing DR but never testing failover procedures.
Why it fails:
- Untested runbooks fail under pressure
- Configuration drift between regions
- Team unfamiliar with failover process
Correct Approach:
- Schedule regular DR drills (quarterly minimum)
- Use AWS Fault Injection Simulator for chaos engineering
- Automate failover with Step Functions or Lambda
- Document and version control all runbooks
Test Your Knowledge
A company needs to route users to different regional deployments based on the user's country for content licensing compliance. Which Route 53 routing policy should they use?
What is the typical RPO for Aurora Global Database?
How does DynamoDB Global Tables handle concurrent writes to the same item in different regions?
Which AWS service provides static anycast IP addresses for multi-region application failover?
Related Services
Quick Reference
Multi-Region Service Capabilities
Service Multi-Region Support
| Service | Replication Type | RPO | RTO | Active-Active |
|---|---|---|---|---|
| Aurora Global Database | Storage-level async | ~1 second | < 1 minute | No (read-only secondary) |
| DynamoDB Global Tables | Async (MREC) or Sync (MRSC) | < 1 second | Near-zero | Yes |
| S3 Cross-Region Replication | Async (RTC: 15 min SLA) | Minutes (or 15 min with RTC) | N/A | Yes (bidirectional) |
| ElastiCache Global Datastore | Async | < 1 second typical | < 1 minute | No (read-only secondary) |
| RDS Cross-Region Read Replica | Async | Minutes | Minutes (manual promotion) | No |
Data Transfer Costs (Approximate)
US East to US West: ~$0.02/GB
US to Europe: ~$0.02/GB
US to Asia Pacific: ~$0.09/GB
Within same region: Free (same AZ) or ~$0.01/GB (cross-AZ)
Cost Optimization Tips:
- Compress data before replication
- Use S3 Intelligent-Tiering for replicated data
- Filter replication to only necessary objects/tables
- Consider if multi-region is truly requiredFailover Checklist
Pre-Failover:
□ Verify health check status in Route 53
□ Check replication lag metrics
□ Confirm DR region capacity
□ Notify stakeholders
During Failover:
□ Promote secondary database (Aurora/RDS)
□ Update Route 53 records (if not automatic)
□ Verify application connectivity
□ Monitor error rates and latency
Post-Failover:
□ Investigate root cause
□ Plan failback procedure
□ Update documentation
□ Conduct post-mortem