AWS DevOps Engineer Professional Training Course

AWS names four disaster recovery strategies, and DOP-C02 expects you to choose among them from a stated recovery objective and cost constraint. They form a spectrum: as recovery time and recovery point shrink, standing cost rises and more of the secondary environment must exist before the disaster. Nothing else about them is complicated, which is why the exam tests the boundaries between them rather than the definitions.

Backup and restore

Data is backed up and copied to a second region. Nothing runs there. On disaster, you deploy the infrastructure from templates and restore the data.

RTO is hours — possibly many, since you are provisioning an entire environment and restoring a full data set. RPO is the backup interval, so hours unless backups are continuous. Cost is the lowest of the four, since you pay only for stored backups.

This is the right answer when the scenario tolerates a long outage and emphasizes cost, and it is a perfectly respectable strategy for internal or batch workloads. Make the recovery credible by keeping the infrastructure templates deployable in the DR region, copying backups cross-region with AWS Backup, and testing restores on a schedule — an untested restore is what turns a documented eight-hour RTO into a real thirty-hour one.

Pilot light

A minimal core runs continuously in the second region: the data layer is replicated and live, and everything else exists as configuration but is switched off — AMIs built, templates ready, Auto Scaling groups at zero desired capacity, no load balancer traffic.

RTO drops to tens of minutes because you no longer restore data; you scale up compute and cut traffic over. RPO drops to replication lag, typically seconds to minutes. Cost is the replicated storage and database plus the trickle of always-on infrastructure.

The exam signal is a scenario that says the database must be continuously replicated but that running duplicate application capacity is not acceptable. The risk to name is that scaling up the compute tier is a control plane operation performed exactly when a region is impaired and everyone else is trying to do the same thing, so instance capacity is not guaranteed. That is why the next strategy exists.

Warm standby

A scaled-down but fully functional copy of the environment runs continuously in the second region — the same components, fewer or smaller instances, real traffic optionally routed to it. On disaster you scale it up and shift all traffic.

RTO is minutes, because the environment is already serving; you are changing its size, not creating it. RPO remains replication lag. Cost is meaningfully higher than pilot light because every tier runs.

Warm standby's real advantage over pilot light is not just speed — it is that the environment is continuously exercised, so you know it works. A pilot light environment that has never served a request may be missing a security group rule nobody noticed. When a scenario emphasizes confidence that failover will actually succeed, warm standby is the stronger answer.

Multi-site active-active

Both regions serve production traffic simultaneously, with data replicated bidirectionally or partitioned so each region owns its own writes.

RTO approaches zero because there is no failover event — you remove a region from routing and the other absorbs the load. RPO approaches zero within the limits of the replication mechanism. Cost is the highest, and so is complexity: bidirectional replication forces you to confront write conflicts, and DynamoDB global tables resolve them with last-writer-wins, which is a design decision and not a property you get for nothing.

Active-active also demands that each region be able to carry the full load, otherwise losing one region overloads the survivor — the static stability argument again. A scenario describing an active-active design that failed under a regional outage usually failed because the surviving region was sized for half the traffic.

Choosing from the scenario

The mapping is mechanical once you extract the numbers:

• RTO in hours, cost-sensitive, tolerant of a lengthy outage — backup and restore.
• RTO in tens of minutes, RPO in minutes, no duplicate compute cost — pilot light.
• RTO in minutes, failover must be proven to work, some duplicate cost acceptable — warm standby.
• RTO near zero, no acceptable downtime, cost and complexity accepted — active-active.

Watch for the constraint that eliminates the obvious answer. A regulatory requirement for data residency can rule out a second region entirely and push you toward multi-AZ resilience plus offline backups. A stateful application that cannot tolerate last-writer-wins rules out naive active-active. A workload whose data set is enormous makes restore time the binding constraint, which pushes backup and restore out of contention even if cost would favor it.

What makes any of them real

Three things separate a DR strategy from a DR document.

Infrastructure as code in both regions. The secondary environment must be deployable from the same templates, with region-specific values as parameters. Anything created by hand in the primary region does not exist in the secondary one.

An automated, tested failover procedure. Route 53 health checks with failover routing, or Application Recovery Controller routing controls for a deliberate manual switch that does not depend on health check propagation. A runbook that requires an engineer to remember eleven steps has an RTO measured in that engineer's availability.

Regular exercises. Game days that actually fail over, in a non-production environment at minimum and in production where the business can bear it. Fault injection experiments that verify the individual mechanisms. Scheduled restore tests that measure how long a restore really takes. Every DR scenario that mentions uncertainty about whether the plan works is answered by adding one of these, not by adding more infrastructure.