AWS Backup and Recovery Strategies: Disaster Recovery for DevOps Professionals
AWS Backup and recovery strategies (for example, pilot light, warm standby)
AWS Backup and Recovery Strategies: Disaster Recovery for DevOps Professionals
This guide covers the essential strategies and AWS services required to implement automated recovery processes, focusing on meeting Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements as defined in the DOP-C02 exam.
Learning Objectives
- Define and distinguish between RTO and RPO.
- Compare the four major disaster recovery (DR) strategies: Backup & Restore, Pilot Light, Warm Standby, and Multi-Site Active-Active.
- Configure AWS Backup for automated, cross-region data protection.
- Evaluate the use of RDS Multi-AZ versus Read Replicas for high availability and disaster recovery.
- Understand the role of AWS Elastic Disaster Recovery (DRS) in minimizing downtime.
Key Terms & Glossary
- RTO (Recovery Time Objective): The maximum acceptable delay between the interruption of service and restoration of service. (Target = "How fast?")
- RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. (Target = "How much data?")
- Failover: The process of switching to a redundant or standby computer server, system, hardware component, or network upon the failure of the previously active application.
- Cross-Region Replication (CRR): Automatically copying data across different AWS Regions to ensure durability and availability in case of a regional outage.
- Cold Storage: A tier in AWS Backup used for infrequently accessed data that has lower storage costs but higher retrieval times and costs.
The "Big Idea"
Disaster Recovery in AWS is not a "one size fits all" solution. It is a spectrum of trade-offs between cost and recovery speed. A DevOps Engineer's primary goal is to map business requirements (SLA/RTO/RPO) to the most cost-effective technical architecture that can survive a regional failure.
Formula / Concept Box
| Concept | Metric | Focus |
|---|---|---|
| RTO | Time | Duration of downtime. Aim for minutes/seconds in Hot Standby. |
| RPO | Time (since last backup) | Data age at time of failure. Aim for near-zero in synchronous replication. |
| Cost | $$$ | Increases exponentially as RTO/RPO approach zero. |
Hierarchical Outline
- Foundational Concepts
- Disaster Recovery (DR): Planning for regional or catastrophic failures.
- High Availability (HA): Planning for localized failures (AZ level).
- The Four DR Strategies
- Backup & Restore: Tape/S3 storage, slowest recovery.
- Pilot Light: Core data is live; application infrastructure is "off" but ready to scale.
- Warm Standby: Scaled-down version of the full environment is always running.
- Multi-Site (Hot Standby): Full capacity running in two or more regions simultaneously.
- AWS Services for Recovery
- AWS Backup: Centralized management for RDS, EBS, EFS, and more.
- AWS Elastic Disaster Recovery (DRS): Block-level replication for on-premises or EC2.
- Amazon Route 53: Health checks and DNS failover (Failover Routing Policy).
Visual Anchors
DR Strategy Continuum
RTO and RPO Timeline
Definition-Example Pairs
- Pilot Light: A strategy where you keep a "pilot light" (typically the database) burning in a DR region, but only start application servers during a disaster.
- Example: An e-commerce site replicates its RDS database to another region. In a disaster, an Auto Scaling Group in the DR region triggers, creating EC2 instances from pre-made AMIs.
- Warm Standby: A scaled-down but fully functional version of your environment is always running.
- Example: A fleet of 2 EC2 instances (compared to 10 in production) handles minimal traffic in the DR region; it scales up to 10 immediately if production fails.
- AWS Backup Lifecycle Policy: Automatically moving backups from warm to cold storage after a set period.
- Example: Moving EBS snapshots to cold storage after 30 days to save 80% on storage costs while keeping them for compliance for 7 years.
Comparison Tables
| Strategy | RTO | RPO | Cost | Complexity |
|---|---|---|---|---|
| Backup & Restore | Hours | 24 Hours+ | Lowest | Low |
| Pilot Light | 10s of Minutes | Minutes | Low-Medium | Medium |
| Warm Standby | Minutes | Seconds/Minutes | Medium-High | High |
| Multi-Site | Near Zero | Zero | Highest | Very High |
Worked Examples
Scenario: Configuring Cross-Region RDS Recovery
Requirement: A DevOps engineer needs to ensure an RDS MySQL database can be recovered in a second region with an RTO of < 15 minutes and an RPO of < 5 minutes.
Solution Steps:
- Option A (Read Replica): Create a Cross-Region Read Replica.
- Pros: Asynchronous replication provides near-zero RPO. Promotion to primary takes minutes (RTO).
- Cons: Higher cost as the DB instance is always running.
- Option B (AWS Backup): Configure an AWS Backup Plan with a copy job to the destination region.
- Pros: Cheaper than a running instance.
- Cons: Restoring a large snapshot to a new instance might exceed the 15-minute RTO.
[!TIP] For the DOP-C02 exam, if RTO is the priority, Read Replicas or Global Datatabases (Aurora) are the preferred answers over snapshots.
Checkpoint Questions
- What is the main difference between RDS Multi-AZ and a Read Replica in terms of DR?
- In a "Pilot Light" strategy, which component is usually kept running and synchronized?
- How does AWS Elastic Disaster Recovery (DRS) replicate data from a source server?
- What Route 53 routing policy is used to switch traffic between regions during a failure?
Muddy Points & Cross-Refs
- Multi-AZ vs. Multi-Region: Students often confuse these. Multi-AZ is for High Availability (data center failure). Multi-Region is for Disaster Recovery (entire geographic area failure).
- Snapshots vs. Backups: Amazon RDS has built-in automated backups (max 35 days). AWS Backup allows for longer retention (years) and cross-account/cross-region management, making it the choice for complex compliance.
- Cross-Region Read Replica Promotion: Remember that once an RDS Read Replica is promoted to a standalone instance, the replication link is broken. You must manually point your application to the new endpoint.