Amazon Application Recovery Controller (ARC) routing control provides a highly available control plane for switching DNS traffic between application replicas, typically across AWS Regions. Routing controls are simple on/off states connected to specialized Route 53 health checks; changing a routing-control state changes the health status Route 53 sees and therefore which failover/weighted records receive client traffic.
Within AWS Architecture and Operations, ARC failover is valuable when disaster recovery needs an explicit operator/API-controlled switch rather than relying only on endpoint health checks. The existing Route 53 routing policies article provides the DNS-routing foundation.
ARC should be designed before the incident: recovery cells, control panels, safety rules, health checks, runbooks, and readiness checks all need to exist while the primary system is healthy.
Routing controls are independent on/off switches
Each routing control represents whether traffic should be directed to a cell or application replica.
The control itself is not a synthetic health probe of the application. It is an operator/automation state used to drive a Route 53 health check.
This separation makes failover intentional: operations can move traffic because of a regional incident, bad deployment, external dependency, or other evidence the automatic endpoint check might not capture.
Control panels group related routing controls
ARC clusters contain control panels, and control panels contain routing controls.
Group controls that participate in the same recovery decision so safety rules can reason about them together.
A multi-Region active/standby application commonly has controls representing the active state of each regional cell.
ARC clusters expose five regional data-plane endpoints
Each routing-control cluster provides endpoints in five AWS Regions for getting/updating routing-control state.
AWS recommends using the cluster data-plane endpoints rather than the control-plane console path during recovery and trying endpoints in sequence when one is unavailable for maintenance or failure.
Runbooks and automation should preconfigure all endpoints rather than performing service discovery during the incident.
Route 53 health checks connect routing control to DNS
When a routing control is created, it is associated with an ARC routing-control health check that Route 53 routing records can use.
Turning the control Off makes the associated health check unhealthy; turning it On makes it healthy.
DNS records then apply normal Route 53 failover/weighted logic, subject to DNS TTL and resolver/client caching.
Safety rules prevent catastrophic operator combinations
ARC safety rules can prevent invalid combinations such as turning all replicas off or can create a gating/override control around a group of routing controls.
Use assertion rules to preserve invariants such as “at least one Region must be On.”
This is critical when failover is automated or when responders are making changes under incident pressure.
Failover should update controls through API/CLI in a practiced runbook
AWS recommends using API or CLI operations for routing-control state changes in recovery automation.
The runbook should read current state, validate safety-rule constraints, update the intended controls—often as a coordinated change—and verify the new state.
Do not use a first-time console walkthrough as the disaster-recovery procedure for a critical service.
DNS TTL still determines client convergence
ARC changes the health signal quickly, but clients/resolvers can continue using cached DNS answers until TTL expires.
Choose Route 53 record TTLs consistent with required RTO while considering query volume and DNS-cache behavior.
Measure real client failover from representative networks instead of assuming routing-control state change equals instantaneous user traffic movement.
Readiness checks are for preparedness, not the critical failover path
ARC readiness checks continuously evaluate configuration, capacity, quotas, and routing-policy parity between recovery cells.
AWS explicitly states readiness checks are not intended to be queried in the critical path of an event before failover.
Use them during steady state to find capacity or configuration drift so the standby is ready when the routing control is needed.
Zonal shift solves a different failure scope
ARC zonal shift/autoshift moves traffic away from an impaired Availability Zone inside one Region for supported resources.
Routing control handles application traffic steering between cells/Regions through Route 53.
Use the smallest recovery mechanism that matches the failure: a bad AZ does not necessarily justify a cross-Region failover with broader operational consequences.
Recovery exercises should test both failover and failback
Practice moving traffic to the standby, sustaining full load there, and returning to the original region after it is repaired.
Verify database/data replication, async queues, caches, credentials, KMS keys, capacity, and observability—not just the DNS switch.
Cross-Region resilience explains why the traffic switch is only one part of regional recovery.
ARC failover succeeds when the traffic switch is fast, safe, and rehearsed
The mature architecture has independent cells, five-endpoint routing-control automation, safety rules, Route 53 records with appropriate TTL, continual readiness checks, and proven failback.
ARC’s value is not merely another health check; it is a durable recovery control surface designed to work when the Region or application path you normally operate from is impaired.
Cells should be independently deployable and sufficiently isolated that failing one does not remove control or dependencies needed by the other. Shared databases, identity services, KMS keys, CI/CD, or network egress can turn a two-Region DNS design into one logical failure domain. ARC controls traffic; it cannot make the standby independent for you.
Failover decisions should use a defined set of signals and authority. Combine application health, data replication lag, dependency status, customer impact, and regional events into a runbook that says who may flip routing controls. Avoid automatic failover based on one noisy metric unless the application has been engineered and tested for that specific automation.
Safety rules should be tested, not merely created. Try the prohibited state transition in a practice environment and confirm ARC rejects it. During incidents, responders need confidence that an assertion or gating rule really prevents “both off” or another invalid combination instead of discovering a misconfigured safety rule at the worst time.
DNS records should be designed around cell-level endpoints, not individual instances. Use load balancers, API endpoints, or other stable regional front doors as the Route 53 targets so routing control moves the whole application replica. Instance-level failover creates an operational surface too fine-grained for regional disaster recovery.
Data-plane credentials and endpoints should be available out of band. If the primary Region or corporate identity path is impaired, responders still need a way to call ARC cluster endpoints. Store runbook commands, endpoint list, and appropriate emergency credentials securely in a recovery system that does not depend on the failed cell.
Route 53 resolver/client caching should be included in RTO measurements. Even with low TTL, local DNS resolvers, JVMs, browsers, or proxies can cache answers longer than expected. Test from representative client networks and application stacks so the business understands the real traffic-shift curve rather than only the authoritative DNS update time.
Readiness checks can identify quota and configuration drift before an event, but their output should feed a remediation backlog. An always-red readiness dashboard that no team owns becomes background noise. Assign owners and deadlines for capacity mismatches that could prevent the standby from absorbing full traffic.
Failback often carries more data risk than failover. After running in the secondary Region, decide how data written there is reconciled and when the original Region is safe to become active again. The routing-control switch should be the final step after data and dependencies are ready, not the first instinct once the original health check turns green.
ARC routing controls should not be driven by ordinary health checks automatically unless the application has been explicitly designed for that behavior. One transient dependency alarm can otherwise trigger a regional data-consistency event. Keep automatic failover criteria narrower than alerting criteria and require multiple signals or human approval for high-impact switches.
Routing-control state changes should be idempotent and recorded. Automation should read current state, use the ARC data-plane endpoint, submit the desired state, verify the response, and write an incident timeline. Retrying the same desired state is safer than scripts that blindly toggle whatever state happens to exist.
Practice exercises should include an ARC endpoint failure. Runbook automation needs to try the five cluster endpoints in sequence rather than assuming one endpoint is always reachable. Store endpoint configuration outside the failing application cell and test credentials from the recovery environment.
Traffic-shift validation should include synthetic transactions and backend load after DNS moves. Seeing the standby Route 53 record become healthy is not proof the replica can process all customer workflows. Verify authentication, writes, asynchronous processing, dependencies, and capacity while the original cell is intentionally out of service.
Data consistency should set the minimum safe failover point. A healthy standby endpoint is not enough if replication lag would lose committed writes or if the secondary is intentionally read-only. ARC gives the switch, but the application must define the state at which the standby may accept full traffic and which degraded modes are allowed before that point.
Recovery automation should use safety rules as a guardrail, not as the only validation. Before switching, confirm the target cell is ready, dependencies are reachable, and capacity alarms are clear. Safety rules can prevent certain invalid control combinations, but they cannot tell whether the standby database is hours behind or whether credentials expired.
Post-event reviews should capture DNS convergence, routing-control API latency, standby saturation, customer error rate, and failback issues. Feed those observations into TTL, capacity, runbook, and readiness-check changes so each exercise improves the actual recovery time rather than simply proving the control can toggle.
