Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson explains Recovery Point Objective (RPO), Recovery Time Objective (RTO), replication and recovery techniques, and the four common disaster recovery (DR) strategies used to balance recovery speed, data loss, complexity, and cost in AWS environments.

The key assessment skill is recognizing the business requirement first—acceptable data loss and acceptable downtime—and then selecting an appropriate recovery architecture.

Key Concepts

Recovery Point Objective (RPO)

RPO is the maximum amount of data loss that the business can accept after a failure. It is expressed as a period of time:

A two-hour RPO means the organization can accept losing up to two hours of data.
The backup, snapshot, or replication process must be frequent enough to meet that target.
If a failure occurs immediately before the next scheduled backup, the potential loss approaches the full RPO interval.

Reducing RPO generally requires more frequent backups, faster replication, or continuously replicated data. Those capabilities increase cost and operational complexity.

Recovery Time Objective (RTO)

RTO is the maximum acceptable time required to restore service after a disaster. For example, a four-hour RTO means the application must be available to serve demand again within four hours of the event.

RTO measures service restoration time, not data loss. A workload can have a short RTO but still lose data if its RPO is long, or it can have a short RPO but take a long time to become operational.

Recovery Point and Recovery Time on a Timeline

At the moment of failure:

The time since the last backup or synchronization determines the potential data loss and therefore relates to the RPO.
The time required to restore infrastructure and resume service determines the RTO.

For example, a workload with a two-hour RPO and two-hour RTO could lose nearly two hours of data and remain unable to process new demand for up to two additional hours.

Replication and Recovery Techniques

The desired RPO influences how data must be protected:

Approximate RPO range	Technique	Main characteristic
Milliseconds to seconds	Synchronous replication	A transaction is not fully committed until the second copy confirms that it has been stored.
Seconds to minutes	Asynchronous replication	Replication does not wait for the destination response, allowing longer-distance replication with less latency impact, but some replication lag is possible.
Minutes to hours	Snapshots and cloud backups	Point-in-time copies, such as EBS or database snapshots, are taken periodically.
Hours to days	Traditional off-site backups	Tape-based or similar techniques provide lower-cost protection but slower recovery and larger potential data loss.

The lecture also distinguishes disk-to-disk replication, where data is copied between online storage systems such as traditional SAN or NAS environments. This can provide relatively fast replication and restoration.

Techniques That Influence RTO

The recovery mechanism influences how quickly service can return:

Fault tolerance: Mirrored disks or similar designs can fail over almost immediately when a component fails.
Traditional high availability, load balancing, and automatic scaling: These can restore service in seconds to minutes, depending on how quickly replacement capacity becomes available.
Cross-site recovery and automated restoration: Snapshot-based or automated recovery processes typically fit the minutes-to-hours range.
Manual cross-site recovery: Recovery using separate on-premises sites and manual procedures may take hours to days.

Automation and pre-provisioned resources generally reduce RTO, but they add implementation and operating cost.

AWS Disaster Recovery Strategies

AWS DR strategies are commonly compared as an active-passive progression followed by active-active. The first three strategies keep the recovery environment partially or fully inactive until needed; multi-site active-active serves traffic from multiple locations at the same time.

Backup and Restore

Backup and restore is suitable for lower-priority workloads where longer recovery times are acceptable.

Typical workflow:

Create backups or snapshots, such as EBS snapshots or copies of file-system and database data.
Store or replicate the backup data, potentially in Amazon S3 or another Region.
Provision or restore the required infrastructure after the disaster.
Restore the data and bring the application online.

This is the lowest-cost option among the four strategies, but it generally has the slowest recovery and the greatest dependence on restore and provisioning steps. EBS snapshots and AMIs can be moved across Regions so that resources can be restored in another Region when required.

Pilot Light

In a pilot light design, critical data is replicated to a secondary Region, while most application infrastructure remains stopped or absent.

The secondary environment may retain only the minimum services needed to activate the application, such as:

Replicated file systems or databases
Authentication services such as Active Directory
DNS or DHCP services, depending on the design
Certificate or public-key-infrastructure services
Elastic Load Balancing and an Auto Scaling configuration prepared for activation

After a disaster, the environment is expanded and application resources are started or scaled out. Pilot light costs more than backup and restore but provides a faster recovery path.

Warm Standby

Warm standby is similar to pilot light, but the secondary Region already runs part of the application stack. For example, some EC2 instances may be running behind a load balancer.

Because capacity is already available, the application can begin serving load more quickly than with pilot light. The environment can then scale up and out after the event. Warm standby is appropriate for more business-critical workloads when a faster RTO justifies the additional cost.

Multi-Site Active-Active

Multi-site active-active maintains running application environments in multiple Regions. Route 53 sends traffic to load balancers in both Regions, and both sites have active instances.

This is the highest-cost strategy, but it is designed for mission-critical workloads requiring very low downtime and near-zero data loss. It avoids waiting for a secondary site to be activated, although the data layer still determines the achievable RPO and whether true active-active writes are possible.

Database Considerations

Active-active database behavior must be evaluated separately from the application tier:

DynamoDB global tables support multi-Region, multi-master active-active writes. Replication between Regions is asynchronous, so replication lag can still occur.
Aurora does not allow normal writes to the secondary Regional database in the same active-active manner. After a disaster, the secondary database must be promoted before it becomes the writable database.

Therefore, an application may be active-active at the traffic and compute layers without being active-active at the database write layer.

Exam- or Assessment-Relevant Takeaways

RPO answers “How much data can be lost?” RTO answers “How long can recovery take?”
Do not confuse backup frequency with recovery duration. Backup frequency primarily affects RPO; restoration and infrastructure activation primarily affect RTO.
Synchronous replication provides very low RPO but is constrained by latency and distance.
Asynchronous replication supports longer distances and faster application commits, but replication lag creates potential data loss.
Backup and restore is the lowest-cost and generally slowest DR pattern.
Pilot light keeps data and minimum supporting services ready while most application resources are inactive.
Warm standby keeps some application capacity running, reducing activation time compared with pilot light.
Multi-site active-active runs application environments in multiple Regions and routes traffic to both, producing the highest cost and potentially the lowest downtime.
Route 53 failover routing is consistent with a primary/secondary model such as pilot light or warm standby; routing traffic to both Regional load balancers represents active-active behavior.
DynamoDB global tables support multi-Region active-active writes, while an Aurora secondary must be promoted before it can serve as the writable database after a disaster.
Multi-AZ and multi-Region designs solve different problems. The DR strategy discussion emphasizes Regions for geographic disaster recovery, while AWS services already provide strong availability capabilities across Availability Zones.

Tool / Feature Decision Guide

Requirement or situation	Prefer	Why
Lower-priority workload and lowest DR cost	Backup and restore	Accepts longer restoration and requires provisioning and data restoration after failure.
Data must be ready, but most compute can remain inactive	Pilot light	Replicates data and keeps minimum supporting services prepared for activation.
Faster recovery for a business-critical workload	Warm standby	Keeps some application capacity running in the recovery Region.
Very low downtime and active service in multiple Regions	Multi-site active-active	Both sites serve traffic and maintain active application capacity.
Millisecond- or second-level data protection	Synchronous replication	Commits wait for confirmation from the second copy.
Cross-Region replication where latency makes synchronous replication impractical	Asynchronous replication	Does not wait for the destination acknowledgment, but may have replication lag.
Periodic point-in-time protection	Snapshots or cloud backups	Suitable for minute-to-hour RPO ranges and restoration workflows.
Active-active multi-Region database writes	DynamoDB global tables	Provides multi-master writes with asynchronous cross-Region replication.
Aurora disaster recovery across Regions	Replicate and promote the secondary when required	The secondary is not a normal active-active writable database.

Common Traps / Misconceptions

RPO is not the time needed to recover. RPO is acceptable data loss; RTO is service restoration time.
A backup does not automatically create a short RTO. The organization must also provision infrastructure, restore data, configure services, and validate the application.
Asynchronous replication is not zero-data-loss replication. The destination may lag behind the source when the failure occurs.
Pilot light is not a fully running standby application. Most application resources are inactive and must be activated or scaled after the disaster.
Warm standby is not the same as active-active. Warm standby has a secondary environment with some running capacity, but normal traffic is not distributed across both sites.
Active-active compute does not guarantee active-active database writes. Aurora and DynamoDB global tables have different cross-Region write behavior.
Multi-AZ and multi-Region are not interchangeable. Availability Zones address localized infrastructure failures; Regions provide greater geographic separation for DR.
Lower RPO and RTO are not free. They usually require more replication, running standby capacity, automation, and operational complexity.

Real-World Engineer / Analyst Notes

Start DR design with business impact analysis: identify the maximum tolerable data loss and downtime for each workload rather than selecting a strategy based only on technology.
Document RPO and RTO per application, including dependencies such as identity, DNS, certificates, databases, queues, and external integrations.
Treat the recovery process as an operational workflow. A design is not complete until the team knows how traffic changes, data is promoted or restored, capacity is activated, and service health is verified.
Test restoration and failover procedures. A snapshot that exists but cannot be restored within the required RTO does not satisfy the business requirement.
Check replication mode and lag during an incident. Asynchronous replication may require identifying the last confirmed recovery point before promoting or restoring a secondary system.
Separate the cost of storing replicated data from the cost of keeping compute resources running. This distinction often explains the cost difference between pilot light, warm standby, and active-active designs.

Quick Reference Summary

RPO: Maximum acceptable data loss, measured backward from the failure to the latest usable recovery point.
RTO: Maximum acceptable time to restore service after the failure.
Synchronous replication: Very low RPO; requires confirmation from the destination and is affected by latency.
Asynchronous replication: Supports longer distances; replication lag can cause data loss.
Backup and restore: Lowest cost, slowest and most manual recovery path.
Pilot light: Replicated data and minimal supporting services; application capacity is activated after failure.
Warm standby: Some application capacity is already running in the recovery Region.
Multi-site active-active: Multiple Regions actively serve traffic; highest cost and lowest expected downtime among these patterns.
DynamoDB global tables: Multi-Region, multi-master active-active writes with asynchronous replication.
Aurora cross-Region recovery: Secondary database requires promotion before serving as the writable database.

Flashcards

Q: A business can tolerate losing no more than 30 minutes of transactions but can tolerate four hours before service is restored. Which objectives are these?

A: The requirement is a 30-minute RPO and a four-hour RTO. RPO describes acceptable data loss; RTO describes acceptable recovery time.

Q: A team wants millisecond- or second-level RPO for a database. Which replication approach should it evaluate first, and what is the tradeoff?

A: Synchronous replication should be evaluated because the second copy confirms storage before the transaction is committed. The tradeoff is sensitivity to latency and distance, along with higher complexity or cost.

Q: When is asynchronous replication preferable to synchronous replication?

A: Use asynchronous replication when replicating over longer distances or when waiting for the remote acknowledgment would introduce unacceptable latency. The tradeoff is possible replication lag and data loss at failure time.

Q: A workload can accept several hours of downtime and is not business-critical. Which DR strategy is the likely fit?

A: Backup and restore is likely appropriate because it has the lowest cost and is designed for workloads that can tolerate provisioning and restoration after the event.

Q: What distinguishes pilot light from backup and restore?

A: Pilot light continuously or periodically replicates critical data and keeps minimum supporting services prepared in another Region. Backup and restore generally waits until the disaster to provision infrastructure and restore the data.

Q: When should warm standby be selected instead of pilot light?

A: Select warm standby when the workload is more business-critical and requires a faster RTO. Some application capacity is already running, so the environment can serve load sooner.

Q: What traffic pattern indicates a multi-site active-active design?

A: Route 53 sends traffic to load balancers in both Regions, with active instances serving in each location. This differs from primary/secondary failover routing.

Q: Why is multi-site active-active the most expensive of the four strategies?

A: It maintains running application environments and capacity in multiple Regions and actively serves traffic from both, rather than keeping the recovery environment mostly inactive.

Q: An application runs active-active across Regions, but its Aurora secondary cannot accept normal writes. What must happen after a disaster?

A: The secondary Aurora database must be promoted before it can serve as the writable database. Active-active application traffic does not imply active-active database writes.

Q: Which AWS database capability supports multi-Region, multi-master active-active writes?

A: DynamoDB global tables support active-active writes across Regions. Replication is asynchronous, so some cross-Region lag remains possible.

Q: What is the operational limitation of relying only on snapshots to meet a short RTO?

A: Snapshots protect recovery points but do not by themselves guarantee rapid service restoration. Infrastructure may still need to be launched, data restored, and dependencies configured and tested.

Q: A company wants cross-Region replication but cannot tolerate synchronous latency over the distance. Which approach is more suitable?

A: Asynchronous replication is more suitable because it does not wait for the destination response. The design must account for replication lag and the resulting RPO.

Q: How do fault tolerance and traditional high availability differ in expected recovery speed?

A: Fault tolerance, such as mirrored disks, can fail over almost immediately and may be unnoticed. Traditional high availability, load balancing, and auto scaling usually recover in seconds to minutes.

Q: What is the key distinction between RPO and the recovery point?

A: The recovery point is the last usable backup or synchronized copy; RPO is the maximum acceptable time gap between that point and the failure. The actual gap at failure determines the data potentially lost.

Practice Questions

Question 1

A financial application must recover in under 15 minutes. Its secondary Region should already have some EC2 capacity running, but the company does not want to pay for a complete duplicate production environment. Which DR strategy best fits?

A. Backup and restore
B. Pilot light
C. Warm standby
D. Multi-site active-active

Correct answer: C. Warm standby

Explanation: Warm standby keeps some application capacity running in the secondary Region, reducing recovery time without the full cost of active-active operation.

Question 2

An organization needs to route production traffic to two Regions at the same time. It also requires a database service that supports multi-Region active-active writes. Which combination best matches the requirement?

A. Route 53 failover routing and an Aurora secondary
B. Route 53 routing to both load balancers and DynamoDB global tables
C. Route 53 latency routing and EBS snapshots only
D. Pilot light and a manually restored database

Correct answer: B. Route 53 routing to both load balancers and DynamoDB global tables

Explanation: Active-active traffic requires both Regional environments to receive traffic, and DynamoDB global tables support multi-master writes across Regions. Their replication is asynchronous.

Question 3

A workload uses asynchronous cross-Region replication. The primary fails while the secondary is several seconds behind. Which statement is correct?

A. The workload has synchronous zero-data-loss protection.
B. The RTO is automatically equal to the replication delay.
C. Some recent data may be lost because the secondary has replication lag.
D. The secondary cannot be used for disaster recovery.

Correct answer: C. Some recent data may be lost because the secondary has replication lag.

Explanation: Asynchronous replication does not wait for the destination acknowledgment. The amount of lag at failure time contributes to potential data loss and therefore affects the achieved RPO.

Question 4

A low-priority application has EBS snapshots stored for recovery. After a Regional disaster, the team must create resources, move or access the snapshots in another Region, restore the data, and start the application. Which strategy and characteristic describe this design?

A. Backup and restore; lowest cost but slower recovery
B. Pilot light; all application instances are already running
C. Warm standby; both Regions actively serve traffic
D. Multi-site active-active; no restoration is required

Correct answer: A. Backup and restore; lowest cost but slower recovery

Explanation: The need to provision resources and restore from snapshots after the event is the defining workflow of backup and restore.

Question 5

An architect proposes using an Aurora secondary as a writable database in both Regions for active-active operation. What is the decisive correction?

A. Aurora requires tape backups before any cross-Region recovery.
B. Aurora secondaries are automatically multi-master.
C. The secondary must be promoted after a disaster before it becomes writable.
D. Aurora cannot be used in a DR architecture.

Correct answer: C. The secondary must be promoted after a disaster before it becomes writable.

Explanation: The lecture distinguishes Aurora from DynamoDB global tables: Aurora does not provide the same active-active multi-Region write behavior, so the secondary must be promoted.

WordPress Metadata

Suggested Slug:
aws-rpo-rto-disaster-recovery-strategies

Meta Description:
Study RPO, RTO, replication techniques, AWS disaster recovery patterns, and the tradeoffs among backup and restore, pilot light, warm standby, and multi-site active-active designs.

Tags:
AWS, SOA-C03, disaster recovery, business continuity, RPO, RTO, backup and restore, pilot light, warm standby, multi-site active-active, data replication, Route 53

AWS RPO, RTO, and Disaster Recovery Strategies for SOA-C03