Multi-region AWS architecture is the answer to "what happens if an AWS region goes down?" — but it's also one of the most expensive and complex infrastructure investments you can make. The gap between a working single-region system and a working multi-region system is enormous. This post covers when multi-region is justified, the two architectures that actually work in production, and the data consistency problems you have to solve before anything else.
When Multi-Region Is (and Isn't) Justified
Justified when: - Your SLA requires 99.99%+ uptime (regional AWS outages are rare but real) - You have users in multiple geographic regions with latency requirements - Your compliance or data residency requirements mandate geographic separation - You're in a regulated industry where data sovereignty requires specific regions
Not justified when: - You want "high availability" but mean multi-AZ, not multi-region (very different) - Your SLA is 99.9% — achievable with multi-AZ deployments at a fraction of the cost - You're pre-revenue or early-stage — operational complexity will slow you down more than outages will
Multi-region doubles (or more) your infrastructure cost, introduces data consistency challenges that have no clean solutions, and significantly increases operational complexity. The decision should be driven by specific requirements, not by ambition.
The Two Architectures That Work
Active-Passive (Disaster Recovery): - Primary region handles all traffic - Secondary region has infrastructure deployed but receives no traffic under normal conditions - Data replicates from primary to secondary (eventual consistency acceptable) - Failover is triggered manually or by automation when primary region has an outage - Recovery Time Objective (RTO): minutes to hours depending on automation - Recovery Point Objective (RPO): depends on replication lag, typically minutes
Active-passive is significantly cheaper than active-active and appropriate when your SLA allows for minutes of downtime during a regional failure.
Active-Active: - Both regions handle live traffic simultaneously - Load is distributed across regions (Route 53 or your CDN routes users to nearest healthy region) - Data is synchronized bi-directionally (or partitioned by region) - Failover is automatic — traffic shifts to the healthy region when one fails - RTO: seconds to minutes - RPO: determined by replication lag, ideally near-zero
Active-active is the correct choice for 99.99%+ SLA requirements, but it requires solving hard data consistency problems.
The Data Consistency Problem
Everything in multi-region eventually fails at data. The CAP theorem is real: in a distributed system, you can have consistency or availability, not both, when a network partition occurs.
Option 1: Single-region database with cross-region read replicas
us-east-1 (primary): RDS PostgreSQL (read/write)
us-west-2 (replica): RDS Read Replica (read-only)
Traffic routing:
- Write requests → us-east-1
- Read requests → closest region
- On us-east-1 failure: promote us-west-2 replica to primary
This is simpler to reason about than true active-active. Writes always go to one region (no conflicts). Reads can be served regionally. The limitation: if your primary region is down, writes are unavailable until the replica is promoted.
Option 2: DynamoDB Global Tables (active-active)
DynamoDB Global Tables provides multi-master replication across regions with eventual consistency. Conflicts are resolved with last-writer-wins semantics:
import boto3
dynamodb = boto3.client("dynamodb", region_name="us-east-1")
# Create global table with replicas
dynamodb.create_global_table(
GlobalTableName="UserSessions",
ReplicationGroup=[
{"RegionName": "us-east-1"},
{"RegionName": "us-west-2"},
{"RegionName": "eu-west-1"},
]
)
DynamoDB Global Tables replication lag is typically under 1 second in practice, making it suitable for most use cases. The constraint: last-writer-wins means conflicting concurrent writes will lose one of the writes. For most operational data, this is acceptable; for financial transactions, it's not.
Option 3: Aurora Global Database
Aurora Global Database provides a primary cluster in one region with read-only secondary clusters in up to 5 regions. Replication lag is typically under 100ms. Promotion of a secondary to primary (on primary region failure) takes under 1 minute:
resource "aws_rds_global_cluster" "main" {
global_cluster_identifier = "main-global-cluster"
engine = "aurora-postgresql"
engine_version = "15.4"
database_name = "myapp"
}
resource "aws_rds_cluster" "primary" {
engine = "aurora-postgresql"
cluster_identifier = "primary-cluster"
global_cluster_identifier = aws_rds_global_cluster.main.id
master_username = var.db_username
# ... primary cluster config
}
resource "aws_rds_cluster" "secondary" {
provider = aws.us_west_2
engine = "aurora-postgresql"
cluster_identifier = "secondary-cluster"
global_cluster_identifier = aws_rds_global_cluster.main.id
# ... secondary cluster config (read-only until promoted)
}
Aurora Global Database is the recommended database layer for most active-passive multi-region deployments requiring PostgreSQL or MySQL compatibility.
Traffic Routing: Route 53 Health Checks and Failover
Route 53 handles DNS-based traffic routing across regions:
# Health check for primary region endpoint
resource "aws_route53_health_check" "primary" {
fqdn = "api.us-east-1.yourdomain.com"
port = 443
type = "HTTPS"
resource_path = "/health"
failure_threshold = "3"
request_interval = "30"
}
# Primary region DNS record with failover routing
resource "aws_route53_record" "primary" {
zone_id = data.aws_route53_zone.main.zone_id
name = "api.yourdomain.com"
type = "A"
failover_routing_policy {
type = "PRIMARY"
}
health_check_id = aws_route53_health_check.primary.id
set_identifier = "primary"
alias {
name = aws_lb.primary.dns_name
zone_id = aws_lb.primary.zone_id
evaluate_target_health = true
}
}
# Secondary region as failover target
resource "aws_route53_record" "secondary" {
zone_id = data.aws_route53_zone.main.zone_id
name = "api.yourdomain.com"
type = "A"
failover_routing_policy {
type = "SECONDARY"
}
set_identifier = "secondary"
alias {
name = aws_lb.secondary.dns_name
zone_id = aws_lb.secondary.zone_id
evaluate_target_health = true
}
}
Route 53 TTL affects failover speed — lower TTL means faster DNS propagation during failover but higher DNS query costs. 60-second TTL is a common production choice.
The Real Cost of Multi-Region
Understand the cost before committing: - Duplicate compute: Every EC2 instance, Lambda configuration, and EKS node group exists in two regions - Data transfer: Cross-region data transfer is expensive ($0.02/GB for in-region, $0.08-0.09/GB for cross-region). For data-intensive workloads, replication costs alone can be substantial - Duplicate data storage: S3, RDS, and DynamoDB costs scale with redundancy - Operational overhead: Every change now needs to be deployed and tested across two regions - Monitoring complexity: Two regions worth of metrics, logs, and alerts
For most production SaaS platforms, multi-region adds 60-100% to infrastructure cost. Budget for this before committing to the architecture.
Talk to Rutagon About Multi-Region Architecture
If your availability requirements are driving toward multi-region, Rutagon designs and implements the architecture — from database replication to traffic routing to failover automation. Contact us at rutagon.com/contact.
See also: AWS VPC security groups best practices and cloud infrastructure capabilities.
FAQ
Is multi-AZ the same as multi-region?
No — these are completely different. Multi-AZ (multiple Availability Zones within a single region) protects against a single data center failure. RDS Multi-AZ provides automatic failover if one AZ fails. Multi-region protects against an entire AWS region going offline. For most teams, multi-AZ with proper architecture is sufficient for 99.9% SLA; multi-region is required for 99.99%+ or geographic distribution.
How do you handle database schema migrations in a multi-region setup?
Backward-compatible migrations first. Deploy the schema change (add column, add index) before deploying the application code that uses it. This allows both the old and new application versions to run against the new schema. Never deploy schema changes and application changes simultaneously across two regions — the rollback path becomes impossible.
Can Terraform manage multi-region infrastructure cleanly?
Yes, using provider aliases. Define multiple AWS provider configurations with different regions, then assign providers to specific resources. Use separate state files per region, linked through Terraform data sources for cross-region references. Workspace-based multi-region management is an alternative but more complex. The provider alias approach with separate state files is the most maintainable pattern.
What's the minimum team size for multi-region to be operationally sustainable?
For active-passive: 3+ infrastructure engineers, with at least one having previous multi-region experience. For active-active: 5+ infrastructure engineers with dedicated on-call rotation. Below these thresholds, the operational burden of managing multi-region often outweighs the availability benefit — a smaller team will have more outages from operational errors than they would from regional AWS failures.
How do you test multi-region failover without actually having an outage?
Game days — planned failover drills where you intentionally shift traffic to the secondary region and verify it handles production load correctly. Start with read traffic only (shift reads to the secondary replica), then graduate to full failover testing with write traffic. AWS Fault Injection Simulator (FIS) can automate regional failure simulations in non-production environments. Document your runbook from each game day — the value is as much in the process refinement as in confirming the system works.