Every SAP-C02 candidate can recite the four disaster recovery strategies. Backup and restore, pilot light, warm standby, multi-site active-active, ordered by cost and by how fast they recover. That knowledge is table stakes, and it is covered thoroughly in the sibling guide on disaster recovery and high availability for SAP-C02. What the strategies do not tell you is which AWS service you would actually use to make a pilot light pilot, or how you would move traffic away from a broken Availability Zone in ninety seconds without touching a DNS record.
Two services fill that gap, and both tend to be under-studied because they are young, were renamed, or are easy to mistake for things you already know. AWS Elastic Disaster Recovery (AWS DRS) is the managed service that continuously replicates servers, from on-premises, other clouds or other AWS Regions, into a cheap staging area in AWS and launches full recovery instances in minutes. Amazon Application Recovery Controller (ARC), formerly Amazon Route 53 Application Recovery Controller, is the service that moves traffic: away from an impaired Availability Zone with zonal shift, or between Regions with routing controls and Region switch. This guide covers both at the depth the SAP-C02 “Design for New Solutions” and “Continuous Improvement for Existing Solutions” domains expect, with the decision cues that separate them from AWS Backup, Route 53 health checks, AWS Application Migration Service and AWS Resilience Hub.
Part 1: AWS Elastic Disaster Recovery (AWS DRS)
What AWS DRS Is and Where It Came From
AWS Elastic Disaster Recovery is the successor to CloudEndure Disaster Recovery, rebuilt as a native AWS service with its own console, API and IAM integration. Its promise is simple: recovery point objectives of seconds and recovery time objectives of minutes for applications running on physical servers, VMware vSphere, Microsoft Hyper-V, other clouds, or EC2 instances in another Availability Zone or Region, at the running cost of a low-end staging environment rather than a duplicate data centre.
That cost model is why the exam cares about it. A traditional warm standby means paying for a second, scaled-down copy of the whole application. DRS instead keeps only the data continuously replicated onto inexpensive storage, and materialises the compute only when you drill or actually fail over. In strategy terms it is the managed way to run pilot light, and with pre-provisioned launch settings it edges into warm standby territory without paying warm-standby prices.
How Replication Works
The moving parts you need to recognise in a scenario:
| Component | What it does | Exam-relevant detail |
|---|---|---|
| AWS Replication Agent | Installed on each source server; captures disk block writes continuously and sends them, compressed and encrypted in transit, to AWS | No reboot required; low CPU impact; installation starts billing, so agent-install permissions should be tightly scoped via an IAM role |
| Staging area subnet | A subnet in your recovery Region that hosts the replication infrastructure | Lives in your account; chosen in the replication settings |
| Replication servers | Lightweight EC2 instances (default t3.small) that receive replicated blocks and write them to staging disks | One replication server can serve disks from multiple source servers (up to 15 staging disks); a dedicated server can be configured for high-write-rate sources |
| Staging disks | One EBS volume per source disk, sized to match | Low-cost volume types by default, with gp3 selectable for high-change-rate disks |
| Point-in-time (PIT) snapshots | EBS snapshots that preserve recoverable states | A base snapshot per disk plus incrementals; default retention is 7 days; lets you recover to a state before a ransomware event or bad change |
| Launch settings / launch template | Defines the recovery instance: instance type (with right-sizing), subnet, security groups, private IP handling, licensing | Edited per source server; the recovery instance is a new EC2 instance created from staging data |
| Post-launch actions | AWS Systems Manager documents run automatically on recovered instances | Validation, agent installation, configuration changes after launch |
Network-wise, agents and the staging subnet talk to the DRS service endpoints and the DRS software buckets in S3 over TCP 443, and agents stream replicated data to replication servers over TCP 1500. You can route that traffic over the public internet or over private connectivity (AWS Direct Connect or Site-to-Site VPN) by selecting the private-IP option in the replication settings, and bandwidth throttling can protect a constrained WAN link. When a question lists “the source servers must not use public internet for replication”, the answer is the private-IP replication setting over Direct Connect or VPN, not a redesign.
Drills, Recovery and Failback
The DRS lifecycle has three operations, and the exam expects you to know what each one touches:
- Drill. You launch drill instances from the staging data into an isolated recovery subnet, validate the application, and terminate them. Drills do not stop or affect replication, so the RPO is unaffected and the source environment is untouched. Drill instances are ordinary EC2 instances billed at EC2 rates while they run, and AWS’s guidance is to drill several times a year at minimum. This is the operational expression of the SAP-C02 principle that an untested DR plan is not a plan.
- Recovery (failover). During a real disruption you launch recovery instances from the most recent state or from a chosen point in time. DRS converts the servers to boot natively on EC2 as part of the launch, applying your launch settings and post-launch actions. Recovery instances come up within minutes because the data is already in the Region; what you are waiting for is EC2 launch and boot, not data transfer. Interdependent servers can be recovered as a group in a defined order with wait times between tiers.
- Failback. After the primary site is repaired, DRS replicates the changes made while running in AWS back to the source environment. For on-premises sources this uses the Failback Client (a bootable ISO) or the DRS failback automation for vCenter. For EC2 sources recovered to another AZ or Region, you start reverse replication on the recovery instance and the direction simply flips. You can also choose never to fail back, keeping the recovered application in AWS, which turns the DR exercise into a migration.
That last point is the DRS-versus-MGN decision the exam likes. AWS Application Migration Service (MGN) uses the same agent and the same replication mechanics, but is purpose-built for a one-way cutover: replicate, test, cut over, decommission. AWS DRS is built for an indefinite steady state of replication with repeated drills, point-in-time recovery and failback. If a scenario says “migrate”, pick MGN; if it says “protect”, “RPO”, “RTO”, “drill” or “fail back”, pick DRS. Both are covered as a pair in the SAP-C02 migration strategies guide.
In-AWS Disaster Recovery
DRS is not only for on-premises sources. It can protect EC2 instances across Availability Zones or across Regions, which makes it the lowest-effort way to give a single-Region, EC2-heavy application a cross-Region recovery option without re-architecting it onto Aurora Global Database or DynamoDB global tables. The replication agent runs on the source instance, the staging area lives in the target Region, and recovery launches there. For applications whose data layer is already multi-Region but whose compute tier is a fleet of stateful EC2 instances, in-AWS DRS is often the missing piece. Cross-account topologies, with a separate staging account and target account, are supported for organisations that isolate DR resources, and pair naturally with the account structures in the SAP-C02 multi-account architecture guide.
Pricing Shape
You do not need exact prices for the exam, but you do need the shape, because cost is usually a deciding factor between options:
| Cost component | How it is charged |
|---|---|
| AWS DRS fee | A flat hourly rate per replicating source server (currently in the region of three US cents per server-hour), regardless of disk count, storage size, number of drills, or target Region |
| Staging EBS volumes | One volume per source disk, mostly low-cost types |
| EBS snapshots | Base plus incrementals; grows with retention period and change rate |
| Replication servers | Small EC2 instances, shared across source servers |
| Drill and recovery instances | Full EC2 and EBS prices, only while launched |
The exam framing: DRS’s steady-state cost is dominated by storage, not compute, which is exactly why it beats a traditional warm standby on price while delivering better RPO than backup-and-restore. When a question says “minimise ongoing cost while achieving an RPO of seconds and an RTO of minutes for a VMware estate”, that combination is the DRS signature.
DRS vs AWS Backup
These are complementary, not competing, and the exam tests the boundary. AWS Backup is a policy-driven service for backups: scheduled snapshots and backups of AWS resources (EBS, RDS, DynamoDB, EFS, S3, VMware and more) with retention, cross-Region and cross-account copy, and vault lock for immutability. Its RPO is the backup frequency, typically hours, and its RTO includes restoring data before anything can start. AWS DRS is continuous replication with RPO in seconds and compute ready to launch in minutes. A regulated organisation usually needs both: DRS for the servers that must come back fast, AWS Backup for long-term retention, compliance and immutable copies, covered in depth in the guide to centralised backup governance with AWS Backup and vault lock.
Part 2: Amazon Application Recovery Controller (ARC)
A Rename You Need to Know
The service launched in 2021 as Amazon Route 53 Application Recovery Controller. AWS has since renamed it Amazon Application Recovery Controller (ARC) to reflect that much of what it does, especially zonal shift, has nothing to do with DNS. Exam questions and older study notes may use either name; treat them as the same service. ARC groups its capabilities into two families:
- Multi-AZ recovery: zonal shift and zonal autoshift.
- Multi-Region recovery: routing control (with safety rules), Region switch, and readiness check.
Zonal Shift: Evacuating an Availability Zone Without Touching DNS
The problem zonal shift solves is one every multi-AZ architect has felt: an Availability Zone is degraded rather than down. Health checks still pass intermittently, the load balancer keeps sending a share of traffic there, and a fraction of your users see errors for an hour while you argue about whether to intervene. Zonal shift lets you tell AWS, in one API call, to temporarily stop sending traffic for a supported resource to a specific AZ and route it to the healthy AZs in the same Region.
Key facts:
- Supported resources are Application Load Balancers and Network Load Balancers (with cross-zone load balancing either on or off), Amazon EC2 Auto Scaling groups, and Amazon EKS clusters. Resources must be opted in before a shift can be started.
- A zonal shift is manual and temporary: you set an expiry from one minute up to three days (72 hours) and can extend it. When it expires or you cancel it, traffic returns to all AZs.
- It works at the load balancer’s AZ level, so no DNS change and no TTL wait is involved for the application behind the balancer. Recovery is measured in seconds to a minute or two.
- You must pre-scale the application so the remaining AZs can absorb the shifted traffic; zonal shift moves traffic, it does not add capacity.
- If a load balancer is in a fail-open state (all targets unhealthy, so it routes to everything), a zonal shift has no effect.
- There is no additional charge for zonal shift or zonal autoshift.
The exam distractor is Route 53. Shifting traffic away from an AZ by editing weighted records or health checks requires DNS propagation and client TTL expiry, and it operates on endpoints you expose in DNS, not on the AZ dimension of a single load balancer. If a scenario asks for the fastest way to stop a bad deployment confined to one AZ from affecting customers, zonal shift is the answer; if it describes cross-Region failover of a whole endpoint, Route 53 failover routing (covered in the Route 53 routing policies guide) or ARC routing control is in play.
Zonal Autoshift: Letting AWS Do It For You
Zonal autoshift authorises AWS to start a zonal shift on your behalf when AWS’s internal telemetry, which aggregates signals from the network, EC2 and Elastic Load Balancing, indicates an AZ impairment that could affect customers. AWS ends the autoshift when the telemetry clears. The two details worth remembering:
- Practice runs are required. When you enable autoshift for a resource, ARC performs a weekly practice run: it shifts traffic for that single resource away from one AZ for about 30 minutes, then shifts it back, and records an outcome of SUCCEEDED or FAILED. You attach a CloudWatch alarm as the “outcome alarm”, and if it fires during the practice run ARC immediately ends the run and marks it failed. You can also define blocked dates and blocked windows during which practice runs must not happen.
- Autoshift is for AWS-detected impairments. A bad deployment that only you can see still needs a manual zonal shift.
Autoshift and practice runs emit EventBridge events, which is how teams wire notifications and automated verification around them.
Routing Control: A Highly Available Switch for Multi-Region Failover
For Region-level failover, ARC provides routing controls: simple on/off switches whose state is read by a special kind of Route 53 health check. You associate that health check with the DNS failover records for each Regional replica of your application. Flip the routing control for Region A to Off and Region B to On, and Route 53 stops returning Region A’s records and starts returning Region B’s, with no dependency on the health of the Region you are leaving.
What makes this different from ordinary Route 53 health checks is the control plane / data plane separation the exam cares about so much in the Professional domains:
- Routing controls live in a cluster, which is a data plane of redundant endpoints in five AWS Regions. You can read and update routing control state against any of the five endpoints. Even if the Region hosting your application and your usual tooling is impaired, the switch still works.
- Controls are grouped on control panels (a default one per cluster, plus any custom ones). Updating state is recommended through the CLI or API rather than the console, precisely because the console depends on more infrastructure than the data-plane endpoints do.
- Each account can have at most two clusters, and clusters are billed per hour, so the exam will treat routing control as a deliberate investment for critical applications rather than a default.
In the language of the DR strategies: routing controls are how a multi-site active-active or warm standby architecture performs a deliberate, reliable, human- or automation-triggered Regional failover, as opposed to the automatic failover that ordinary health checks provide. Automatic failover sounds better until you have seen a flapping health check bounce production between Regions during a partial event.
Safety Rules: Guardrails Against Fail-Open and Fat Fingers
Because routing controls are deliberately simple switches, ARC lets you wrap them in safety rules that the data plane enforces on every state change:
| Rule type | What it enforces | Canonical use |
|---|---|---|
| Assertion rule | A condition on a set of routing controls must hold after any change, or the change is rejected | ”At least one of the Region routing controls must always be On”, preventing a fail-open scenario where an operator turns Region A off before turning Region B on and sends traffic nowhere |
| Gating rule | A separate gating routing control acts as an overall on/off switch for a set of target controls; while the gate is Off, no manual or automated update to the targets is allowed | A “manual override” switch that freezes automation from flipping Regions during an incident review, or that must be deliberately opened before a failover can be executed |
Safety rules are the exam’s favourite way to test whether you understand why routing control exists. A question that mentions “prevent an operator from accidentally disabling all Regions” is describing an assertion rule; one that mentions “prevent automation from failing over without explicit approval” is describing a gating rule.
Region Switch: Orchestrated Multi-Region Recovery
Routing control flips DNS. It does not promote your Aurora global database, scale up the standby Auto Scaling groups, re-point your EventBridge rules or run your validation checks. Region switch is ARC’s newer capability that orchestrates the whole recovery. You define a plan per application consisting of workflows made of steps, each step running one or more execution blocks in sequence or in parallel. Execution blocks handle specific tasks, such as switching Route 53 health checks, adjusting ARC routing controls, scaling EC2 Auto Scaling, EKS or ECS capacity, promoting Aurora global databases, invoking Lambda functions or running custom steps.
The properties that matter for architecture questions:
- Plans can be executed manually or automatically from CloudWatch alarms, cover active/passive or active/active topologies, support parent and child plans for applications composed of several services, and can be shared across accounts.
- Region switch has a data plane in each Region, so you can execute a plan from the healthy Region without depending on the impaired one.
- Pricing is per plan per month, not per execution, so the design unit is “one plan per application”.
Think of Region switch as the runbook-as-code layer on top of routing controls. It overlaps conceptually with AWS Resilience Hub, which assesses whether your architecture can meet RTO/RPO and recommends tests, and with AWS Fault Injection Service, which breaks things on purpose to prove it. Those two are covered in the DOP-C02 guide to Fault Injection Service and Resilience Hub. Region switch is the thing that actually performs the recovery when the real event arrives.
Readiness Check: Know Its Status
ARC’s readiness check continuously audited whether a standby Regional replica matched production in service quotas, capacity and routing configuration, using recovery groups, cells, resource sets and readiness scopes. It still appears in older exam prep and in the console for existing customers, but readiness check is no longer available to new customers as of 30 April 2026. For the exam, understand what it was for (detecting quota and capacity drift between Regions before a failover exposes it), and expect current-generation answers to lean on Region switch plans, Resilience Hub assessments and quota monitoring instead. If a question explicitly describes the recovery-group-and-cells model, it is describing readiness check.
Decision Table: Which Service Does the Scenario Want?
| Scenario cue | Pick | Not this, because |
|---|---|---|
| ”Replicate on-premises VMware servers to AWS, RPO seconds, RTO minutes, minimise idle cost” | AWS Elastic Disaster Recovery | AWS Backup’s RPO is the backup interval; a warm standby costs far more |
| ”Recover to a state before the ransomware encryption started” | AWS DRS point-in-time snapshots | Current-state replication would recover the encrypted data |
| ”Protect a stateful EC2 fleet in a second Region without re-architecting” | AWS DRS in-AWS cross-Region replication | Aurora Global or DynamoDB global tables only cover the database |
| ”One-way migration of servers to AWS with a cutover window” | AWS Application Migration Service (MGN) | DRS is for continuous protection and failback |
| ”Long-term, immutable, cross-account backup copies for compliance” | AWS Backup with vault lock | DRS is not a retention or compliance tool |
| ”An AZ is degraded; move traffic away in seconds without changing DNS” | ARC zonal shift | Route 53 changes wait on propagation and TTLs |
| ”Let AWS automatically move traffic when it detects an AZ impairment, and prove weekly that the app tolerates it” | ARC zonal autoshift with practice runs | Manual zonal shift needs a human on call |
| ”Reliable manual Regional failover that works even if the primary Region’s control plane is down” | ARC routing control (five-Region cluster) | Ordinary health checks fail over automatically and can flap |
| ”Ensure at least one Region is always receiving traffic during a failover” | ARC assertion safety rule | Nothing else enforces that invariant at the data plane |
| ”Freeze automated failover until an operator approves” | ARC gating safety rule | IAM policies can block callers but not express “gate is closed" |
| "Orchestrate DNS, database promotion and scaling across accounts as one runbook, optionally from an alarm” | ARC Region switch | Routing control alone only flips DNS |
| ”Assess whether the architecture can meet its RTO/RPO and recommend tests” | AWS Resilience Hub | ARC executes; Resilience Hub evaluates |
| ”Inject AZ failures to validate the recovery plan” | AWS Fault Injection Service | ARC is the response, not the experiment |
Where This Fits in Your SAP-C02 Prep
The SAP-C02 “Design for New Solutions” domain asks you to design for reliability and business continuity, and “Continuous Improvement for Existing Solutions” asks you to improve the reliability of what already exists. Both are usually tested as service selection under constraints: the right RPO, the right RTO, the right cost, the right blast radius. DRS and ARC are the two services that let you give precise answers rather than strategy names, and because they are newer and were renamed, they are also where many otherwise-prepared candidates lose points.
The fastest way to make these distinctions reflexive is to practise them against realistic, multi-constraint scenarios. Sailor.sh’s AWS Certified Solutions Architect - Professional (SAP-C02) mock exam bundle is built around exactly this kind of trade-off, with explanations that walk through why DRS beats a warm standby for one scenario and why zonal shift beats a Route 53 change for another. Use this guide to learn the mechanisms; use timed mocks to find out which cues you still misread.
For the surrounding material, start with the strategy-level SAP-C02 disaster recovery and high availability guide, then the Route 53 routing policies guide for the DNS failover mechanics that routing controls plug into, and the guide to AWS Backup and vault lock for the backup side of the boundary. For hybrid replication paths, the SAP-C02 networking deep dive covers Direct Connect and VPN. The SAP-C02 study plan and SAP-C02 practice questions round out the preparation.
Frequently Asked Questions
What is AWS Elastic Disaster Recovery?
AWS Elastic Disaster Recovery (AWS DRS) is a managed service that continuously replicates physical, virtual, other-cloud or EC2 source servers into a low-cost staging area in an AWS Region using a block-level replication agent, and launches full recovery instances within minutes from the latest state or a chosen point in time. It supports non-disruptive drills and failback to the original environment, and is the successor to CloudEndure Disaster Recovery.
How is AWS DRS different from AWS Backup?
AWS Backup takes scheduled, policy-driven backups with retention, cross-Region and cross-account copy and immutable vault lock; its recovery point is the backup interval and recovery requires a restore. AWS DRS replicates continuously for an RPO of seconds and an RTO of minutes, and launches compute from already-present data. Most regulated organisations use both: DRS for fast recovery of critical servers, AWS Backup for retention and compliance.
How is AWS DRS different from AWS Application Migration Service?
They share the same replication agent and staging mechanics, but MGN is designed for a one-way migration cutover while DRS is designed for ongoing protection with repeated drills, point-in-time recovery and failback. Choose MGN for “migrate” scenarios and DRS for “protect” scenarios.
How much does AWS DRS cost?
A flat hourly fee per replicating source server (around three US cents per server-hour at the time of writing), plus the underlying AWS resources: staging EBS volumes, EBS snapshots for point-in-time recovery, small replication-server EC2 instances, and full EC2 and EBS charges only while drill or recovery instances are running.
What is zonal shift in Amazon Application Recovery Controller?
Zonal shift temporarily moves traffic for a supported resource (Application or Network Load Balancer, EC2 Auto Scaling group, or EKS cluster) away from one Availability Zone to the healthy AZs in the same Region, without any DNS change. It is manual, expires after a configurable period of up to three days, and has no additional charge.
What is the difference between zonal shift and zonal autoshift?
Zonal shift is started by you. Zonal autoshift authorises AWS to start a shift on your behalf when AWS’s internal telemetry detects an AZ impairment, and requires weekly 30-minute practice runs with an outcome alarm so you can confirm the application tolerates losing an AZ.
Why does ARC routing control use a cluster in five Regions?
So that the switch you use to fail over is more available than the application it protects. The cluster is a data plane of redundant endpoints in five AWS Regions; you can update routing control state through any of them, even when the Region hosting your application or your usual tooling is impaired.
Is Route 53 Application Recovery Controller the same as Amazon Application Recovery Controller?
Yes. AWS renamed the service to Amazon Application Recovery Controller (ARC); its routing controls still integrate with Route 53 health checks, but zonal shift and Region switch operate independently of DNS.
Conclusion
The four DR strategies tell you what you are buying; AWS Elastic Disaster Recovery and Amazon Application Recovery Controller tell you how. DRS turns pilot light into a managed service: an agent, a cheap staging area, point-in-time snapshots, non-disruptive drills, minutes-to-launch recovery and a path back home, for roughly the price of the storage. ARC turns “move the traffic” into reliable primitives: zonal shift and autoshift for the AZ that is degraded rather than dead, routing controls with assertion and gating safety rules for deliberate Regional failover that survives a broken control plane, and Region switch to orchestrate the whole runbook. Learn the boundaries against AWS Backup, MGN, Route 53 health checks, Resilience Hub and FIS, keep the rename in mind, and the recovery scenarios on the SAP-C02 stop being strategy trivia and become engineering questions you can answer precisely.