Cross-Region failover
Failing over between Regions is two problems. Getting traffic to the surviving Region is the network layer. Having something there worth failing over to is the data layer, and it is the harder of the two.
Route 53 or Global Accelerator
Section titled “Route 53 or Global Accelerator”Route 53 moves traffic by changing what a DNS query returns. Failover is bounded by the health check interval and by the record’s TTL — and by clients and resolvers that hold addresses longer than the TTL says they should, which many do. Practically, budget tens of seconds to minutes.
Global Accelerator moves traffic by changing where its two static anycast addresses route to. The addresses do not change, so DNS caching is irrelevant and failover is a network event measured in seconds.
Choose Route 53 when:
- DNS-based failover is fast enough
- You want domain-based routing, and several routing policies composed together
- Cost is the deciding factor
- A simple configuration is worth more than the last few seconds
Choose Global Accelerator when:
- Failover has to complete in seconds
- The application needs static IP addresses for firewall allow-lists or legacy clients
- The traffic is TCP or UDP rather than HTTP
- Optimising the network path to the application matters as much as failover
- Client IP preservation is required
For most Regional failover, Route 53 is sufficient. Global Accelerator earns its cost where the failover budget is seconds or the application needs fixed addresses.
The mechanisms behind the failover
Section titled “The mechanisms behind the failover”Moving traffic is pointless unless the second Region has current data and enough capacity. The relevant AWS services:
Amazon S3 Cross-Region Replication. Replicates objects to a bucket in another Region asynchronously. Requires versioning on both buckets. S3 Replication Time Control gives a replication SLA if the lag matters.
Amazon Aurora Global Database. Replicates to secondary Regions with typical lag around a second, and promotes a secondary in about a minute. The failover is managed, but it is still a promotion, not a symmetric multi-master arrangement.
Amazon DynamoDB global tables. Multi-Region, multi-active replication with sub-second propagation. Both Regions accept writes; conflicts resolve last-writer-wins, which the application has to be designed for.
Amazon RDS cross-Region read replicas. Asynchronous replication with manual promotion. Also useful for read scaling in the second Region while it is idle.
AWS Elastic Disaster Recovery (DRS). Continuous block-level replication of servers into a staging area, with sub-second RPO and automated failover testing. Suits lift-and-shift workloads that cannot be rearchitected.
CloudFront origin failover. Switches between a primary and secondary origin within a distribution. Because CloudFront makes the decision, there is no DNS propagation delay at all. It applies only to GET, HEAD and OPTIONS requests and only to the status codes you configure — see Amazon CloudFront.
EC2 automatic recovery replaces failed instance hardware within a Region and preserves the instance ID and private address. It is not cross-Region, and it is worth naming here only so it is not mistaken for a Regional failover mechanism.
What to decide first
Section titled “What to decide first”- RTO and RPO. These choose the mechanism. A one-minute RTO rules out anything requiring manual promotion; a zero RPO rules out asynchronous replication.
- Capacity in the second Region. A pilot-light or warm-standby deployment has to scale up before it can carry the load, and that takes time that counts against the RTO.
- Failback. Getting back is usually harder than getting out, because the original Region’s data is now stale and writes have accumulated elsewhere.
- Testing. An untested failover path is an assumption. Exercise it on a schedule.