AWS Architecture Series #8 — Route 53 ARC: Multi-Region DR That Actually Holds Up Under Pressure

Business Challenge

A payments platform processes card authorisations across two AWS regions: us-east-1 (active) and us-west-2 (passive). Their RTO target is 3 minutes, RPO is 30 seconds. They have Aurora Global Database with sub-second replication, DynamoDB global tables, and Route 53 failover records. On paper it works. In the last regional impairment it took 8 minutes to complete failover — three times their SLA — and finance calculated $300K per minute in lost transaction volume.

The post-mortem found three failure modes stacked on top of each other. First, Route 53 health checks with a 30-second evaluation period meant the DNS change did not propagate until after clients had already started timing out. Second, the passive region was configured for 30% of production capacity — nobody had updated the Auto Scaling group targets in six months. Third, there was no mechanism to prevent both regions from being set to active simultaneously if an engineer ran the wrong runbook.

Each failure was real, but they had the same root cause: their multi-region architecture was a collection of independent components with no coordination layer. Route 53 ARC is that coordination layer. AWS has since renamed it Amazon Application Recovery Controller — still ARC, and the docs now sit under that name, but the routing-control model described here is unchanged.

Architecture

ARC has two distinct recovery surfaces: multi-region recovery via routing controls, and multi-AZ recovery via zonal shift and zonal autoshift. They solve different problems and are operated independently.

Routing controls: the multi-region layer

A routing control is a simple boolean switch — ON or OFF. Each control is tied to a Route 53 routing control health check, which in turn drives a DNS record (typically a failover or weighted record). You flip the control through the ARC API; Route 53 updates the health check state, and DNS propagates.

The critical design point: routing control state lives in an ARC cluster, which AWS describes as “a data plane of endpoints in five AWS Regions”. You talk to one endpoint; if it is unavailable you try another. AWS does not publish a quorum figure for how many of the five must be reachable, so do not design against an assumed number — design against the instruction it does give, which is to keep a local copy of all five endpoint addresses and write retry logic that can work through every one of them. That is the difference between a control plane that survives a regional impairment and one that merely claims to.

Safety rules: preventing the worse outcome

The feature that turns ARC from "fast DNS switch" into "safe failover mechanism" is safety rules. There are two types:

For the payments platform, the critical safety rule is: exactly one of the two regional routing controls can be ON at any time. This makes split-brain impossible by design rather than by convention.

Zonal shift and zonal autoshift: the AZ layer

Not every impairment is regional. A bad deployment, a noisy-neighbour compute issue, or an isolated AZ network event should not require a full region failover. ARC's zonal shift addresses this with a separate mechanism.

A zonal shift temporarily moves traffic away from a specific AZ to the remaining healthy AZs in the same region. You initiate it manually with an expiration you set (up to 3 days, extendable). The shift works at the load balancer level — ARC integrates with ALB and NLB to mark an AZ unhealthy, causing the load balancer to stop routing to targets in that AZ.

Zonal autoshift is the same mechanism but automated: AWS uses internal telemetry — network metrics, EC2 data, ELB signals — to detect AZ-level impairments before they become customer-visible. When it detects a potential issue, it automatically initiates a zonal shift on your behalf. No human action required. You opt in per resource.

What about readiness checks?

ARC historically included readiness checks — a feature that continually monitored whether your passive region's resource capacity, quotas, and routing configuration matched production. As of 2025, readiness checks are no longer available to new customers. Existing customers can continue using them, but new architectures cannot rely on them.

For new deployments, cover the same ground with:

• CloudWatch cross-region alarms — monitor Auto Scaling group sizes, ALB target group healthy host count, and RDS replica lag in the passive region
• AWS Health events (via EventBridge) — detect service quota exhaustion or capacity signals in the passive region before you need it
• CloudWatch Synthetics canaries — smoke-test the passive region's endpoints on a schedule so you know it responds before you flip traffic to it
• Infrastructure parity checks in CI — Terraform plan drift detection or AWS Config conformance packs to catch configuration skew between regions before an incident

Why This Architecture Holds Up

The payments platform's 8-minute failover had nothing to do with DNS propagation speed. It had everything to do with the absence of a control plane that was independent of the data plane failure. When us-east-1 was impaired, the tools they needed to execute recovery were themselves partially impaired. ARC's cluster design solves this directly: the five-region endpoint spread means the control plane operates even when the region you're failing away from is unavailable.

Key Architecture Decisions

1. One cluster per environment, not one per application

An ARC cluster is a regional control plane, not an application-scoped resource. Create one cluster per environment (production, staging) and put all your application routing controls on it. Multiple control panels on a single cluster give you logical separation without the operational overhead of managing multiple clusters. A cluster costs approximately $2.50/hour — shared across all applications in that environment.

2. Safety rules before routing controls

Design your safety rules before you create routing controls. The canonical rule for active-passive DR is an assertion rule with MinimumControls: 1 and MaximumControls: 1 — exactly one region active at any time. Add a second assertion with MinimumControls: 1 to ensure you cannot accidentally deactivate all regions. These two rules together eliminate both split-brain and complete blackout.

3. Region switch for orchestrated failover

ARC's Region switch feature (added after the original routing controls) provides a higher-level abstraction: you define a recovery plan that captures the correct sequence of steps — stop writes to primary, promote Aurora replica, flip routing controls, validate canary — and Region switch executes them in order. For complex applications with multiple dependencies, Region switch reduces the risk of runbook step ordering errors during a high-pressure incident.

4. Opt into zonal autoshift selectively

Zonal autoshift is powerful but has implications: it can shift traffic automatically without human approval. For most workloads this is the right default. For workloads with strict compliance requirements where any topology change must go through a change management process, opt out and use manual zonal shift instead. The configuration is per resource.

5. Passive region capacity is a process problem, not a tool problem

ARC cannot ensure your passive region has enough capacity to handle production load. That is your infrastructure parity process. Common patterns: run passive at 100% of active capacity (expensive, but eliminates cold-start scaling risk), use a scheduled warm-up that scales passive to production size 15 minutes into a regional event, or accept a gradual scale-out as part of your RTO budget. The payments platform's 8-minute failover was partially caused by a 6-minute Auto Scaling warmup period. ARC cut the routing time to under 60 seconds; the remaining 5 minutes was capacity.

Closing Thought

Multi-region DR is not primarily a networking problem. It is a coordination problem: how do you execute a state change across two regions, under partial failure conditions, without introducing a worse failure? Route 53 ARC's routing controls and safety rules give you a control plane that is explicitly designed for this. The cluster's five-region spread means it works when you need it. Safety rules mean the state machine only allows valid transitions.

The tool does not remove the hard parts — passive region capacity management, database promotion sequencing, cache warming, downstream dependency cutover. Those are still yours to design. What ARC removes is the risk that the traffic flip itself goes wrong: that you end up with both regions active, or neither, or a half-propagated DNS state that you can't observe. For a $300K-per-minute workload, that certainty is worth the operational overhead of setting it up.

Official AWS Reference

• What is ARC — zonal shift, zonal autoshift, routing control, Region switch and readiness check
• Routing control in ARC — clusters, control panels and routing control health checks
• Best practices for routing control — the five endpoints, retry logic and DNS TTL guidance
• Readiness check in ARC — including the note that it is closed to new customers
• Zonal autoshift in ARC