AWS Cloud Practitioner Study Notes · Part 66
AWS Disaster Recovery Strategies: RTO, RPO, and the Four Recovery Patterns
Detailed AWS Cloud Practitioner study notes explaining RTO, RPO, backup and restore, pilot light, warm standby, and active-active DR.
Disaster recovery (DR) is the plan and architecture used to restore a workload after a serious disruption. The correct AWS DR strategy is not automatically the most expensive or the most highly available design. It is the design that meets the business’s acceptable downtime and data-loss objectives at a justifiable cost.
The two numbers that drive the decision are:
RTO → How quickly must the service be restored?
RPO → How much data loss can the business accept?AWS commonly describes four cloud disaster-recovery strategies, from lower cost and slower recovery to higher cost and faster recovery:
Backup and restore
↓
Pilot light
↓
Warm standby
↓
Multi-site active/activeThis is Part 66 of the AWS Cloud Practitioner Study Notes. Part 31 covers database backups, while this article focuses on the broader recovery architecture for applications, infrastructure, and data.
Disaster recovery versus high availability
These ideas are related but not identical.
High availability (HA) is about keeping a workload operating through ordinary component failures, such as an instance failure, an Availability Zone problem, or a temporary software fault. A multi-AZ deployment, load balancer, and automatic scaling are common HA techniques.
Disaster recovery is about restoring a workload after a major event that seriously affects the running environment. Examples include a Region-wide disruption, a large-scale infrastructure failure, accidental deletion, ransomware, a destructive deployment, or a serious human error.
Availability → keep serving through expected component failures
Disaster recovery → recover after a serious disruptive eventA highly available application can still need DR. For example, a multi-AZ database may survive an Availability Zone failure, but it does not by itself protect against corrupted data, an incorrectly executed delete command, or a Region-level disaster. Backups, replication, isolation, and tested recovery procedures address those cases.
RTO: Recovery Time Objective
Recovery Time Objective (RTO) is the maximum acceptable delay between service interruption and restoration of service.
If a business has an RTO of two hours, the recovery plan must restore the workload within two hours of the defined disaster event. RTO is about downtime.
Disaster occurs ──────────────── Service restored
←──── RTO ────→RTO includes more than starting a server. It may include:
- Declaring the incident and approving failover
- Provisioning or scaling recovery infrastructure
- Restoring or promoting databases
- Restoring application configuration and secrets
- Updating DNS or traffic routing
- Validating authentication, integrations, and data
- Confirming that users can safely access the service
An architecture that can start EC2 instances in ten minutes may still miss a one-hour RTO if database recovery, DNS changes, dependency recovery, and validation take another two hours.
RPO: Recovery Point Objective
Recovery Point Objective (RPO) is the maximum acceptable time since the last recoverable data point. It describes the maximum potential data loss measured backwards from the disaster.
If the RPO is one hour, the organisation accepts that the recovered system may be missing up to one hour of data, depending on the last successful backup or replication point. RPO is about data loss or data staleness.
Last recoverable copy ───────── Disaster occurs
←──── RPO ────→
Possible lost changesExamples:
| Requirement | Meaning |
|---|---|
| RPO = 24 hours | Daily backups may be acceptable if they complete reliably |
| RPO = 1 hour | Backups or replication must provide a recovery point at least hourly |
| RPO = minutes | Continuous or frequent replication is usually needed |
| Near-zero RPO | Very little data loss is acceptable; synchronous or near-continuous replication may be required |
RPO is not the same as backup retention. Retention answers “how long do we keep recovery points?” RPO answers “how much recent data can we lose?”
RTO and RPO choose the strategy
The business should define RTO and RPO based on revenue impact, customer impact, safety, regulatory obligations, recovery dependencies, and the cost of downtime or data loss. The technical team then chooses an architecture that can meet those objectives.
Do not choose arbitrary objectives such as “zero downtime” or “zero data loss” without checking whether the workload and budget can support them. A target that is more demanding than the business actually needs can create unnecessary complexity and cost.
Strategy comparison
| Strategy | Recovery environment | Typical recovery speed | Typical data approach | Relative cost | Complexity |
|---|---|---|---|---|---|
| Backup and restore | Mostly created during recovery | Slowest | Backups and snapshots | Lowest | Lowest |
| Pilot light | Core data and minimal recovery components ready | Faster than backup and restore | Data continuously or frequently replicated | Low to medium | Medium |
| Warm standby | Smaller but functional environment always running | Fast | Replicated data and ready application stack | Medium to high | High |
| Multi-site active/active | Full environments serving traffic simultaneously | Fastest | Replicated or distributed data | Highest | Highest |
The exact RTO and RPO depend on the workload, AWS services, automation, data volume, network, and testing. These labels are patterns, not guaranteed service-level numbers.
1. Backup and restore
Backup and restore keeps recoverable copies of data and configuration, then creates or restores the workload in a recovery environment after a disaster.
Primary workload
↓ scheduled backups / snapshots
Amazon S3, backup vault, database backup, or archive
↓ disaster
Create infrastructure → restore data → deploy application → test → route trafficWhat is prepared in advance?
- Automated backups, snapshots, or point-in-time recovery
- Backup retention and lifecycle policies
- Copies stored in a separate account or Region when required
- Infrastructure as Code for the recovery environment
- Application packages, container images, and deployment pipelines
- Documented recovery runbooks
- IAM roles, encryption keys, DNS records, and configuration procedures
The recovery environment may not be running before the disaster. Compute, databases, networking components, and application services may need to be provisioned or restored during the recovery process.
Example
A low-criticality reporting application takes daily database backups and stores application artifacts in Amazon S3. If the Region is lost, the team provisions the network and compute resources with CloudFormation or Terraform, restores the latest database backup, deploys the application, validates it, and updates DNS.
Benefits
- Lowest ongoing cost of the four strategies
- Simple operating model for less critical workloads
- Backups can protect against accidental deletion and data corruption
- A good fit when the business can tolerate longer recovery
- Recovery copies can be isolated from the production environment
Trade-offs
- Slowest RTO because infrastructure and data must be restored
- RPO depends on backup frequency and successful completion
- Recovery capacity may not exist until the event occurs
- Large databases can take a long time to restore and validate
- Untested backups may be unusable or incomplete
- Configuration, dependencies, and secrets can be forgotten even when data is backed up
Best fit
Choose backup and restore when the workload has a relatively relaxed RTO and RPO, the cost of a continuously running DR environment is not justified, or the main recovery requirement is protection from data loss and accidental deletion.
Exam clue
“Lowest cost”, “periodic backups”, “restore resources after a disaster”, or “longer recovery time is acceptable” usually means backup and restore.
2. Pilot light
Pilot light keeps the core data and the minimum required foundation running in the recovery Region, while the application and non-essential resources remain switched off or are created during failover.
The name comes from a small flame that remains lit and can be used to start a larger fire. In cloud terms, the database or replicated data is ready, but the full application stack is not serving normal traffic.
Primary Region DR Region
Application: running Core data: replicated and ready
Database: active Network: prepared
Application: stopped or minimalWhat is prepared in advance?
- A VPC, subnets, routing, security controls, and IAM foundations
- A replicated database or continuously updated data store
- Application images, packages, and infrastructure definitions
- Monitoring, logging, and recovery automation
- A way to start or scale the application stack quickly
During failover, the team activates the application servers, deploys or scales required services, promotes or connects to the recovery database, and redirects traffic.
Example
A web application replicates its database to a second Region. The DR Region contains the VPC and deployment configuration, but the application fleet is stopped to reduce cost. When the primary Region fails, automation launches the application tier, scales it, validates the database, and moves Route 53 traffic to the DR endpoint.
Benefits
- Faster recovery than restoring everything from backups
- Lower cost than keeping a complete application environment running
- Data is already available or close to available
- Infrastructure can be automated and tested without serving production traffic
Trade-offs
- Recovery still requires an activation and scale-up step
- The application tier may have configuration drift if it is not deployed regularly
- The database replication method determines the achievable RPO
- Capacity, quotas, images, secrets, certificates, and dependencies must be ready
- Failover runbooks must be fast and reliable
Pilot light versus backup and restore
Backup and restore starts with recovery points and creates most of the environment after the disaster. Pilot light keeps core recovery components, especially data, available before the disaster. That preparation reduces recovery time but costs more and requires more operational discipline.
Best fit
Choose pilot light when the workload needs a better RTO than backup and restore but does not justify a full, continuously running secondary environment.
Exam clue
“Core data is continuously replicated, while application servers are activated during recovery” indicates pilot light.
3. Warm standby
Warm standby maintains a scaled-down but fully functional copy of the production workload in another Region. The recovery environment is already running and can serve traffic, although it may not initially have the same capacity as the primary environment.
Primary Region DR Region
Full capacity: serving traffic Reduced capacity: serving or ready
Database: active Database: replicated
Application: active Application: active at smaller scaleDuring a disaster, the team redirects traffic and scales the warm standby environment to the required capacity. Unlike pilot light, it does not need to start the entire application stack before it can process requests.
Example
A production API runs with ten application instances in Region A. Region B continuously runs two instances, has the application deployed, and maintains a replicated database. Route 53 health checks detect the failure, traffic is redirected, and the Region B Auto Scaling group increases capacity.
Benefits
- Faster recovery than pilot light
- The application can be tested in the DR Region more realistically
- Less activation work during a stressful incident
- The recovery site can often serve limited traffic before full scaling
- Continuous testing is easier because the environment is already functional
Trade-offs
- Higher ongoing cost because compute and other resources are always running
- The scaled-down environment may not have enough capacity immediately
- Capacity quotas, database throughput, licenses, and third-party dependencies must support failover
- Configuration drift can still occur between Regions
- Data replication and traffic routing remain complex
Pilot light versus warm standby
This distinction is frequently tested:
| Question | Pilot light | Warm standby |
|---|---|---|
| Is core data ready? | Yes | Yes |
| Is the full application environment running? | No, or only minimally | Yes, at reduced scale |
| What happens during recovery? | Turn on or deploy resources, then scale | Scale up and redirect traffic |
| Ongoing cost | Lower | Higher |
| Recovery speed | Faster than backup and restore | Faster than pilot light |
If the DR application cannot process requests until servers are started, it is pilot light. If the reduced application environment is already running and functional, it is warm standby.
Best fit
Choose warm standby when the business needs minutes-level recovery, can afford a continuously running reduced environment, and wants a practical balance between recovery speed and the cost of active/active infrastructure.
4. Multi-site active/active
Multi-site active/active runs complete production environments in two or more Regions, and all of them serve traffic during normal operation. If one Region fails, traffic is reduced or redirected to the healthy Regions.
Users
├── Region A: full application, serving traffic
└── Region B: full application, serving trafficTraffic can be distributed with services such as Amazon Route 53 or AWS Global Accelerator. The application and data architecture must support multi-Region operation, including traffic routing, identity, deployment, data replication, conflict handling, and operational ownership.
Example
A global application deploys the same service stack in two Regions. Route 53 latency or geolocation routing sends users to a suitable Region. Data is replicated using a design appropriate to the database. If Region A fails, health checks remove it from routing and Region B continues serving users.
Benefits
- Fastest recovery potential
- Both Regions provide business value during normal operation
- Capacity is already active rather than waiting for restoration
- Can improve global latency and geographic resilience
- No large traffic pause is required if the architecture supports automatic routing
Trade-offs
- Highest infrastructure and operational cost
- Most complex data consistency and conflict-resolution design
- More difficult deployments, observability, incident response, and security management
- A bug, bad deployment, or corrupted write can replicate to every active Region
- “Near-zero RTO” does not guarantee zero data loss, especially after data corruption or human error
Active/active versus hot standby
Both may have a complete secondary environment, but they do not use it in the same way:
- Multi-site active/active: multiple Regions serve traffic simultaneously.
- Hot standby active/passive: one Region serves traffic and the other is fully ready but does not normally serve production traffic.
The AWS four-strategy comparison usually calls the highest pattern multi-site active/active. A fully running passive environment is often described as hot standby in more detailed architectures.
Best fit
Choose multi-site active/active when the business requires extremely fast recovery, the service is globally important, and the organisation can operate the complexity and cost of multiple production Regions.
Exam clue
“Full environments in multiple Regions serve traffic at the same time” means multi-site active/active.
Data protection is the foundation of DR
The application can only recover to the state represented by its available data. A DR plan should define:
- What data must be backed up
- How frequently backups or replication occur
- Where recovery copies are stored
- How long recovery points are retained
- How encryption keys are protected and recovered
- How backup integrity is verified
- How corrupted or deleted data is isolated from replication
- How the application handles partially completed transactions
Common AWS building blocks include Amazon S3 versioning and replication, AWS Backup, database snapshots and point-in-time recovery, cross-Region database replication, Amazon EBS snapshots, and application-specific replication. The exact choice depends on the service and the required RPO.
Replication is not a complete substitute for backups. If an operator deletes data or a malicious change is replicated, the secondary copy may also be damaged. Backups, immutability, retention, isolation, and point-in-time recovery help address those failure modes.
Recovery dependencies people often forget
Recovering the database and EC2 instances is not enough. A realistic DR plan includes:
- DNS, routing, health checks, and certificates
- VPCs, subnets, route tables, NAT, and security controls
- IAM roles, permissions, and emergency access
- Secrets Manager secrets and encryption keys
- Container images, packages, and artefact repositories
- Queues, event buses, scheduled jobs, and workflow state
- Third-party APIs and allowlists
- Observability, dashboards, alerts, and log access
- Customer identity and authentication providers
- Quotas, service limits, licences, and reserved capacity
- Data pipelines and downstream reporting systems
A dependency that cannot operate in the DR Region can become the real RTO bottleneck. Map the full workload rather than only the compute layer.
Failover, recovery, and failback
These terms describe different stages:
- Failover: move production traffic or operation from the primary environment to the recovery environment.
- Recovery: restore the workload and its data to the agreed operating state.
- Failback: move the workload back to the original environment after it is repaired and safe.
A failover runbook should define who can declare a disaster, which signals trigger recovery, how data replication is handled, how writes are stopped or redirected, how traffic moves, how users are informed, and how success is verified.
Failback can be harder than failover. The recovery Region may have accepted new writes while the primary was unavailable. Before moving back, the team must reconcile or replicate those changes, validate the original environment, and plan a controlled traffic transition.
Testing the DR strategy
A DR plan that has never been tested is an assumption. AWS recommends regularly testing failover to verify that the recovery environment works and that the actual RTO and RPO are achievable.
Useful tests include:
- Restore a backup into an isolated environment.
- Launch pilot-light resources and measure activation time.
- Scale a warm standby to expected failover capacity.
- Exercise DNS or Global Accelerator traffic changes.
- Test database promotion and application connection changes.
- Validate secrets, certificates, IAM, queues, and third-party integrations.
- Run a game day with the people who would respond to the incident.
- Test rollback and failback, not only the initial failover.
Measure the results rather than recording only “test passed”:
Actual RTO = incident start to validated service restoration
Actual RPO = disaster time minus newest recoverable valid dataAlso test configuration drift. A recovery Region that was correct six months ago may no longer contain the current application version, permissions, infrastructure, or network rules.
A practical strategy-selection process
Use this sequence for each workload:
Step 1: Classify the business impact
Identify whether the workload is mission-critical, important, or low-criticality. Estimate the effect of downtime, stale data, permanent data loss, and an incorrect recovery.
Step 2: Define RTO and RPO
Ask the business for maximum acceptable downtime and data loss. Document the assumptions and dependencies. Do not let the infrastructure design invent the business requirement.
Step 3: Identify the disaster scope
Is the concern an instance, Availability Zone, Region, account, data corruption, accidental deletion, ransomware, or a full data-centre loss? A multi-AZ design may address one scope, while a cross-Region DR design addresses another.
Step 4: Select the least complex strategy that meets the objectives
Relaxed RTO/RPO → Backup and restore
Improved RTO → Pilot light
Minutes-level → Warm standby
Near-zero RTO → Multi-site active/activeStep 5: Automate and document recovery
Use Infrastructure as Code, deployment pipelines, runbooks, health checks, monitoring, and repeatable data recovery procedures. Manual steps increase recovery time and the chance of error.
Step 6: Test and revise
Compare measured RTO and RPO with the targets. Fix gaps, update the runbook, and repeat the exercise after significant application or infrastructure changes.
Exam comparison and memory trick
| Requirement in the question | Likely answer |
|---|---|
| Cheapest DR option; backups restored after disaster | Backup and restore |
| Data replicated, application servers activated during recovery | Pilot light |
| Smaller functional application environment already running | Warm standby |
| Complete environments in multiple Regions serve traffic | Multi-site active/active |
| Maximum acceptable downtime | RTO |
| Maximum acceptable data-loss window | RPO |
| Keep a recovery plan accurate by exercising it | Test failover regularly |
| Remove a Region from user traffic | Route 53 health checks or Global Accelerator, depending on design |
RTO = Time to recover
RPO = Point in time to recover from
Backup/restore → restore
Pilot light → start
Warm standby → scale
Active/active → continueThe final answer to remember is: define business RTO and RPO first, then choose the simplest DR strategy that meets them. Backup and restore costs the least but recovers slowest. Pilot light keeps core data and foundations ready. Warm standby keeps a reduced working environment running. Multi-site active/active runs complete environments simultaneously and can recover fastest, but costs and operates the most.