AWS Multi-Region Failover: Route 53, Global Accelerator, Aurora, and DynamoDB Global Tables
Multi-region failover fails most often in the parts teams assumed were automatic: traffic steering, write ownership, schema drift, and the human decision to promote a secondary system.
Situation
Most AWS multi-region designs start with a reasonable fear: one region can become unavailable, impaired, partitioned, or operationally unsafe to use. The business wants continuity. The engineering team wants a design that can move traffic elsewhere without rewriting the application during an incident.
AWS gives several building blocks that look like they solve the problem independently. Route 53 can steer DNS traffic based on health checks. AWS Global Accelerator can route users through the AWS edge network to healthy regional endpoints. Aurora Global Database can replicate relational data across regions with a primary writer and secondary readers. DynamoDB global tables can replicate items across regions with active-active writes.
The trap is treating these as interchangeable failover tools. They are not. They operate at different layers, with different consistency models, different failure detection semantics, and different operational blast radii.
A serious architecture has to decide which layer owns failover, which data stores are allowed to accept writes, and which recovery objective matters more: minimizing downtime or preventing incorrect writes.
The Problem
The hard part of multi-region failover is not detecting that a region is broken. The hard part is proving that the replacement region is safe to make authoritative.
DNS failover can move new clients, but cached answers and long-lived connections continue to exist. Global Accelerator can shift traffic faster at the network edge, but it cannot make a database replica writable or resolve application-level corruption. Aurora can replicate relational changes to another region, but the secondary is not automatically equivalent to a fully promoted primary. DynamoDB global tables can accept writes in multiple regions, but conflict resolution becomes part of the application contract.
The most dangerous failure mode is split ownership. One region believes it is still primary while another region has been promoted. That creates double writes, divergent state, idempotency failures, and reconciliation work that may exceed the original outage.
The second failure mode is partial failover. The load balancer moves traffic, but background workers, queues, scheduled jobs, secrets, feature flags, and observability pipelines still point at the old region. The user-facing path appears recovered while the system quietly loses work.
The third failure mode is false confidence from successful read failover. Serving stale or read-only traffic from a secondary region is useful, but it is not the same as accepting new orders, payments, writes, or irreversible workflow transitions.
The core question is: which part of the system is allowed to decide that a different region is now the source of truth?
The Answer: Separate Traffic Failover from Authority Failover
A resilient design separates four concerns: client entry, regional application health, relational write authority, and globally replicated key-value state.
flowchart TD
U[users] --> E[edge entry — Route 53 or Global Accelerator]
E --> A[primary region — application fleet]
E --> B[standby region — application fleet]
A --> C[Aurora primary — write authority]
C --> D[Aurora secondary — replicated reader]
A --> G[DynamoDB global table — regional replica]
B --> H[DynamoDB global table — regional replica]
G --> H
D --> I[promotion runbook — controlled authority change]
I --> J[new Aurora primary — writes enabled]
B --> J
Route 53 and Global Accelerator should answer the question, “Where should clients enter the system?” They should not answer, “Which region owns the data?”
Route 53 failover is a good fit when DNS-level steering is acceptable and the application can tolerate resolver caching behavior. It is simple, widely understood, and integrates with health checks. The operational cost is that failover is not instantaneous for every client, because DNS answers can live beyond the moment when health changes.
Global Accelerator is better when fast traffic steering and stable anycast IP addresses matter. It routes traffic to healthy endpoints and can reduce dependency on DNS propagation behavior. It is still a traffic-entry mechanism. It does not remove the need to validate that the standby application, dependencies, and data layer are ready.
Aurora Global Database should usually be treated as single-writer infrastructure. The primary region owns relational writes. Secondary regions can serve reads, support low-latency reporting, and become candidates for promotion. Promotion should be explicit, automated through a runbook, and guarded by checks: replication lag, schema version, migration state, job ownership, and write fences.
DynamoDB global tables fit a different class of data. They are useful for regional session state, user preferences, idempotency records, distributed configuration, and workloads that can tolerate or resolve last-writer behavior. They are not a magic replacement for relational consistency. If an item can be updated concurrently in two regions, the application must be designed around that possibility.
The practical architecture is often active-passive for relational writes and active-active for carefully selected DynamoDB tables. That gives the standby region enough live behavior to stay warm without pretending every data model supports multi-master writes.
In Practice
Context: AWS documents Route 53 health checks and failover routing as DNS-based mechanisms for directing traffic away from unhealthy endpoints. The documented pattern is traffic steering based on health, not transactional correctness.
Action: Use Route 53 failover records only for endpoints whose health checks represent the full serving path. A shallow health check that returns 200 while the application cannot write to its database is worse than no health check. For write-heavy systems, expose a regional readiness endpoint that checks dependency reachability, migration compatibility, queue access, and whether the region is currently authorized to accept writes.
Result: The failover decision becomes tied to user-visible capability rather than instance uptime. DNS still has caching behavior, so recovery expectations must be expressed as ranges, not promises of immediate global convergence.
Learning: Route 53 is useful for regional steering, but it should be downstream of an authority model. It cannot decide whether Aurora has been safely promoted.
Context: AWS Global Accelerator is documented as an edge networking service that routes traffic to healthy regional endpoints using static anycast IP addresses. The pattern is faster network-level steering through AWS edge locations.
Action: Put Global Accelerator in front of regional load balancers when fast endpoint withdrawal matters. Keep regional health checks strict, and avoid using accelerator failover as a substitute for application readiness. During an incident, the accelerator can stop sending new traffic to a region, but existing stateful workflows still need application-level recovery.
Result: Client entry becomes less dependent on DNS resolver behavior. The system still needs a separate plan for database promotion, queue replay, and regional write fencing.
Learning: Global Accelerator improves traffic movement. It does not change the consistency model of the backing services.
Context: Aurora Global Database is documented around one primary AWS Region for writes and secondary regions for low-latency reads and disaster recovery. The known behavior is asynchronous cross-region replication with promotion of a secondary when the primary is unavailable or intentionally moved.
Action: Treat Aurora promotion as an authority-changing operation. Before promotion, fence old writers if possible, stop regional workers that can mutate state, check replication lag, verify schema version, and record the promotion decision in an operational log. After promotion, update application configuration so only the new primary receives relational writes.
Result: The system avoids the worst failure mode: two regions writing to different relational primaries. Recovery may take longer than pure traffic failover, but the data outcome is more defensible.
Learning: For relational data, correctness usually deserves a human-approved or strongly guarded automated step. Fast failover that corrupts state is not resilience.
Context: DynamoDB global tables are documented as multi-region, multi-active replication. AWS documents conflict handling through last-writer-wins reconciliation.
Action: Use global tables for data models where concurrent regional writes are acceptable or naturally idempotent. Good candidates include session records, request deduplication keys, feature exposure state, and user-local metadata. Avoid putting strongly ordered financial ledgers or relational aggregates into global tables unless the application owns conflict resolution explicitly.
Result: The standby region can serve meaningful live traffic before Aurora promotion. Some state remains close to users and resilient to regional failure, while strict relational state stays under single-writer control.
Learning: Active-active data is an application contract, not a checkbox. If the business cannot explain the conflict rule, the table should not accept writes in multiple regions.
Where It Breaks
| Failure mode | What happens | Mitigation |
|---|---|---|
| Health check lies | Traffic moves to a region that is alive but not capable | Check real dependencies and regional write authority |
| DNS cache delay | Some clients keep using the old endpoint | Use low TTLs where appropriate, and consider Global Accelerator for faster steering |
| Aurora split brain | Two regions accept relational writes | Fence writers and make promotion explicit |
| Replication lag | Secondary region is missing recent writes | Measure lag before promotion and define acceptable data loss |
| Global table conflict | Two regions update the same item | Design idempotent writes or explicit conflict handling |
| Background jobs stay active | Workers mutate state in the failed or old primary region | Add regional job leases and disable old workers during promotion |
| Schema drift | Standby app version does not match database state | Make migrations region-aware and verify version before traffic shift |
| Observability gap | The team cannot prove which region is authoritative | Emit authority state, promotion events, and regional dependency status |
What to Do Next
- Problem: Traffic failover and data authority are often bundled together, which creates split ownership during incidents.
- Solution: Use Route 53 or Global Accelerator for entry-point steering, Aurora Global Database for controlled relational promotion, and DynamoDB global tables only for data models that tolerate multi-region writes.
- Proof: The documented AWS patterns line up with this separation: DNS and edge services steer traffic, Aurora preserves a primary-writer model, and DynamoDB global tables replicate active-active items with conflict semantics.
- Action: Write the failover runbook before the next incident. Include health-check definitions, writer fencing, Aurora promotion steps, DynamoDB conflict assumptions, queue and worker behavior, rollback rules, and a game day that proves the standby region can become authoritative without data ambiguity.