What is AWS ARC?
Amazon Application Recovery Controller (ARC) is a family of AWS services for managing application recovery at different scopes. It includes four capabilities:
- Zonal shift and zonal autoshift: move traffic away from an impaired Availability Zone within a single Region.
- Routing control: on/off switches tied to Route 53 DNS that redirect traffic between Regional replicas when you flip them.
- Readiness check: continuous checks that a Regional replica is configured and provisioned to match its primary. (Note: as of 30 April 2026, AWS closed readiness check to new customers; existing customers continue to use it as normal.)
- Region switch: a declarative plan that coordinates a multi-service, multi-Region failover end-to-end.
Each of these targets a different problem at the AWS layer. All four have public APIs, which a Cutover runbook calls directly through its integrations framework. The AWS-layer action then sits inside a runbook that also covers the people, the non-AWS dependencies, the business validation, and the audit trail around it.
Benefits of Cutover and AWS ARC for AWS customers
Cutover Recover integrates with Region switch through its public APIs. An ARC plan stops being a separate system the recovery team has to watch, and becomes a live component inside a Cutover runbook.
ARC plans triggered at the right moment in the wider event.
A plan should only execute once the upstream preconditions are met: the application has stopped taking transactions, the on-prem database replica has caught up, the mainframe batch has finished, the change is approved in ServiceNow. AWS can't poll for any of that. Cutover holds each one as a runbook task and fires the ARC plan only when they're all done. The plan runs when it should, not when someone remembers to click the button.
AWS ARC’s manual approvals, with the business context attached.
When a Region switch plan pauses on a manual approval block, the approver signs off inside a Cutover task that shows them why it matters:
- Which LOBs are impacted
- what upstream validation has already run
- what the RTO clock looks like,
- who else is on the call.
The AWS-side gate is the same. The decision behind it isn’t guesswork.
ARC drives the AWS-side failover. The runbook covers everything around it. From the recovery team’s point of view, there’s one place to look.
What that buys you at scale is the layer above ARC itself: cross-plan sequencing, exec decisions, the non-AWS activity running alongside, and one audit artifact covering all of it.
Why not just use ARC with Lambda and Step Functions?
It's a fair question. ARC handles the AWS-side failover, Step Functions sequences it, and Lambda bridges to non-AWS systems through callback patterns. That stack works well for a recovery that lives inside AWS and is built and operated by engineers.
Cutover covers the ground ARC with Lambda and Step Functions can't reach. The recovery needs to coordinate things AWS doesn't see in code: a payments partner confirming standby, a regulator notification going out, an exec deciding whether to commit to the next recovery phase, a recovery commander coordinating people across multiple AWS accounts during a batch DR test when the original SMEs aren't on the call. Every one of those steps in the AWS stack means another Lambda broker, another API Gateway endpoint, another piece of state machine definition to wire it in. You can build it, but you're building a runbook platform using AWS primitives.
The other gap is who actually runs the recovery. Engineers built the Lambda and Step Functions setup, but during a real event it's recovery commanders, business approvers, and execs operating it. A recovery commander or business approver doesn't work in CloudWatch and Step Functions consoles, even if engineers can. And when the regulator asks for the recovery report, a CloudWatch trace isn't what they want to read. Cutover holds those steps natively, in the same surface the recovery team is already using, and produces one artifact covering every plan, every gate, every decision, and every non-AWS step.
How Cutover integrates with ARC Region switch
The integration starts with a single ARC Region switch plan inside a Cutover runbook. That’s the unit. From there, the runbook talks to the plan through six ARC API calls, mapped one-to-one to the runbook steps that need them.
Cutover customers already run AWS STS SigV4 integrations against DRS, FIS, Lambda, EC2, ECS, and ASG. ARC Region switch drops in using the same auth pattern with arc-region-switch as the service code. Six API calls cover the full runbook integration: a readiness check at the top, the plan execution itself, live progress, and a manual-approval surface for ARC’s pause points.
Cutover runbook integration to AWS ARC: 6 API calls
All six calls are data plane operations against the target Region, designed to stay available during a Regional impairment. ARC also exposes control plane equivalents like GetPlan that run in us-east-1, but for live recovery work the integration deliberately uses the data-plane-only path. Cutover’s integration inherits ARC’s data-plane resilience design rather than cutting across it.
That covers the single-plan unit. The more interesting question is: what happens when you have twenty of them, in three recovery phases, with exec gates between?
The pattern: portfolio orchestration
A real regional event is rarely one application. It’s a planned disaster recovery exercise or an unplanned failover involving dozens or hundreds of applications, each with its own ARC plan, each with its own dependencies, all needing to recover in a specific sequence. This is the shape most regulated enterprises will end up in, and where ARC alone runs out of road.
ARC does have an answer at this layer: the nested ARC Region switch plan execution block lets a parent plan invoke child plans, so you can express “activate these three applications in order.” That’s a useful primitive when the orchestration is purely AWS-side and fits within ARC’s two-level hierarchy (one parent, up to 25 children).
But nested plans only sequence AWS-side actions. They don’t model the layer above that, which is where most enterprise disaster recovery events actually live.
Example: Regional failover event
- Phase 1 recovers shared infrastructure (identity, networking, observability) with multiple ARC plans fanning out in parallel and a Cutover exec-decision gate to close the initial phase.
- Phase 2 brings up customer-facing critical apps in priority order, gated by business validation.
- Phase 3 handles back-office systems and the portfolio close-out and audit pack.
Where ARC stops and Cutover takes over
A nested ARC plan structure can’t express any of the recovery details noted above. After shared infra is up, someone has to confirm it’s actually working before Phase 2 kicks off. That’s a human decision with business context, not an AWS-side condition.
The wider event also brings in things ARC simply doesn't model:
- SaaS cutovers
- mainframe batch drain
- third-party acknowledgements
- regulator notifications.
And when the event is over, the regulator wants one artifact covering every plan, every gate, every decision, and every non-AWS step. ARC’s plan execution reports (added in December 2025) close the per-plan side of this: each plan now exports a timeline, RTO calculations, and alarm states to S3. What they can’t produce is the event-level orchestration: cross-plan sequencing, the exec decisions between recovery phases, the SaaS and mainframe activity running alongside, and a single artifact covering all of it. That’s the event-level record, and it’s what Cutover produces.
Each ARC plan inside a recovery phase still uses the same six-API integration shown above.
Why Cutover for regional failover events
What Cutover adds at this scale is the layer above ARC: sequencing across plans, holding exec decisions between recovery phases, coordinating the non-AWS activity that happens alongside, and producing one portfolio-level audit artifact covering every plan and every surrounding activity.
Getting started with Cutover
If you’re evaluating Region switch, start with the ARC plan and extend it with a Cutover runbook. The six integration tasks above are all buildable today through Cutover Custom Integrations, and run today in a working reference integration against a live ARC plan. The API surface is well-documented, the auth pattern is standard AWS Signature Version 4, and Cutover’s runbook model handles polling and event capture natively.
If you’re building your first Region switch plan, wrap it in a Cutover runbook from the start. You won’t get more out of ARC by waiting.
Hands-on lab: Cutover runbook and AWS ARC Routing Control
Contact Cutover to walk through the integration pattern, or join the AWS Workshop Studio lab, Increase Resilience with Cutover Automated Runbooks, to see the runbook layer in action.