Selecting an Appropriate DR Strategy to Meet Business Requirements

Designing for disaster recovery (DR) is a balancing act between the cost of the solution and the potential impact of downtime on the business. This guide explores how to align AWS architecture with business metrics like RPO and RTO.

Learning Objectives

• Define and distinguish between Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
• Compare the four primary AWS disaster recovery strategies: Backup & Restore, Pilot Light, Warm Standby, and Multi-site Active-Active.
• Select the most cost-effective DR strategy based on specific business availability requirements.
• Identify key AWS services used to implement resilient architectures (e.g., Route 53, RDS, S3).

Key Terms & Glossary

• Disaster Recovery (DR): The process of restoring IT systems and data after a catastrophic event.
• Recovery Point Objective (RPO): The maximum acceptable amount of data loss measured in time (e.g., "We can lose up to 4 hours of data").
• Recovery Time Objective (RTO): The maximum acceptable delay between service interruption and restoration (e.g., "The system must be back up in 15 minutes").
• Failover: The automatic or manual process of switching to a redundant or standby system upon the failure of the primary system.
• Synchronous Replication: Data is written to the primary and secondary locations simultaneously before the write is confirmed.

The "Big Idea"

Disaster Recovery is not a "one size fits all" solution. It exists on a spectrum of cost vs. speed. At one end, "Backup & Restore" is cheap but slow; at the other, "Multi-site Active-Active" is nearly instantaneous but extremely expensive. Your job as an architect is to find the "Goldilocks zone" where the cost of the DR solution does not exceed the cost of the business loss it is preventing.

Formula / Concept Box

[!TIP] Think of RPO as the "Back-in-time" limit (looking at the past) and RTO as the "Down-time" limit (looking at the future from the point of failure).

Hierarchical Outline

• I. Business Metrics for DR
  • Recovery Point Objective (RPO): Relates to backup frequency.
  • Recovery Time Objective (RTO): Relates to restoration speed.
• II. The Four DR Strategies
  • Backup & Restore: High RPO/RTO. Uses S3 and snapshots.
  • Pilot Light: Medium RPO/RTO. Core data is live; compute is idle (e.g., AMIs ready to boot).
  • Warm Standby: Low RPO/RTO. "Always-on" reduced-capacity version of the environment.
  • Multi-site Active-Active: Zero RPO/RTO. Full traffic split across multiple regions.
• III. AWS Resilience Features
  • Compute: Auto Scaling across multiple AZs.
  • Database: RDS Multi-AZ (High Availability) vs. Cross-Region Read Replicas (DR).
  • Storage: S3 Cross-Region Replication (CRR).

Visual Anchors

The DR Strategy Spectrum

RPO vs. RTO Timeline

\begin{tikzpicture}[scale=1.2, every node/.style={font=\small}] \draw [thick, ->] (0,0) -- (10,0) node[right] {Time}; \draw [red, dashed, thick] (5, -0.5) -- (5, 1.5) node[above] {Disaster Event};

\end{tikzpicture}

Definition-Example Pairs

• Pilot Light: Keeping the "pilot light" burning (databases live) while the rest of the house (compute) is dark until needed.
  • Example: An RDS instance is running in Region B with synchronous replication, but EC2 instances are only started via CloudFormation after a disaster is declared.
• Warm Standby: A scaled-down but fully functional version of your environment.
  • Example: Running a single small EC2 instance and a small RDS instance in a secondary region. When disaster strikes, the Auto Scaling Group scales up the EC2 fleet to handle full traffic.
• Backup & Restore: The most traditional method of restoring from off-site tapes or cloud snapshots.
  • Example: Daily EBS snapshots and RDS snapshots stored in S3. If the region fails, you recreate the entire stack in a new region from these files.

Worked Examples

Scenario: The Cost-Conscious Payroll App

Requirement: A company has a payroll application. Downtime is annoying but not fatal. They want the cheapest possible solution that allows them to recover within 24 hours with no more than 24 hours of data loss.

Analysis:

• RTO: 24 hours
• RPO: 24 hours
• Strategy Selection: Backup & Restore.

Implementation:

1. Storage: Use S3 to store nightly database backups.
2. Automation: Use AWS CloudFormation to define the infrastructure (VPC, EC2, SG) so it can be deployed in a different region if necessary.
3. DNS: Use Route 53 with a manual failover record to point to the new environment once built.

Scenario: The High-Stakes E-commerce Site

Requirement: A global retailer needs to ensure that if a whole AWS Region goes down, customers are redirected instantly with zero data loss.

Analysis:

• RTO: Near-zero
• RPO: Zero
• Strategy Selection: Multi-site Active-Active.

Implementation:

1. Database: Use Amazon Aurora Global Database or DynamoDB Global Tables for multi-region writes.
2. Traffic: Use Route 53 Latency-based Routing to send users to the closest healthy region.
3. Compute: Full-scale application fleets running in two or more regions simultaneously.

Checkpoint Questions

1. What is the main difference between Pilot Light and Warm Standby?
2. If a company requires an RPO of 5 minutes, which AWS database feature should they enable for their RDS instances?
3. Which DR strategy is the most expensive to maintain and why?
4. True or False: RTO measures the amount of data lost during an outage.

▶Click to see answers

1. In Pilot Light, compute resources (EC2) are not running (only the DB is). In Warm Standby, a small, functional version of the compute fleet is always running.
2. Point-in-time recovery (PITR) or synchronous replication (Multi-AZ/Read Replicas).
3. Multi-site Active-Active, because you are paying for two (or more) full-capacity environments running at all times.
4. False. RTO measures the time to recover. RPO measures the data loss.