Amazon Application Recovery Controller in practice: readiness checks, routing controls, zonal autoshift

A composite incident I have walked through with customers more than once: a multi-Region deployment with a primary in eu-west-1 and a warm secondary in eu-central-1. Something starts to go wrong in the primary — a power event in one Availability Zone (AZ) bleeds into a brownout pattern, latency goes asymmetric, and a few minutes later the runbook calls for a Regional failover. The on-call engineer opens the AWS Management Console to flip an Amazon Route 53 weighted alias record. The console is sluggish. The page loads, the form submits, the API call times out. The very control plane the engineer needs to use to escape the impaired Region is itself colored by the same event. Eventually the change goes through, but the failover took twelve minutes longer than the rehearsed runbook suggested, and the post-mortem is going to ask why.

This is the bootstrap problem of recovery. The machinery you reach for to fail away from a problem cannot share fate with the problem itself. If your steering layer depends on the same Regional control plane you are trying to leave, your recovery mechanism is not actually independent of the failure mode it is supposed to mitigate. Amazon Application Recovery Controller (ARC) exists to close exactly that gap.

ARC, formerly Amazon Route 53 Application Recovery Controller, is best understood as a small set of data-plane primitives engineered to keep operating when the rest of your Region is having a bad day. AWS organizes the service across two domains. Multi-Region recovery today comprises routing control with safety rules, the newer Region switch capability, and readiness check. Multi-AZ recovery comprises zonal shift and zonal autoshift. The pieces matter individually, but the architectural posture is the thing to internalize first.

The unit of organization in ARC's Multi-Region story is the cluster. Each cluster is a data plane composed of endpoints in five AWS Regions — five separate API endpoints in five separate failure domains, any one of which can flip your routing controls. AWS describes this layer as extremely reliable, and the operational guidance follows directly: when something is on fire, you do not change routing-control state from the console, because the console and several other API operations are control-plane paths that may not be available to you during the event. You change state by calling the data-plane API, and your client retry logic should treat all five Regional endpoints as equal targets, choosing one at random for each call rather than treating the topology as primary-with-failover.

This is the single most important operational habit to build around ARC. Bookmark or hard-code your five Regional cluster endpoints, drive failover from the data-plane API, and exercise that path under conditions that look like the real thing. A failover runbook that ends in log into the console is a failover runbook that has not internalized the architecture.

A routing control is, at its core, a deliberately small abstraction: an On/Off switch. AWS uses those exact two states. Each routing control is associated with what AWS calls a routing control health check — an Amazon Route 53 health check whose state is driven directly by the routing control's value. Your DNS records, typically failover or weighted alias records, evaluate that health check the way they evaluate any other Route 53 health check. So when an operator flips a routing control from On to Off, the chain is: data-plane API call → routing control state change → routing control health check transitions → Route 53 DNS resolution shifts traffic to the cell whose health check is now passing.

The deliberate simplicity of On/Off is the point. You can build elaborate orchestrations on top, but the primitive itself does one thing, which is exactly what you want at the edge of an incident.

Safety rules sit on top of routing controls and prevent the most common failure mode of any failover system: human error during an incident. ARC supports two types. An assertion rule enforces that any change to one or more routing-control states leaves the system in a permissible configuration; if the requested change would violate the criterion, ARC refuses to apply it. A gating rule is an overall on-off switch over a set of routing controls — it controls whether those target routing controls can be changed at all. You create a gating routing control as the master switch, and ARC blocks or allows updates to the target routing controls based on whether the gate is set to On or Off. Together, the two rule types let you encode invariants such as at least one cell must remain On at all times (an assertion rule) or target routing controls may not be updated unless the gating routing control is explicitly set to On (a gating rule). These invariants are the difference between a failover that recovers the system and a failover that takes both replicas offline at three in the morning.

Worth knowing for capacity planning: the documented per-account quota is two clusters, with a per-cluster ceiling of three hundred routing controls spread across up to fifty control panels, and a maximum of one hundred routing controls per control panel. If you are designing a fleet at that scale, you will hit those numbers before you expect to and should plan the topology accordingly.

Readiness check is the part of ARC that gets misunderstood most often. It does not tell you whether your application is healthy. It is not a failover trigger. It is a continuous evaluation of configuration parity between your replicas — capacity, quotas, routing policies, and other configuration details — to answer one question: if you had to fail over right now, is the standby actually configured to take the load? AWS is explicit that readiness checks should not be used to indicate whether your production replica is healthy, nor should you rely on them as a primary trigger for failover during a disaster event.

That distinction matters. Readiness drift — the standby fleet sized for last quarter's traffic, an Auto Scaling quota that was raised in the primary and never mirrored, a routing policy that exists only in the primary's account — is one of the quietest causes of failed failovers, and it is exactly what readiness checks are designed to surface before you need to act on them. One important practical note: as of 30 April 2026, the readiness-check feature is no longer open to new customers, although existing customers can continue to use it. For new designs that need configuration-parity validation, AWS recommends onboarding to ARC Region switch, which includes a plan evaluation capability that regularly monitors the state of your recovery plan to ensure readiness for execution. Absent that, build the same discipline into your own deployment pipelines, infrastructure-as-code reviews, and pre-deploy tests.

Most resilience events are not Regional. They are zonal — a single Availability Zone in a single Region having a bad time. ARC's Multi-AZ side of the house is built for that case. Zonal shift is a manual primitive: you tell ARC, for a supported resource, to temporarily move traffic away from a specified Availability Zone. Supported resources today include Application Load Balancers and Network Load Balancers — with cross-zone load balancing either enabled or disabled — Amazon EC2 Auto Scaling groups, and Amazon EKS clusters. The shift is bounded by an expiration you set, up to three days, and it is extendable and reversible.

Zonal autoshift takes the same primitive and inverts the trigger. You opt in, and AWS will start a shift on your behalf when its internal telemetry — drawn from the AWS network, Amazon EC2, and Elastic Load Balancing among other sources — indicates that an Availability Zone impairment could affect customers. The mental model to keep in mind is that ARC does not inspect the health of individual resources; it acts on signal about the Availability Zone, so in some cases traffic might be shifted away for resources that were not themselves impacted. That is a deliberate trade — false positives are cheaper than missed detections at the AZ level, particularly when the alternative is waiting for an application-level signal that may never have arrived in time.

An important prerequisite that the documentation emphasizes: before you enable zonal autoshift, you should pre-scale your application resource capacity across all Availability Zones in the Region. Zonal autoshift works independently and does not wait for auto scaling actions to complete. Relying on scaling on demand rather than pre-scaling can result in longer recovery times when a shift occurs.

Practice runs are the part that turns autoshift from a theoretical capability into a tested one. They are required when you enable autoshift, they take place weekly, and they shift traffic away from a single resource for around thirty minutes before returning it. The point is to give you a continuous, low-stakes signal that your application can actually tolerate losing one AZ's worth of capacity. AWS also provides an on-demand practice-run option for the cases where you want to validate ahead of a known event such as a deploy, a peak window, or a planned dependency change.

ARC works because it is small, opinionated, and engineered to keep working when other things do not. Treat it that way. Drive routing-control changes from the data-plane API across all five cluster endpoints, never from the console during an event. Encode your invariants as assertion and gating rules so an exhausted operator cannot turn off the last cell at four in the morning. Treat readiness checks, where you have access to them, as a parity monitor that surfaces drift, not as a health monitor or a failover trigger — and where you do not have access, use Region switch plan evaluation or build that parity discipline into your pipelines instead. Enable zonal autoshift on the resources that support it, pre-scale your capacity so shifts can complete without waiting for auto scaling, accept that practice runs will occasionally make the on-call's afternoon mildly interesting, and treat that as the system telling you the truth about your own resilience.

ARC steers traffic, but the layer that delivers that steering to clients is DNS. In the next article we go down one level into the steering layer itself — anycast routing for DNS high availability, the four Amazon Route 53 routing policy types and where each one earns its keep, and the EDNS0 client-subnet behavior that quietly determines whether your latency-based answers are actually serving the client you think they are.