“Multi-region” means at least three different things in AWS conversations: full active-active where both regions serve live traffic, active-passive where one region is warm standby, and cold disaster recovery where the second region activates only during a declared outage. The architecture, cost, and operational complexity are very different across these three patterns.
Most teams want active-active but need to understand what it actually requires before committing to it.
The three patterns
Active-passive (warm standby)
Your primary region handles all traffic. The secondary region has a warm replica: database replication is running, ECS or Lambda services are deployed and ready, load balancers exist. Failover time: 5-30 minutes depending on automation.
When it’s appropriate: RPO (recovery point objective) under 1 hour, RTO (recovery time objective) under 30 minutes, but you don’t need or can’t afford the complexity of active-active. Common in fintech, healthcare, and SaaS products where regional AWS outages are an acceptable trigger for failover but cross-region traffic routing at steady state isn’t worth the cost and engineering overhead.
Key components:
- RDS Multi-AZ in primary region (synchronous replication within region) + RDS read replica cross-region (asynchronous, ~1-5 second lag for write acknowledgment)
- Route 53 health checks with failover routing records
- Identical application stack deployed in secondary region (ECS services, Lambda functions, API Gateway) but at zero or minimal capacity
- Regular failover testing (quarterly minimum for any serious RPO commitment)
The cost model: Primary region runs at full capacity. Secondary region pays for: RDS replica (~$0.20/GB data transfer for cross-region replication), dormant ECS task definitions (no cost until tasks run), Route 53 health checks ($0.50/health check/month). Estimated overhead: 15-30% of primary region cost.
Active-active (dual write)
Both regions serve live user traffic. Writes go to both regions (or to the user’s closest region with cross-region replication). This eliminates the “failover” concept — if one region degrades, the other continues serving traffic without any explicit failover action.
When it’s appropriate: You have a global user base with latency requirements that make single-region suboptimal, you need continuous availability (99.99%+), or you’ve built for compliance requirements that mandate geographic data distribution.
What gets hard:
Database consistency. This is the core challenge of active-active. You have two writable database instances in different regions. If a user creates a record in us-east-1 and a concurrent request in eu-west-1 modifies something related, you have a distributed write problem. Solutions:
- Global routing to single write region: Use latency-based routing but direct writes to one primary region. Reads are served locally, writes incur cross-region round trip. Simple to reason about, not true active-active for writes.
- DynamoDB Global Tables: DynamoDB natively handles multi-region replication with eventual consistency (typically <1 second replication lag). No conflict resolution complexity for most workloads. If two regions write to the same item simultaneously, last-writer-wins. For most application data (user records, sessions, configuration), this is acceptable.
- Aurora Global Database: Aurora supports global tables with a primary region (writes) and secondary regions (reads). Replication lag under 1 second globally. For a write-heavy workload, this still means all writes go to one region — just reads are local.
The honest answer: true multi-master relational database writes across regions, with strong consistency, remains an unsolved problem in the general case. Either accept eventual consistency (fine for most applications), shard writes by region (complicated application logic), or accept that writes go to one region (which isn’t true active-active for writes).
Session and state management. User sessions must be region-independent. If a user’s session is stored in a Redis cluster in us-east-1 and their next request routes to eu-west-1, they get logged out. Solutions: DynamoDB Global Tables for session storage, or a cross-region Redis cluster (ElastiCache Global Datastore, ~$0.20/GB replication transfer).
Idempotency. Multi-region writes require idempotency at every mutation endpoint. If a write partially succeeds in one region and fails in another, and the client retries, the system must handle the duplicate without doubling the effect.
Cost. Active-active roughly doubles your compute cost (two regions running at capacity) plus adds cross-region data transfer ($0.02/GB for most region pairs, $0.09/GB for regions outside the US/EU zone). For a medium-sized SaaS product spending $30K/month in a single region, active-active typically runs $60-80K/month.
Disaster recovery (cold standby / pilot light)
The secondary region has minimal running infrastructure: essential services only (identity, networking basics). Most infrastructure is defined in IaC but not running. Recovery time: 30 minutes to 4 hours depending on what needs to be provisioned.
When it’s appropriate: RPO of a few hours is acceptable, RTO can be measured in hours, and cost efficiency is a priority. Common for internal tools, early-stage products, and systems where a regional outage is extremely rare and business continuity can tolerate the recovery window.
Key components:
- IaC (CloudFormation or Terraform) that can deploy the full stack in the secondary region with a single command
- Database snapshots cross-region copied on a schedule (hourly, daily — depending on RPO)
- Runbook tested quarterly
- Route 53 manual failover procedure documented
This is the cheapest option: secondary region costs are essentially just the data transfer for snapshot copies and a minimal NAT Gateway to keep networking warm.
Data residency and compliance
For GDPR (EU), PIPEDA (Canada), and certain financial regulations, data residency requirements may dictate that user data stays in specific geographic regions. This complicates multi-region significantly: if EU user data cannot leave the EU, you can’t replicate that data to a US region for DR purposes. You need a separate DR region within the EU, separate KMS keys scoped per region, and application-layer data routing that enforces the geographic constraint.
If your product serves users in multiple regulatory jurisdictions, model the data residency requirements before choosing a multi-region pattern. The architecture that satisfies GDPR without custom work is different from the architecture that maximizes global availability.
Route 53: the traffic layer
Route 53 is the global entry point for multi-region architectures. The relevant routing policies:
Failover routing: Primary/secondary endpoints. Route 53 health-checks the primary; if it fails, traffic routes to secondary. Works for active-passive.
Latency-based routing: Routes users to the region with lowest latency. Works for active-active or read routing.
Geolocation routing: Routes users based on geographic location. Useful for data residency compliance.
Health check configuration matters. Route 53 health checks by default poll every 30 seconds with a 3-failure threshold before routing around a failed endpoint. That’s ~90 seconds of degraded service before failover. For tighter RTO, configure shorter intervals (10 seconds) and lower failure thresholds.
TTL matters. DNS TTL for failover records should be 60 seconds or less. If you set a 5-minute TTL, clients that cached the primary endpoint before failure continue hitting the degraded region for up to 5 minutes after Route 53 has updated the record.
What actually fails during AWS regional events
AWS regional events are uncommon but not rare. The common failure modes that trigger multi-region considerations:
Specific AZ degradation (most common): One AZ within a region experiences hardware or networking issues. Multi-AZ within the region handles this — you don’t need multi-region for AZ failures. Ensure your resources are deployed across at least 2 AZs in every region.
Specific service degradation: A specific AWS service in one region (S3, API Gateway, Lambda) degrades. If your application depends on that service and it’s not replicated, you’re affected regardless of multi-region configuration. Understand your critical dependencies per region.
Full regional outage (rare): An entire AWS region experiences major degradation. us-east-1 (N. Virginia) has had notable events (December 2021 being the most impactful). Multi-region architecture with automatic failover handles this.
Before investing in multi-region, audit which failure modes your SLA requires protection against. Multi-AZ within one region is often the right answer for AZ-level resilience, and it’s substantially cheaper.
The global accelerator option
AWS Global Accelerator routes traffic to the optimal AWS endpoint using the AWS backbone network rather than the public internet. For multi-region, it provides:
- Single Anycast IP addresses that work across regions
- Health-based routing between regions
- Faster failover than DNS-based (seconds vs DNS propagation)
Cost: $0.025/hour per accelerator + $0.015/GB data processed. For high-traffic global applications, the performance and failover speed improvements justify the cost. For low-traffic applications, the DNS-based Route 53 approach is sufficient.
The engineering and operational cost
Multi-region architecture isn’t just infrastructure cost — it’s engineering cost:
Initial build: 4-8 weeks of senior engineering time to build, test, and document a well-architected multi-region setup. Active-active is closer to 3-6 months.
Ongoing operations: Failover testing (quarterly), drift detection between regions, replication lag monitoring, separate deployment pipelines that coordinate across regions.
Runbook maintenance: Your runbooks for incident response become more complex. Any procedure that involves “restart the service” now involves “restart the service in both regions, in order, after confirming replication state.”
Build the capability if the business requires it. Don’t build it speculatively — an application with 10,000 users and a business-hours SLA doesn’t need active-active multi-region.
Getting it right
Multi-region architecture is one of the more expensive engagement types to design and implement correctly — the failure modes are non-obvious, the consistency tradeoffs are real, and the operational overhead is sustained. I help engineering teams design the right pattern for their availability requirements and implement it without over-engineering.
If you’re evaluating multi-region for an upcoming architecture decision, let’s talk.
Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.