Domain 2 of 4 · Chapter 2 of 6

Business continuity and disaster recovery

RTO, RPO, and the four-strategy cost/recovery curve

Continuous replication can hand you a near-zero RPO while your RTO stays at hours, because current data does not turn application servers on or scale a fleet: RTO and RPO are independent, and that is the trap the exam plants again and again. Business continuity is an engineering exercise that starts before any service is chosen, by turning those two recovery objectives into numbers the business signs off on and letting the numbers select the DR architecture.

The objectives drive everything

  • Recovery Time Objective (RTO) is the maximum acceptable downtime between a disruption and restored service. The AWS disaster recovery whitepaper[1] frames RTO as the time to return to a working state.
  • Recovery Point Objective (RPO) is the maximum acceptable data loss, measured as a span of time before the disruption, usually equal to the replication lag or the backup interval at the moment of failure.
  • Recovery Level Objective (RLO) captures which functions must return and in what order; a degraded-but-running tier often satisfies continuity at far lower cost than full restoration.

The trap the exam plants again and again: RTO and RPO are independent. Continuous replication can give a near-zero RPO while RTO stays high, because the data being current does not turn application servers on or scale a fleet. A design that nails one objective and ignores the other is wrong even though it looks complete.

The four strategies, cheapest to costliest

AWS defines four DR strategies[1] on a single cost/recovery curve:

Strategy DR-Region state Failover action Typical RTO Typical RPO Relative cost
Backup & restore Data backups only; infra not deployed Redeploy IaC, restore data Hours Hours (backup interval) Lowest
Pilot light Data live + core infra on; app servers OFF Turn servers on, then scale Tens of minutes Seconds (continuous replication) Low
Warm standby Scaled-down full stack already taking traffic Scale up only Minutes Seconds (continuous replication) Medium
Multi-site active/active Full production capacity serving traffic None (route away from failed Region) Near zero Near zero Highest

The sharp line between pilot light and warm standby is whether the recovery Region can serve a request right now: pilot light cannot until you turn servers on and scale; warm standby already handles traffic at reduced capacity and only needs scale-up. Hot standby is the active/passive variant of multi-site: full capacity is pre-provisioned in a standby Region for static stability (the recovery side is already fully built, so failover flips an existing switch rather than creating resources mid-incident, the principle is unpacked in Resilient failover below), but only one Region serves traffic at a time. Pick the cheapest strategy whose RTO/RPO still meet the business numbers; over-buying a multi-site design for an RTO of hours is just as wrong as under-buying a backup-and-restore design for an RTO of minutes.

More cost → Faster recovery (lower RTO/RPO) Backup & restore RTO/RPO: hours lowest cost Pilot light RTO: tens of minutes RPO: seconds Warm standby RTO: minutes RPO: seconds Multi-site active/active RTO/RPO: near zero highest cost
The four AWS DR strategies on one cost/recovery curve: each step right buys faster recovery (lower RTO/RPO) for higher ongoing cost.

RPO is set by the data layer: replication services and their limits

The strategy name does not set RPO. The data-replication mechanism does. A workload labelled "warm standby" still has an hours-long RPO if its data tier only snapshots periodically. Match the replication service to the required RPO. The figure groups the replication services by data tier so you can read each one's RPO at a glance.

Relational: Aurora global database and RDS cross-Region read replicas

An Amazon Aurora global database[2] replicates from one primary to up to 10 read-only secondary Regions with typical cross-Region replication latency under one second. AWS states RTO for an Aurora global database is in the order of minutes and RPO is typically measured in seconds[10]. Two recovery operations are distinct and heavily tested:

  • Switchover (formerly "managed planned failover") is for planned, healthy-state events; it synchronizes a secondary with the primary first, so its RPO is 0, no data loss[10].
  • Failover is for an unplanned Regional outage; because replication is asynchronous its RPO is a non-zero value measured in seconds[10], equal to the replication lag at the moment of failure. Aurora attempts to snapshot the old primary's volume so you can recover unreplicated data.

Monitor each secondary's lag with the AuroraGlobalDBRPOLag CloudWatch metric; on Aurora PostgreSQL the rds.global_db_rpo parameter[10] enforces an upper RPO bound by blocking commits when every secondary falls behind it (valid 20 seconds to ~68 years). Backtrack is not supported on a global database. For engines without Aurora, Amazon RDS cross-Region read replicas[11] replicate asynchronously and can be promoted to a standalone instance for disaster recovery (RDS for Oracle and Db2 offer mounted/standby replica modes whose primary purpose is cross-Region DR).

NoSQL and object: DynamoDB global tables, S3 CRR/SRR

Amazon DynamoDB global tables[3] provide multi-active, read-local/write-local replication, a fit for active/active write-local designs. The default multi-Region eventual-consistency mode reconciles concurrent writes with last-writer-wins per item; a strongly consistent (RPO 0) mode is restricted to exactly three Regions in a region set. Amazon S3 Cross-Region Replication (CRR)[4] copies objects asynchronously with no time guarantee; S3 Replication Time Control (S3 RTC)[5] adds an SLA that replicates the vast majority of objects within 15 minutes, emitting OperationMissedThreshold events and replication metrics when an object exceeds the threshold. Use it when a bounded, measurable S3 RPO is a compliance requirement.

Replication is not a backup

The single most-tested data-protection nuance: continuous replication faithfully copies corruption, accidental deletes, and malicious changes to the DR Region, so it does not protect against a data disaster. Pair it with S3 versioning or point-in-time snapshots so you can recover to a point before the bad event. S3 CRR's defaults help here: a DELETE that specifies a version ID is never replicated to the destination, which protects data from malicious deletions[12], and with a modern (Filter-based) replication rule, delete markers are not replicated by default[12] unless you explicitly enable delete-marker replication.

The data tier sets RPO, not the strategy name Relational Aurora global database up to 10 secondary Regions switchover: RPO 0 (no data loss) failover: RPO seconds RDS cross-Region read replica async; promote to standalone RPO seconds NoSQL and object DynamoDB global tables multi-active, read/write-local RPO seconds (eventual) RPO 0 in a 3-Region set S3 CRR / RTC CRR: async, no time guarantee RTC: 15-minute SLA, measurable RPO
Pick the replication service whose RPO meets the target: Aurora global database, RDS read replicas, DynamoDB global tables, or S3 CRR/RTC.

Resilient failover: data-plane controls, ARC, and DRS

Choosing the strategy is half the design; the other half is how you actually switch over, and how you protect the backups that make recovery possible. One model unifies this section: static stability means the recovery side is already fully built, so failover flips an already-existing switch rather than creating or reconfiguring resources mid-incident. The data-plane-vs-control-plane rule below is that same idea applied to traffic. The figure below walks that one question — is the failover trigger a data-plane operation? — to the preferred and the avoided mechanisms.

Fail over with data-plane operations, not control-plane

Control-plane operations (launching instances, creating resources, changing configuration, scaling) have lower availability design goals than data-plane operations and are the most likely thing to be impaired during a large-scale event. So drive failover with data-plane controls. Amazon Route 53 health-check DNS failover[1] and Application Recovery Controller (ARC) routing controls[6] are highly reliable on/off switches (routing controls are implemented as Route 53 health checks). By contrast, changing Route 53 weighted-record weights or a Global Accelerator traffic dial is a control-plane operation, workable, but less resilient at the exact moment you need it most. This is the static-stability principle from the section opener: prefer flipping an already-existing switch over creating or reconfiguring resources mid-incident.

ARC: routing controls, safety rules, readiness checks, zonal shift

Application Recovery Controller[6] gives four building blocks:

  • Routing controls: the data-plane on/off switches that fail traffic between Regions.
  • Safety rules: guardrails on routing-control state changes, e.g. preventing both an active and a standby replica from being enabled at once.
  • Readiness checks: continually monitor that the recovery Region's quotas, capacity, and routing are ready; AWS explicitly states a readiness check "is not intended to be used in the critical path for failover during an event" (it is preparation/steady-state only).
  • Zonal shift / zonal autoshift: for a single impaired Availability Zone (not a Region loss), shift traffic away from one AZ to healthy AZs in the same Region. A zonal shift is a temporary mitigation with an expiration from one minute up to three days (72 hours), extendable[13]; zonal autoshift lets AWS initiate the shift automatically. Prescale capacity in the remaining AZs first.

DRS implements pilot light; AWS Backup protects the copies

AWS Elastic Disaster Recovery (DRS)[9] continuously replicates server-hosted applications and databases into AWS at the block level using a low-cost staging-area subnet, following the pilot-light pattern; on failover or drill it converts servers to boot natively on AWS and launches a full-capacity recovery environment within minutes, with point-in-time recovery and failback. It targets on-premises, other-cloud, or EC2-hosted workloads, not managed services such as RDS.

Centralize and protect backups with AWS Backup[7], which schedules and monitors backups across services (EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx, Storage Gateway, and more) and can copy recovery points cross-Region and cross-account. Copying to a separate account means a compromised member account cannot delete the only copy. Make those copies immutable with AWS Backup Vault Lock[8]: governance mode can be removed by a sufficiently-privileged user, while compliance mode becomes immutable after a cooling-off grace period (ChangeableForDays, minimum 3 days / 72 hours) and afterward cannot be deleted or changed by any user (including root) or by AWS while it holds recovery points (maximum retention 36,500 days, ~100 years). Finally, prove the plan: AWS Backup restore testing[14] runs scheduled restores, measures their duration against RTO, and deletes the test resources, so you know recovery actually works before a real disaster.

Is the failover trigger a data-plane operation? Yes Data-plane controls (preferred) Route 53 health-check DNS failover ARC routing controls resilient on/off switch No Control-plane operation (avoid) Route 53 weights / GA traffic dial launch or scale resources lower availability goal Static stability: flip an already-built switch never reconfigure resources mid-incident (control-plane is likeliest to be impaired)
Drive failover with data-plane on/off switches (Route 53 health checks, ARC routing controls), not control-plane changes that may be impaired.

Exam-pattern recognition: SAP-C02 BC/DR stems

SAP-C02 BC/DR questions hand you concrete RTO/RPO numbers, a cost or compliance constraint, and four plausible architectures. Read the numbers first, then eliminate.

Pattern 1: "RPO of seconds, RTO in minutes, minimize steady-state cost"

Stem: a new regional application needs an RPO of seconds and an RTO of a few minutes at the lowest ongoing spend. Correct: pilot light, continuous replication (Aurora global database[2] or DynamoDB global tables[3]) into an always-on core with app servers off, possibly via DRS[9]. Why distractors fail: backup & restore gives RPO/RTO in hours, missing both numbers; multi-site active/active meets them but is rejected by the "lowest cost" constraint; nightly cross-Region snapshots make RPO equal to the backup interval, not seconds.

Pattern 2: "Replicate to a second Region but survive accidental/malicious deletion"

Stem: data is in S3 (often versioned) and replicated cross-Region; an object is deleted or corrupted. Correct: keep S3 versioning plus the CRR defaults that shield the replica, a version-ID DELETE is not replicated to the destination[12] and delete markers are not replicated by default[12]; add Object Lock or backups for true immutability. Why distractors fail: "CRR alone protects against deletion" is wrong, replication copies the change verbatim, so it is not a backup (the rule from RPO is set by the data layer above); "enable delete-marker replication" makes the problem worse by propagating the delete; restoring from a same-bucket version ignores the corruption scenario.

Pattern 3: "Bounded, SLA-backed S3 replication for compliance"

Stem: a regulator requires that objects replicate within a measurable, guaranteed window. Correct: S3 Replication Time Control[5] (SLA, vast majority within 15 minutes, with OperationMissedThreshold events). Why distractors fail: plain CRR is asynchronous with no time guarantee; S3 Transfer Acceleration is an upload-latency feature, not replication; cross-Region AWS Backup copy is scheduled, not continuous.

Pattern 4: "Centralized, immutable backups across an Organization"

Stem: many member accounts under AWS Organizations need centralized backup with WORM immutability against an insider or a compromised account. Correct: AWS Backup[7] with cross-account, cross-Region copy into a dedicated backup account, plus Vault Lock in compliance mode[8]. Why distractors fail: governance-mode lock can be removed by a privileged user, so it fails "cannot be deleted by anyone"; per-account scripts and lifecycle rules are not centralized and not immutable; storing the only copy in the source account leaves it deletable by a compromised admin.

Pattern 5: "Reliable multi-Region failover / single-AZ impairment"

Stem: a multi-Region active-passive (or active-active) app must fail over reliably, or a single AZ is degraded. Correct for Region failover: ARC routing controls[6] (data-plane on/off switches) with safety rules; for a single bad AZ, ARC zonal shift (up to 72 hours, extendable[13]), no Region failover needed. Why distractors fail: changing Route 53 weighted-record weights or a Global Accelerator traffic dial is a control-plane operation and less resilient during an event (the data-plane rule from Resilient failover above); relying on Auto Scaling to launch DR capacity at failover is a control-plane dependency that may be impaired, pre-provision (warm/hot standby) instead; ARC readiness checks are steady-state monitoring and are explicitly not for the failover critical path.

The four AWS DR strategies by RTO, RPO, cost, and effort (SAP-C02)

DimensionBackup & restorePilot lightWarm standbyMulti-site active/active
Typical RTOHours (redeploy + restore)Tens of minutes (turn on + scale)Minutes (scale up only)Near zero (no failover)
Typical RPOHours (backup interval)Seconds (continuous replication)Seconds (continuous replication)Near zero (continuous replication)
DR-Region stateData backups only; infra not deployedData live + core infra on; app servers OFFScaled-down full stack always runningFull production capacity, serving traffic
Failover actionDeploy IaC, restore dataTurn servers on, scale outScale up existing stackNone (route away from failed Region)
Relative costLowestLowMediumHighest
Routing modelActive/passiveActive/passiveActive/passiveActive/active (or hot standby = active/passive)

Decision tree

RTO/RPO in hours and cost is the priority? Yes, hours OK Backup & restore AWS Backup cross-Region copy + CloudFormation/CDK redeploy No, need faster Must serve traffic immediately at failover? No, minutes OK Pilot light data live, app servers OFF; turn on + scale (DRS option) Yes Need near-zero RTO and budget for full DR capacity? No, scaled-down OK Warm standby scaled-down live copy; scale up with EC2 Auto Scaling Yes Multi-site active/active full capacity per Region; highest cost (or hot standby) Data layer sets RPO Aurora global DB / DynamoDB global tables / S3 CRR + RTC Always: fail over via data-plane (Route 53 health-check DNS / ARC routing controls), pair replication with versioning or point-in-time backups, protect copies with AWS Backup cross-account copy + Vault Lock, and prove the plan with DR drills (GameDays) and restore tests.
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

RTO is downtime tolerance, RPO is data-loss tolerance

RTO (Recovery Time Objective) is the maximum acceptable time to restore service after a disruption; RPO (Recovery Point Objective) is the maximum acceptable data loss, measured as a span of time before the disruption. The two are independent levers: continuous replication can drive RPO to near-zero while RTO stays high because servers still have to be turned on and scaled up before they serve traffic. Set both from business need, then choose the strategy that meets them.

Trap Assuming a near-zero RPO automatically buys a near-zero RTO: replicated data can sit on infrastructure that still needs minutes to come online.

Four DR strategies sit on a cost-vs-recovery curve

AWS frames four DR strategies, cheapest/slowest to costliest/fastest: backup and restore, pilot light, warm standby, and multi-site active/active. Backup and restore lands RTO/RPO in hours; multi-site active/active reaches near-zero RTO for most disasters. Choose by the RTO/RPO the business actually requires against budget, since each step up the curve trades ongoing cost for faster recovery.

Trap Defaulting to multi-site active/active for every workload: it is the most complex and costly option, and many workloads are met far more cheaply by pilot light or warm standby.

Backup and restore redeploys infrastructure from IaC, then restores data

Backup and restore is the lowest-cost strategy: it keeps only data backups (plus point-in-time recovery) in the recovery Region and, on disaster, redeploys infrastructure from CloudFormation/CDK IaC before restoring data from AWS Backup or snapshots. RTO is in hours because nothing is pre-running, so it fits workloads that can tolerate extended downtime. Restore is a control-plane operation, so periodically pre-restore to prove recovery is viable even if the control plane is degraded.

Trap Trusting an untested backup as a DR plan: restore is a control-plane action that can fail exactly when a Region is impaired, so unexercised backups may not restore when needed.

Pilot light keeps data live but application servers switched off

Pilot light replicates data live and provisions core infrastructure, but application servers are loaded and "switched off": they must be turned on and scaled out before they can serve traffic. This yields a low RPO with an RTO of tens of minutes at low ongoing cost, since only the data layer runs continuously. The defining line: pilot light cannot process requests until you act, which is exactly what separates it from warm standby.

Trap Treating pilot light as ready to serve traffic on failover: it cannot, because the application tier is off until you switch it on and scale it.

Warm standby runs a scaled-down copy that already serves traffic

Warm standby keeps a scaled-down but fully functional copy of production always running in the recovery Region, handling traffic at reduced capacity, so failover only needs a scale-up: no servers to turn on. It buys a faster RTO than pilot light in exchange for higher steady-state cost. Raise DR-Region service quotas ahead of time so the scale-up to full production capacity is not throttled at the worst moment.

Trap Assuming the DR Region can scale to production capacity on demand, when default service quotas there cap the recovery scale-up and stall failover during the incident.

Pilot light needs servers turned on; warm standby only needs scale-up

Pilot light and warm standby both keep a copy of primary assets in the DR Region, but the distinction AWS draws is operational: pilot light cannot process requests without additional action first (turn on servers, possibly deploy non-core infra, then scale), whereas warm standby handles traffic immediately at reduced capacity and only needs to scale up. Use the required RTO to choose: warm standby recovers faster but costs more to keep running.

Trap Assuming pilot light keeps a small fleet already serving traffic just like warm standby, when its compute is off until you act, so only warm standby handles requests immediately at reduced capacity.

Multi-site active/active has no failover; hot standby is the active/passive twin

Multi-site active/active serves production traffic from every Region it is deployed to, so there is no failover step: you simply route away from a failed Region. Hot standby is the active/passive variant: full capacity is pre-provisioned and statically stable in the standby Region, but only one Region takes traffic until cutover. Both are the highest-cost strategies and target near-zero RTO; AWS notes most teams that stand up a full second Region just run it active/active.

Trap Calling any two-Region deployment "active/active": if only one Region actually receives user traffic, it is hot standby (active/passive), not active/active.

RPO is set by the data layer's replication, not the strategy name

The replication mechanism, not the strategy label, determines RPO. Continuous asynchronous replication (Aurora global database, DynamoDB global tables, S3 Cross-Region Replication) gives a near-zero RPO; periodic snapshots make RPO equal to the backup interval. A design labelled "warm standby" still carries an hours-long RPO if its data layer only snapshots: match the replication to the RPO you need.

Trap Inferring RPO from the DR strategy's name: a warm-standby compute tier paired with snapshot-only data still loses everything since the last snapshot.

Replication faithfully copies corruption, so it is not a backup

Continuous replication copies corruption, accidental deletes, and malicious changes straight to the DR Region, so it cannot recover from a data disaster on its own. Pair replication with S3 versioning or point-in-time snapshots so you can roll back to a moment before the bad event. With S3 Cross-Region Replication, a delete with no version ID writes a delete marker in the source bucket only by default, shielding the replica from source-side deletions.

Trap Relying on cross-Region replication as your backup: it propagates corruption and deletions verbatim, leaving no clean point to recover from without versioning or snapshots.

3 questions test this
Aurora global database spans up to 10 secondary Regions with sub-second lag

An Amazon Aurora global database replicates from one primary to up to 10 read-only secondary Regions with cross-Region replication latency typically under one second, using dedicated storage-layer infrastructure that doesn't tax the database engine. On a Region outage you can promote a secondary to read/write in under a minute, and you can monitor each secondary's RPO lag. It supports write forwarding, but Backtrack is not supported on a global database.

Trap Expecting Aurora Backtrack to undo changes on a global database: Backtrack is unsupported there, so cross-Region promotion or snapshot copy is the recovery path.

DynamoDB global tables give multi-active write-local replication

Amazon DynamoDB global tables replicate across Regions and let any replica take reads and writes, fitting active/active write-local designs. The default multi-Region eventual-consistency (MREC) mode replicates within about a second and reconciles concurrent updates with last-writer-wins per item, giving an RPO equal to the replication delay. The strongly consistent multi-Region (MRSC) mode delivers RPO=0 but must be deployed in exactly three Regions within one region set.

Trap Assuming global tables give cross-Region strong consistency by default: the default MREC mode is eventually consistent (RPO > 0); RPO=0 requires the three-Region MRSC mode.

S3 Replication Time Control puts an SLA window on replication

Standard S3 Cross-Region Replication is asynchronous with no time guarantee. S3 Replication Time Control (S3 RTC) replicates most new objects in seconds and is backed by an SLA to replicate 99.9% of objects within 15 minutes, emitting OperationMissedThreshold events and S3 Replication metrics when an object exceeds that 15-minute threshold. Use S3 RTC when a bounded, measurable S3 RPO is a compliance requirement rather than best-effort.

Trap Counting on plain S3 CRR for a guaranteed replication window: only S3 RTC carries the 15-minute SLA and missed-threshold events; standard CRR makes no timing promise.

5 questions test this
Aurora Backtrack rewinds in place; it is not cross-Region DR

Aurora Backtrack rewinds a cluster to an earlier point in time in place (Aurora MySQL only, up to 72 hours) and never moves data to another Region, so it is not a cross-Region DR mechanism and is unsupported on an Aurora global database. It is fast in-place recovery from logical errors; for Region-level recovery use an Aurora global database or a cross-Region snapshot copy instead.

Trap Choosing Aurora Backtrack to recover from a Region outage: it only rewinds the cluster in place (MySQL, 72h max), providing no copy in another Region.

AWS Backup centralizes cross-account and cross-Region copies

AWS Backup schedules and monitors backups across services (EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx, Storage Gateway) from one place and can copy recovery points cross-Region and cross-account. Copying to a separate account is the key insider-threat and account-compromise defense: a compromised member account cannot delete a copy held in a different account. Pair cross-Region copy for Region resilience with cross-account copy for blast-radius isolation.

Trap Keeping every backup copy in the same account as production: an account compromise or insider can then delete the only copies; a cross-account copy survives that.

7 questions test this
Backup Vault Lock in compliance mode is immutable after the grace time

AWS Backup Vault Lock enforces WORM on a vault. Governance mode can be removed by users with sufficient IAM permissions; compliance mode has a cooling-off grace time (ChangeableForDays, minimum 3 days / 72 hours) during which it can still be changed, after which the vault and lock become immutable and cannot be deleted or altered by any user or by AWS while recovery points remain. You can set min/max retention, with a maximum of 36,500 days (~100 years).

Trap Expecting to remove a compliance-mode vault lock after its grace time: once ChangeableForDays elapses it is immutable to everyone, including AWS and the root user.

10 questions test this
Drive Region failover with data-plane operations, not control-plane

Resilient Region failover should use data-plane operations, which have higher availability design goals than control planes. Route 53 health-check DNS failover and ARC routing controls (on/off switches built on Route 53 health checks) are data-plane and stay available during an incident. Changing Route 53 weighted-record weights or a Global Accelerator traffic dial is a control-plane operation, so it is less resilient at exactly the moment you most need to fail over.

Trap Failing over by editing Route 53 record weights or a Global Accelerator traffic dial: those are control-plane changes that may be unavailable during the disaster; use data-plane ARC routing controls.

3 questions test this
ARC safety rules guard routing-control changes; readiness checks watch steady-state

ARC safety rules are guardrails on routing-control state changes: an assertion rule can enforce that at least one routing control stays On to prevent a fail-open scenario, and a gating rule acts as a master on/off switch over a set of controls. Separately, ARC readiness checks continually monitor that the recovery Region's quotas, capacity, and routing stay aligned with production, but AWS says they are for ongoing preparation, not a primary failover trigger (and readiness check is no longer open to new customers).

Trap Using ARC readiness checks as the failover trigger: AWS states they verify steady-state alignment and should not be relied on to initiate recovery during a disaster.

1 question tests this
AWS Elastic Disaster Recovery implements the pilot-light pattern

AWS Elastic Disaster Recovery (DRS)[9] continuously replicates server-hosted applications and databases into AWS at the block level using a low-cost staging-area subnet, following the pilot-light pattern. On failover it converts servers to boot natively on AWS and automatically launches a full-capacity environment, with recovery instances ready within minutes. It targets on-premises, other-cloud, or EC2-hosted workloads, not managed services such as RDS.

Trap Reaching for AWS DRS to protect managed services like RDS: DRS replicates server/EC2 block storage, so RDS and similar managed databases need their own DR (cross-Region replicas or snapshots).

4 questions test this
An untested DR plan is not a plan: exercise it regularly

DR readiness comes only from exercising it: run failover drills (GameDays), verify that restores from backup actually complete, and for active/active confirm that traffic routes away from a lost Region and the survivors absorb full load. Automate the failover steps even when a human initiates them, so recovery is a single deterministic action rather than an error-prone scramble under pressure.

Speed Route 53 failover with low TTL and faster health checks

DNS-based failover time is governed by record TTL plus health-check speed. Lower the TTL (commonly 60 seconds or less) so resolvers stop caching the old answer quickly, choose Route 53's fast 10-second health-check interval instead of the standard 30-second one, and reduce the failure threshold so an endpoint is marked unhealthy after fewer failed probes. A high TTL keeps sending users to the failed Region long after the health check has already flipped.

Trap Tuning only the health-check interval while leaving a high record TTL: resolvers keep serving the cached failed endpoint until the TTL expires, no matter how fast the check flips.

5 questions test this
Route 53 returns the primary record when all failover targets are unhealthy

In a failover routing configuration, if Route 53 considers both the primary and secondary records unhealthy, it returns the primary record rather than no answer: it must return something, so it falls back to primary. This is why traffic can keep flowing to a failed primary even during an outage; to force a true cutover, make sure the secondary stays healthy (or rework the health-check association) so Route 53 has a healthy target to choose.

Trap Expecting Route 53 to stop answering when every endpoint is unhealthy: it returns the primary record instead, so an unhealthy secondary leaves users pinned to the dead primary.

3 questions test this
Set Evaluate Target Health to Yes on alias records for automatic failover

For alias records pointing to ALBs/NLBs (including latency-based and weighted alias records), set Evaluate Target Health to Yes so Route 53 derives endpoint health from the load balancer's registered targets without a separate health check. When the closest Region's targets are all unhealthy, Route 53 backs out of that branch and routes to the next-best healthy Region automatically. With it set to No, Route 53 keeps sending traffic to the failing alias target.

Trap Leaving Evaluate Target Health set to No on alias records: Route 53 then routes to the alias target even when its underlying targets are all unhealthy, defeating automatic failover.

9 questions test this
Use CloudWatch-alarm health checks for private or metric-based targets

Route 53 health checkers run from outside the VPC and cannot reach private IP addresses, so for resources with only private IPs (or for any condition best expressed as a metric) create a CloudWatch alarm and a Route 53 health check that monitors that alarm's data stream. This also lets you fail over on application signals such as 5XX counts or response time, not just basic reachability. The CloudWatch alarm must live in the same account as the health check.

Trap Pointing a standard Route 53 endpoint health check at a private IP: the public health checkers can't reach it, so route via a CloudWatch-alarm health check instead.

5 questions test this
Use ARC routing controls for operator-driven failover and failback

Amazon Application Recovery Controller (ARC) routing controls are simple on/off switches wired to Route 53 DNS failover records, making failover and failback deliberate operator decisions rather than automatic flapping on a health check. Each ARC cluster is a data plane of redundant endpoints spread across five AWS Regions, so you can toggle controls during an incident without depending on a single Region's control plane.

Trap Letting an automatic health check flip Regions when you need a controlled cutover: health-check automation can flap; ARC routing controls keep failover and failback as deliberate operator actions.

5 questions test this
Make the cross-Region read replica Multi-AZ before you promote it

Configure an RDS cross-Region read replica as a Multi-AZ deployment before a disaster, so that when you promote it to a standalone primary it is already Multi-AZ and highly available immediately, with no separate conversion step during recovery (otherwise modifying to Multi-AZ is an extra post-promotion action). Promotion is the standard low-RPO cross-Region DR cutover for RDS, paired with pointing the application at the new endpoint.

Trap Promoting a single-AZ cross-Region replica during a disaster and only then converting it to Multi-AZ: that conversion adds time and leaves the new primary without standby HA at the worst moment.

11 questions test this
Detect missed RPO with the AWS Backup Audit Manager last-recovery-point control

AWS Backup Audit Manager evaluates backup activity against controls in a framework; the "Last recovery point was created" control flags any resource whose most recent recovery point is older than a configured window (set in hours, 1–744, or days, 1–31), which is how you automatically detect a missed RPO. Report plans deliver scheduled compliance reports to an S3 bucket for auditors, and cross-account aggregation is available to a management or delegated administrator account.

Trap Assuming a backup plan alone guarantees RPO compliance: without the "last recovery point" control, a silently failed or skipped backup goes unnoticed until you need to restore.

6 questions test this
AWS Backup cold storage carries a 90-day minimum and copy constraints

An AWS Backup lifecycle moves recovery points to cold storage after a set number of days, but a backup must remain in cold storage for a minimum of 90 days, so the delete-after value must be at least the transition-to-cold days plus 90 (total retention of 90+ days is required to use cold storage at all). AWS Backup does not support cross-Region copies of recovery points already in a cold tier, so initiate any cross-Region copy before the point transitions to cold.

Trap Scheduling a cross-Region copy of a recovery point that has already moved to cold storage: AWS Backup can't copy cold-tier points across Regions, so the copy must happen before the cold transition.

4 questions test this
S3 lifecycle rules are not replicated: set matching rules on both buckets

S3 Replication copies objects but not the bucket's lifecycle configuration, and lifecycle actions on the source (such as expirations) are not applied to the destination: Amazon S3 even creates expiry delete markers on the source without replicating them. To keep source and destination consistent (matching transition and noncurrent-version expiration behavior), configure identical lifecycle policies on both buckets independently, or the replica accumulates versions and drifts from the source's retention.

Trap Assuming a source-bucket lifecycle policy also ages out the replica: lifecycle config and its actions don't replicate, so the destination must carry its own identical rules.

8 questions test this

Also tested in

References

  1. Disaster recovery options in the cloud (AWS DR whitepaper) Whitepaper
  2. Amazon Aurora global databases
  3. Amazon DynamoDB global tables
  4. Replicating objects with S3 Cross-Region Replication
  5. Meeting compliance requirements with S3 Replication Time Control
  6. What is Amazon Application Recovery Controller (ARC)?
  7. What is AWS Backup?
  8. AWS Backup Vault Lock
  9. What is AWS Elastic Disaster Recovery?
  10. Using switchover or failover in Amazon Aurora Global Database
  11. Working with DB instance read replicas (Amazon RDS)
  12. What does Amazon S3 replicate?
  13. Zonal shift in ARC (Amazon Application Recovery Controller)
  14. Restore testing in AWS Backup