SAP-C03 Disaster Recovery Architectures: Elastic Disaster Recovery, ARC, Resilience Hub and Multi-Region Failover

Choose the cheapest disaster recovery strategy that meets both targets: the recovery point objective (RPO), the most data the business can lose, and the recovery time objective (RTO), the longest it can be down. The RPO decides how data must reach the recovery site (periodic copies or continuous replication). The RTO decides how much compute must already be running there. AWS describes four strategies, ordered by cost and speed.

The RPO bands in AWS's DR whitepaper are typical values, not properties of the strategy name: the RPO comes from the replication you choose. A pilot light whose database replicates continuously has the same RPO as a warm standby; the two differ in RTO and cost.

Work each requirement separately. An RPO of a day is met by daily backup copies; an RPO of a minute rules out any scheduled backup or log shipping interval longer than that and requires continuous replication (an Aurora global database, a cross-Region read replica, DynamoDB global tables, S3 Cross-Region Replication, or block-level replication with AWS Elastic Disaster Recovery). For the RTO, add up what has to happen after the decision to fail over: launching instances, booting, loading caches and warming up. If the time from launch to a useful instance is longer than the RTO, nothing that starts compute at failover can meet it, however much capacity is reserved: some capacity must already be running, which is a warm standby sized to the minimum service level. If the RTO leaves time to launch and warm compute, pilot light is cheaper.

A design can mix strategies per tier. A stateless tier with a generous RTO can be rebuilt from AMIs and infrastructure as code at recovery, while the stateful tier beside it replicates continuously because its RPO is tight. Read the constraints as well as the targets: a rule that forbids standing compute in the recovery Region (licensing is a common reason) excludes a running replica and points to block-level replication that launches servers only on recovery.

Capacity is not guaranteed. Pilot light and warm standby both scale out during the disaster, when many customers may be asking for the same instance types in the same Region. For critical workloads, On-Demand Capacity Reservations in the recovery Region hold the capacity (billed whether used or not). Savings Plans only discount usage and service quotas only permit it; neither reserves anything.

AWS Elastic Disaster Recovery (DRS) protects physical servers, virtual machines and EC2 instances by replicating their disks continuously into AWS, giving an RPO of seconds and an RTO of minutes without running full-size servers until a drill or recovery. It is the service for standing disaster recovery of servers; AWS Transform MGN (formerly AWS Application Migration Service) uses similar replication but is built for a one-time migration cutover, without DR features such as point-in-time recovery, recovery plans and failback.

How it works:

• The AWS Replication Agent is installed on each source server. It talks to the DRS service endpoint on TCP 443 and sends block-level data to replication servers on TCP 1500.
• Replication servers are lightweight EC2 instances in a staging area subnet in the recovery Region, writing to low-cost EBS volumes. Several source servers share a replication server by default. This staging area is the only standing cost besides storage and snapshots.
• The replication servers themselves must reach the DRS endpoint, the Regional Amazon EC2 endpoint and Amazon S3. In a staging VPC with no internet path, that means VPC endpoints for those three services.
• Private IP data routing in the replication settings sends data over AWS Direct Connect or Site-to-Site VPN instead of the internet. Firewalls between the source and the staging subnet must then allow TCP 1500 to the staging subnet's CIDR.
• At a drill or recovery, DRS launches recovery instances from the replicated data and converts each server to boot natively on EC2.

Troubleshooting follows the two paths. A server that appears in the console but stalls in initial sync has a working control path (443) and a broken data path: check TCP 1500 to the staging subnet and the replication servers' access to the DRS, EC2 and S3 endpoints.

Replication settings versus launch settings

The default replication settings are a template applied to source servers added after they change. Editing them does not update servers already protected; existing servers must be updated individually (or in bulk through the API). The staging subnet only hosts replication servers and has nothing to do with where recovered instances launch.

Elastic Disaster Recovery recovers to a moment before corruption by keeping point-in-time (PIT) snapshots of each source server, because continuous replication faithfully copies bad writes: after ransomware encrypts files, the latest replicated state is encrypted too.

The PIT policy has three rules. The minute rule (a snapshot every 10 minutes kept for an hour) and the hour rule (hourly snapshots kept for 24 hours) are fixed. The day rule takes a daily snapshot whose retention is configurable from 1 to 365 days (7 by default). A daily recovery window of, say, 90 days is met by setting the day rule to 90 on every source server that needs it; the minute and hour rules cannot be extended, and changing only the default settings leaves existing servers on their old policy. Snapshots that were never taken cannot be created later, so retention must be set before it is needed.

At recovery you choose a snapshot per server. When the time of infection is known, pick the latest snapshot before it. When it is unknown and differs per server, launch drill instances from candidate snapshots into an isolated subnet, verify which is the last clean one, and then launch the real recovery from that snapshot. Drills do not interrupt replication or touch the source servers, so testing candidates is safe; decrypting or scanning the latest state is not a recovery strategy. Protecting the backups themselves from deletion (AWS Backup Vault Lock, logically air-gapped vaults) belongs to the business continuity topic.

Drills, recovery plans and failback in Elastic Disaster Recovery

Elastic Disaster Recovery covers the whole cycle: drill, recover, then fail back.

• Drills launch drill instances without affecting the source servers or ongoing replication, so they can run as often as policy requires.
• Recovery plans recover a multi-tier application with one action. A plan has ordered steps; servers within a step recover in parallel, the next step starts when the previous one reaches a terminal state, and wait times can be inserted between steps (for example, recover the data tier first, give it time to accept connections, then recover the tiers that depend on it). The same plan runs as a drill or as a recovery. A plan works within one account and Region; orchestration across accounts and Regions is the job of ARC Region switch.
• Failback returns workloads to the original site without losing the changes made while they ran in AWS. For on-premises sources, boot the target machine with the Failback Client (or use DRS failback automation for vCenter); the recovery instance replicates to it, and once in sync you perform the failback with a short cutover. For sources that were EC2 instances in another Region or AZ, start reversed replication on the recovery instance and launch for failback in the original Region when it is in sync.

One-time copies (VM Import/Export, AMI copies, DataSync) cannot track ongoing writes and need a long freeze; the replication agent only protects servers into AWS. Custom Step Functions or Lambda orchestration of the DRS API works, but it is code to maintain where a built-in recovery plan exists.

AWS Resilience Hub checks a deployed application against its RTO and RPO targets, estimates what the application can actually achieve, and recommends fixes. It is the assessment tool in Task 4.2; AWS Trusted Advisor flags individual fault-tolerance issues and the Well-Architected Tool records a review, but neither compares an application with recovery targets.

1. Describe the application from input sources: AWS CloudFormation stacks, Terraform state files stored in Amazon S3, AWS Resource Groups, myApplications (AppRegistry) applications and Amazon EKS clusters. Several sources can make up one application, so an application built with mixed tooling is assessed as it is deployed, with nothing rewritten or redeployed.
2. Attach a resiliency policy holding an RTO and RPO for each disruption type: Application, Cloud Infrastructure, Availability Zone and Region.
3. Run an assessment. Resilience Hub estimates the workload RTO and RPO per disruption type and per component and reports Policy met or Policy breached, with resiliency recommendations (configuration changes per component) and operational recommendations (alarms, SOPs and AWS FIS experiments).

Reading a breach means finding the component whose design cannot meet the target for that disruption type. Multi-AZ protects against an AZ disruption but not a Region disruption. Point-in-time recovery, versioning and AWS Backup continuous backups stay inside the source Region; their cross-Region copies are periodic snapshots, so they meet only a loose RPO. A Region RPO measured in minutes needs continuous cross-Region replication, and the usual fix is the store's own feature added to the existing resource (see the data replication section below) rather than a migration to a different database. Stateless compute deployed from code usually meets a Region RTO measured in hours by redeploying.

Testing and validating DR: FIS experiments, SOPs and the pipeline

An assessment's estimated RTO is a calculation; validation proves it by causing the failure and timing the recovery. Resilience Hub supports this in three ways:

• Recommended AWS FIS experiments per disruption type inject the failure (for example, an Availability Zone impairment), check that the recommended alarms fire, and let the team time the standard operating procedure (SOP) that restores service. The measured time is the evidence auditors and executives ask for.
• Assessments in CI/CD: running an assessment as a pipeline stage stops a release that would leave the application breaching its resiliency policy before it reaches production.
• Drift detection reports when the application's resources or policy compliance change after an assessment.

The rule for evidence: a DR test proves recovery only when a real failure is injected, detection is observed and the restore is timed. Anything that estimates, records configuration or moves traffic without causing a fault is useful but proves none of the three, and changing the targets changes the goal, not the evidence. For orchestrated Regional failovers, ARC Region switch adds its own validation (plan evaluation and measured recovery time, below).

Systems Manager Automation runbooks turn a recovery procedure from a wiki page into versioned code: steps call AWS APIs, run scripts, branch and wait, and can require human sign-off. Run Command documents, by contrast, run commands on managed nodes and are not the tool for orchestrating API-level recovery.

Multi-account and multi-Region execution. From the Organizations management account or a delegated administrator account, one Automation execution can run a runbook in many accounts and Regions (target locations). Two levels of rate control exist, and the exam distinguishes them:

Step-level maxAttempts and onFailure affect only a single execution's step, not the fan-out.

Approvals. The aws:approve action pauses until named approvers respond, and MinRequiredApprovals sets how many of them must approve before the run continues. It is not supported inside multi-account and multi-Region executions, so put it in a parent runbook in the administrator account: aws:approve first, then aws:executeAutomation with TargetLocations to fan the recovery runbook out. aws:pause waits for anyone to resume and enforces no approvers. Step Functions or Lambda can do similar work but need approvals and cross-account execution built and deployed in every account.

Route 53 failover routing answers DNS queries with a primary record while it is healthy and with a secondary record when it is not, switching back automatically when the primary recovers. Alias records to AWS resources such as ALBs can use Evaluate target health instead of a separate health check. Weighted records at 100/0 need manual edits; latency and geolocation routing spread traffic rather than keeping one Region primary (latency records with health checks are the active-active pattern).

Three kinds of health check matter for DR:

• Endpoint checks probe a public IP or domain over HTTP, HTTPS or TCP. Checkers run on the internet and cannot reach private IP addresses, so an internal ALB behind a private hosted zone never reports healthy this way.
• CloudWatch alarm checks follow an alarm's data stream. They monitor what endpoint checks cannot: private resources (an ALB's healthy host count) and dependencies such as the database behind a shallow /health page.
• Calculated checks combine child checks with a threshold, for example "healthy only if the endpoint check and the database alarm check are both healthy", so either failure fails the primary without code changes.

Fail-open behaviour and chains. When every record in a failover set is unhealthy, Route 53 answers as if all were healthy and returns the primary. To serve a maintenance page when both Regions are down, alias the secondary to a nested failover pair (the second Region as primary, an S3 website endpoint as its secondary). Each record name uses one routing policy, so combining behaviours (failover, then a fallback) is done by aliasing between records, not by mixing policies on one name.

Data plane versus control plane. Health checks and DNS answers run on Route 53's globally distributed data plane, which is designed for very high availability. Creating or editing records uses the control plane, which is hosted in one Region. Recovery that depends on editing records during an incident adds a dependency the design should avoid; flipping health check state does not.

ARC routing controls give operators manual, data-plane failover: each routing control is an on/off switch whose state drives a routing control health check attached to Route 53 failover records. Turning a Region's control off makes its record unhealthy and moves traffic, with no record edits and no automatic flip on a brief blip.

• Controls live in a cluster, a set of five redundant Regional endpoints. A state change succeeds while any endpoint is reachable, so scripts and runbooks must try each endpoint in turn rather than pinning one. Calling the ARC control plane or editing Route 53 records reintroduces the dependency the cluster exists to avoid.
• Safety rules prevent dangerous states:

IAM can restrict who changes controls, but denying operators conflicts with letting several teams act; a gating rule keeps them able to act once the switch is on. Readiness checks audit whether replicas match their primary in capacity, quotas and configuration, but the feature is closed to new customers (existing users can keep using it), and it was never meant for the critical path of a failover. For a new design, continuous validation of a recovery plan comes from Region switch plan evaluation (below). ARC also offers zonal shift and zonal autoshift for moving traffic away from an impaired Availability Zone, which is covered with in-Region resilience.

ARC Region switch plans for orchestrated multi-Region recovery

ARC Region switch orchestrates a whole Regional failover or switchover as a plan of ordered steps made of execution blocks, so the recovery runs as one action without custom code. Execution blocks include Aurora Global Database switchover/failover, EC2 Auto Scaling group scaling, EKS resource scaling, ECS service scaling, ARC routing control state changes, Route 53 health check changes, manual approval, custom action Lambda, Systems Manager Run Command, and Region switch plan execution (running a child plan).

• Regional independence: Region switch has a data plane in each Region, so a plan executes from the Region being activated and does not depend on the one being left.
• Graceful vs ungraceful: a graceful execution is for planned moves and drills; an ungraceful execution is for a real outage when the old Region cannot be reached. Each block can be configured for both. For Aurora, graceful means switchover (waits for replication to catch up, no data loss, needs a healthy primary) and ungraceful means failover (promotes the secondary without the primary, may lose the last seconds of writes). Post-recovery workflows prepare the old Region to become the standby again.
• Multi-account: plans act in other accounts through cross-account IAM roles (with an external ID).
• Team ownership: each team can own its plan, and a parent plan runs the children in the required order with plan execution blocks. Nesting is limited to a parent and its children, not deep chains.
• Continuous validation: plan evaluation runs when a plan is created or updated and every 30 minutes, checking that resources, permissions and quotas still let the plan run; warnings are published to Amazon EventBridge, so owners hear about a broken plan without running a drill.
• Evidence: each execution reports the actual recovery time (from Regional CloudWatch alarms) and can deliver a PDF execution report to Amazon S3, suitable for regulators.

Scaling blocks ask for capacity but do not guarantee it. Pair critical scale-out steps with On-Demand Capacity Reservations in the recovery Region.

AWS Global Accelerator fails traffic over between Regions without relying on DNS: clients connect to two static anycast IP addresses, and the accelerator sends each new connection to a healthy endpoint group (one per Region, holding NLBs, ALBs, EC2 instances or Elastic IPs). Failover typically takes under a minute and works for TCP and UDP, which matters when clients cache DNS answers and ignore TTLs (game consoles, devices) or when partners allow-list fixed IP addresses. Route 53 failover depends on clients re-resolving; CloudFront does not carry UDP.

A traffic dial on each endpoint group sets the percentage of traffic it receives. Setting a Region's dial to 0% sends all new connections to the other groups for a drill or maintenance window, while connections already open are not terminated and health checks keep running; setting it back to 100% restores normal routing. Deregistering targets, by contrast, drops open sessions, and repointing DNS changes the addresses clients reach.

The data layer sets a multi-Region design's RPO, so choose replication by its lag and its failover behaviour.

• Aurora global database: storage-level replication to secondary Regions, typically under a second. Use switchover for planned moves (no data loss) and failover for outages (possible loss of the latest writes). A headless secondary (no instances) lowers cost for pilot light.
• RDS cross-Region read replica: asynchronous replication, promoted during a Region disruption; the low-cost way to give an existing RDS instance a Region RPO in seconds to minutes. Multi-AZ deployments, including Multi-AZ DB clusters, stay inside one Region.
• DynamoDB global tables: add a replica Region to an existing table to replicate it continuously, with every replica writable.
• S3 Cross-Region Replication (CRR) copies new objects asynchronously; S3 Replication Time Control (RTC) adds an SLA of 99.99% of objects within 15 minutes plus replication metrics, and S3 event notifications flag objects that miss the threshold. Standard CRR has no SLA. Batch Replication copies existing objects on demand and is not continuous. For failback, configure two-way replication with replica modification sync so objects written in the recovery Region return.
• S3 Multi-Region Access Points give one endpoint over buckets in several Regions. Default routing sends requests to the nearest bucket; with an active-passive routing configuration, operators fail over by changing routing status (through the console or the API in any of five Regions), and traffic moves in about 2 minutes without application changes. Route 53 records cannot fail over S3 API calls between buckets.
• Secrets and keys: replicate Secrets Manager secrets as replica secrets in the recovery Region. A multi-Region KMS key does not replicate the secret itself.

Container DR uses one cluster per Region, because both EKS clusters and ECS clusters are Regional. A cluster cannot span Regions with node groups or capacity providers, so the recovery Region needs its own cluster deployed from the same definitions, plus every dependency available locally.

Amazon EKS.

• GitOps (a controller such as Argo CD or Flux in each cluster syncing one Git repository) keeps clusters identical without applying changes twice. Pair active-active clusters with health-aware routing (Route 53 latency records with health checks, or Global Accelerator).
• AWS Backup backs up EKS cluster state and persistent volumes and can copy them to another Region, but the backups do not include container images.
• ECR replication copies only images pushed after the rule exists, so older images must be replicated separately (ECR replication backfill or a re-push), and manifests in the recovery cluster must reference the recovery Region's registry.
• Workload identity: an IRSA role trusts one cluster's OIDC provider, which is unique per cluster, so a standby cluster's pods get AccessDenied. EKS Pod Identity avoids that coupling: roles trust the pods.eks.amazonaws.com service principal, the Pod Identity Agent add-on runs in each cluster, and each cluster gets pod identity associations for its service accounts.

Amazon ECS. Deploy the same task definition and service in the recovery Region. A service at desired count 0 on Fargate is a pilot light that costs nothing for compute until scaled with a single change; a reduced count is a warm standby. Every reference in the recovery task definition must be local: an ECR image URI in the recovery Region (via a replication rule) and secrets from a Secrets Manager replica secret ARN. The general rule: any reference that resolves in the primary Region, however it is permitted, fails with that Region, so the standby must hold its own copy of every image and secret it needs.