AWS Solutions Architect Professional Training Course

Disaster recovery is one of the most reliably scored areas of Domain 2, because the mapping from objectives to architecture is deterministic. If you can convert a stated recovery time objective and recovery point objective into a strategy, and then name the mechanism that delivers it, you will answer these items quickly.

The two objectives, precisely

Recovery time objective (RTO) is how long the business will tolerate being down. Recovery point objective (RPO) is how much data the business will tolerate losing, measured as a window of time before the failure. They are independent. A workload can accept losing eight hours of data but need to be serving traffic within fifteen minutes, and the reverse is equally common.

RPO drives the replication mechanism. RTO drives how much infrastructure exists before the disaster. Keeping those two mappings separate is the fastest way to eliminate options that get one right and the other wrong — for example, an answer with continuous replication satisfying a tight RPO but requiring hours of infrastructure provisioning against a fifteen-minute RTO.

The four strategies

Backup and restore. Data is backed up to the recovery Region; nothing runs there. Recovery means provisioning infrastructure from templates and restoring data. RTO in hours, RPO equal to the backup interval. Cheapest by a wide margin. Correct when the scenario tolerates hours of downtime, or for workloads whose business impact is genuinely low.

Pilot light. The core data layer is replicated and running — a cross-Region read replica, a replicated table — while the compute tier exists as templates and images but is switched off. Recovery means scaling the compute up and promoting the database. RTO in tens of minutes, RPO in seconds to minutes. Costs little more than the storage and replication.

Warm standby. A scaled-down but fully functional copy of the workload runs in the recovery Region and can serve traffic immediately, then scales up. RTO in minutes, RPO in seconds. Costs the standby capacity continuously. This is the answer whenever a scenario needs failover in minutes but cannot justify running full capacity twice.

Multi-site active-active. Both Regions serve production traffic. There is no failover event, only a traffic shift. RTO and RPO approach zero, subject to how the data layer is replicated. It is the most expensive and by far the most operationally demanding, and it forces you to solve the hard data problems: write conflicts, eventual consistency, and idempotency.

Match the strategy to the objective and no further. An answer proposing active-active for a workload with a four-hour RTO is over-built and will rank below warm standby or pilot light unless the scenario names another reason — a regulatory requirement for continuous availability, or a latency requirement that already demands presence in both Regions.

Delivering the RPO

The replication mechanism is where these items are won or lost:

• Aurora Global Database replicates through the storage layer with typical cross-Region lag around a second, and supports managed planned failover and unplanned promotion of a secondary Region.
• RDS cross-Region read replicas replicate asynchronously at the engine level, with lag that varies under write load. Promotion is manual and breaks replication.
• DynamoDB global tables replicate multi-active with last-writer-wins conflict resolution, which is excellent for the RPO and requires the application to tolerate that resolution rule.
• S3 Cross-Region Replication is asynchronous; Replication Time Control adds a service level agreement on the replication window and metrics when objects fall behind, which is the answer when an RPO on object data must be evidenced.
• AWS Backup supports cross-Region and cross-account copies on a policy applied through the organization, which is the low-effort answer for backup-and-restore across an estate.
• AWS Elastic Disaster Recovery performs continuous block-level replication from source servers into a staging area, giving sub-minute RPO and recovery in minutes without a full standby environment. It is the right answer for workloads that cannot be re-platformed onto native replication.

Two traps. First, a multi-AZ deployment is high availability within a Region, not disaster recovery — it does not protect against a Regional event or a logical error such as a bad deployment or a mistaken deletion. Second, replication faithfully replicates corruption and deletion. A design whose only protection is replication has no answer for ransomware or a bad migration script; point-in-time recovery, versioning, object lock, and immutable backup vaults are what cover that, and a scenario mentioning malicious deletion is asking for them explicitly.

Failover mechanics

Deciding to fail over is a distinct problem from being able to. Design the health signal so it reflects the application, not just the endpoint: a Route 53 health check driven by a CloudWatch alarm on error rate or replication lag is more honest than a check that a port is open. Then choose the redirection mechanism — Route 53 failover routing, subject to DNS caching, or Global Accelerator, which shifts traffic within the AWS network with no dependence on client caches.

Route 53 Application Recovery Controller is worth knowing for the harder cases. Readiness checks continuously verify that the recovery Region actually has the capacity and configuration to take over, which prevents the classic failure of failing over into a Region that was never quite ready. Routing controls provide a highly available on-off switch with a safety rule set, so a human can shift traffic even when the control plane in the failing Region is impaired.

Failback, and testing

Plans stop at failover far too often. Failback requires reversing replication, reconciling data written in the recovery Region, and choosing a window for the return. Write it down before the incident, because doing it under pressure is how data gets lost.

A recovery plan that has not been tested is an assumption. Test with real game days: fail over on a schedule, measure the actual RTO against the objective, and check that runbooks, IAM permissions, quotas, and capacity in the recovery Region are all present. Service quotas in particular are per-Region and are the single most common cause of a failover that stalls halfway. Where capacity must be guaranteed, an On-Demand Capacity Reservation in the recovery Region is the mechanism, because a Savings Plan is a discount and reserves nothing.