Disaster Recovery (DR) and Business Continuity Planning (BCP) are the safety nets that keep a company's IT systems running when something catastrophic happens—a cloud region goes dark, a data centre floods, or a ransomware attack locks every file. For the AWS Certified Solutions Architect Professional exam (SAP-C02), you must design these strategies to meet strict time and data loss targets, because architects are the ones who decide exactly how and when a business gets back online.
Jump to a section
A simple way to picture Disaster Recovery and Business Continuity Planning
A busy restaurant kitchen on a Friday night. Orders are flying in, pans are sizzling, and the head chef is orchestrating the chaos. Suddenly, the main gas line to the stove ruptures with a loud hiss. The flames die.
Disaster Recovery (DR) is what the kitchen team does right after the gas line breaks: they switch to the backup propane tanks stored in the alley, fire up the portable burners, and keep cooking the steaks. They recover the ability to cook. Business Continuity Planning (BCP) is what the restaurant owner did months earlier: they installed a secondary gas line from a different street main, trained two sous-chefs to run the kitchen if the head chef is sick, and stored a copy of every recipe and supplier contact in a fireproof safe off-site. BCP ensures the restaurant stays open even when disaster strikes.
The RPO (Recovery Point Objective) is how much cooked food the kitchen is willing to lose: if the gas cuts out for 30 minutes, they can re-fire the orders within that window, but any steak held for an hour is wasted. The RTO (Recovery Time Objective) is how fast they need to get the backup burners lit: if the grill is down for more than 15 minutes, diners walk out. The kitchen practises this by running a surprise fire drill every quarter, so every line cook knows exactly where the propane valves are. This real-world drill maps to AWS's concept of “game days” for testing your DR plan.
Disaster Recovery (DR) is the set of technical actions you take to restore IT infrastructure and data after a disaster. Business Continuity Planning (BCP) is the broader business plan that includes DR but also covers people, processes, physical locations, and communications to keep the entire organisation running. In AWS, you design DR and BCP using global infrastructure that spans multiple geographic regions.
Let's define the core terms you must know for SAP-C02:
Recovery Point Objective (RPO): The maximum acceptable amount of data loss measured in time. If your RPO is 15 minutes, you can lose at most 15 minutes of data. This determines how often you take backups or replicate data.
Recovery Time Objective (RTO): The maximum acceptable time to restore service after a disaster. If your RTO is 1 hour, your systems must be fully operational within 60 minutes of the incident.
AWS offers several DR patterns, each with different RPO/RTO characteristics. These are called DR strategies, and they form a spectrum from slow and cheap to fast and expensive:
Backup and Restore: You periodically back up data to Amazon S3 (Simple Storage Service). When disaster hits, you restore from those backups into new infrastructure. RPO is typically hours (depending on backup frequency). RTO is hours to days because you must provision servers, install software, and load data. This is the cheapest strategy.
Pilot Light: You run a minimal version of your core infrastructure—a small “pilot light” environment—in another Region. You replicate critical data continuously. When disaster strikes, you “turn on” the full-scale environment by scaling up the pilot light environment. RPO can be minutes (if you use synchronous replication). RTO is typically tens of minutes to hours.
Warm Standby: You run a scaled-down but fully functional copy of your production environment in another Region. It’s always running, just at lower capacity. When disaster hits, you scale it up to full production size. RPO is minutes. RTO is minutes to tens of minutes.
Multi-Site Active/Active: You run your full production workload in two or more Regions simultaneously, with traffic load-balanced across them. Both sites handle traffic all the time. If one Region fails, traffic is redirected to the remaining healthy Regions. RPO is near zero (seconds, using synchronous replication like Amazon Aurora Global Database). RTO is near zero (seconds to minutes, because DNS and load balancers redirect traffic automatically). This is the most expensive strategy.
Why do multiple patterns exist? Because faster recovery costs more money. Business leaders choose the pattern that best fits the value of the data and the cost of downtime. A bank processing credit cards needs near-zero RPO and RTO. A blog about gardening can accept hours of downtime.
AWS provides tools to implement each pattern:
AWS Backup for centralised backup management.
Amazon S3 and S3 Glacier for storage tiers.
AWS Database Migration Service (DMS) for continuous replication.
Amazon Route 53 for DNS failover routing traffic to healthy Regions.
AWS Elastic Disaster Recovery (AWS DRS) for automated replication of entire servers.
AWS CloudFormation or Terraform for spinning up infrastructure code quickly.
Amazon RDS Multi-AZ and Amazon Aurora Global Database for database failover.
The exam tests your ability to select the correct DR pattern and tool given specific RPO and RTO requirements, budget constraints, and application architecture. You also need to know how to automate failover and failback (returning to the primary site after the disaster is resolved).
Finally, BCP extends beyond IT: it includes a business impact analysis (BIA) to identify critical functions, a crisis communication plan, and regular testing. AWS Well-Architected Framework includes a Reliability pillar with a “Disaster Recovery” question that asks: “How do you plan for disaster recovery?” You must define backup strategy, DR strategy, and test your plan. The exam expects you to recognise that DR is not just about backup—it's about orchestrating the whole recovery process with minimal human intervention.
Define Business Requirements
Work with stakeholders to determine the acceptable RPO (data loss) and RTO (downtime) for each application. Also document budget constraints and compliance needs. This step sets the design targets for your DR strategy.
Assess Application Architecture
Analyse which components (compute, database, storage, networking, dependencies) need to be recovered. Identify single points of failure. For example, a monolithic app may be harder to replicate than microservices. This step determines which DR pattern is feasible.
Select the DR Strategy
Based on RPO/RTO and architecture, choose one of the four patterns: Backup and Restore, Pilot Light, Warm Standby, or Multi-Site Active/Active. For example, if RTO is 1 hour, Pilot Light may not suffice; choose Warm Standby.
Implement Data Replication
Set up continuous replication for databases (e.g., Amazon Aurora Global Database) or servers (e.g., AWS DRS) to the DR Region. For object storage, enable S3 Cross-Region Replication. This ensures the DR site has up-to-date data when disaster strikes.
Automate Failover and Failback
Configure Route 53 health checks to detect region failure and automatically update DNS records. Use AWS Lambda and Systems Manager Automation to orchestrate database promotion and scaling. Document failback steps to return to the primary site after the disaster is resolved.
Test the DR Plan Regularly
Schedule quarterly game days where you simulate a region outage and execute the failover process. Measure actual RPO and RTO against targets. Fix any issues found—stale automation, expired credentials, or missing permissions. Testing prevents surprises during real disasters.
Imagine you are a Solutions Architect at “FinFlow,” a fintech startup that processes mobile payments. FinFlow’s production environment runs on Amazon EC2 instances behind an Application Load Balancer in the US East (N. Virginia) Region. They use Amazon RDS for PostgreSQL as the primary database. The CEO demands: “We cannot lose more than 5 seconds of transactions, and we must be back online within 2 minutes if Virginia goes down.”
You, as the architect, must design a DR strategy meeting these strict RPO (5 seconds) and RTO (2 minutes) requirements. You immediately rule out Backup and Restore because it cannot meet RTO. You also rule out Pilot Light because provisioning takes longer than 2 minutes. Multi-Site Active/Active appears to be the only feasible pattern.
You design the following:
Deploy identical infrastructure in US West (Oregon) Region: EC2 instances, load balancer, and RDS database.
Use Amazon Aurora Global Database for the relational data. Aurora Global Database replicates data asynchronously from the primary Region to up to five secondary Regions with an average lag of less than 1 second—meeting the 5-second RPO.
Use Amazon Route 53 with a weighted routing policy or latency-based routing to distribute traffic 50% to Virginia and 50% to Oregon. Configure health checks so that if Virginia becomes unhealthy, Route 53 automatically sends 100% of traffic to Oregon.
Store static assets and user uploads in Amazon S3, which is already globally durable. Use S3 Cross-Region Replication (CRR) to copy objects to a bucket in Oregon for even lower latency.
Use AWS Global Accelerator to shift traffic in seconds if an endpoint fails.
Automate the entire failover process using AWS Lambda functions and AWS Systems Manager Automation runbooks so that no manual steps are needed. The goal is that from the moment Virginia is detected unhealthy, the failover to Oregon completes in under 2 minutes.
Step by step, what happens during a disaster:
Health check failure: Route 53 health checks detect that the Virginia load balancer is unreachable for three consecutive checks (15 seconds).
Traffic redirection: Route 53 automatically changes DNS records to point all traffic to Oregon. Global Accelerator also shifts traffic.
Database failover: Amazon Aurora Global Database promotes the Oregon cluster to become the new primary. This takes about 60-90 seconds.
Application scaling: The Oregon Auto Scaling group, which was running at minimum capacity, scales up to handle the full load. This happens within minutes, but because warm standby was already running, the scaling is quick.
Failback: Once Virginia is restored, you perform a reverse failback operation: promote Virginia back to primary and shift traffic back. This is orchestrated manually in a controlled window to avoid split-brain scenarios.
Your team also creates a business continuity plan: a crisis communication email list, a runbook for failover steps (even though most are automated), and quarterly “game day” drills where you simulate a Region outage and test the whole process. The CEO is happy because downtime is <2 minutes and data loss is <1 second.
The SAP-C02 exam will test Disaster Recovery and Business Continuity Planning extensively. Expect to see these question types:
Scenario-based questions: You are given a company’s RPO, RTO, budget, and application type (e.g., monolithic vs microservices, relational vs NoSQL database). You must choose the correct DR strategy (Backup and Restore, Pilot Light, Warm Standby, Multi-Site Active/Active) and the specific AWS services needed.
Comparison questions: They ask you to compare two DR strategies for a given requirement. For example, “Which strategy minimises RTO while keeping costs low?”
AWS service selection: You must know which service does what—e.g., AWS DRS for server replication vs. Amazon S3 CRR for object replication vs. Aurora Global Database for database replication.
traps the exam sets:
They give you tight RPO/RTO but a low budget. You must recognise that Multi-Site Active/Active is the only solution that meets sub-minute RPO/RTO, but it is expensive. If the budget is low, you must point that out or propose a hybrid approach.
They ask about “pilot light” but describe “warm standby”. The difference: pilot light has just the core data and a tiny compute footprint (like a database and a few EC2 instances running minimal software); warm standby has a scaled-down but complete copy of the production environment.
They confuse RPO and RTO. Remember: RPO is about data loss (backup frequency), RTO is about downtime (restoration speed).
They mention “synchronous replication” with a global database across Regions. But synchronous replication across long distances introduces latency and is only practical for specific databases, not all workloads.
Key exam concepts to memorise:
The four DR strategies and their typical RPO/RTO ranges.
The specific AWS services for each strategy.
How to use Route 53 health checks and failover routing.
How to automate DR with AWS CloudFormation, Lambda, and Systems Manager.
The difference between disaster recovery and high availability: high availability handles single-component failures (e.g., an instance crashes); DR handles region-wide failures.
The concept of “failback” and how to return to the primary site without data loss.
The AWS Well-Architected Framework Reliability pillar’s DR questions.
Common question patterns:
“A company needs RTO of 1 hour and RPO of 15 minutes. Which strategy should they use?” Answer: Warm standby (Pilot Light may not meet RTO; Backup and Restore cannot meet RPO).
“Which AWS service enables automated failover for an on-premises server to the cloud?” Answer: AWS Elastic Disaster Recovery (AWS DRS).
“What is the minimum RPO achievable with Amazon RDS Multi-AZ in a single Region?” Answer: Near zero (synchronous replication to standby instance). But this is HA, not DR. The exam will test that distinction.
“You need to replicate data to another Region with less than 1 second lag. Which service supports this?” Answer: Amazon Aurora Global Database.
Finally, expect questions that combine DR with other topics like migration, security, and cost optimisation. For example, they might ask how to encrypt data at rest during replication (use AWS KMS with multi-Region keys).
Disaster Recovery (DR) restores IT systems after a disaster; Business Continuity Planning (BCP) keeps the entire organisation running.
Recovery Point Objective (RPO) defines maximum acceptable data loss in time; Recovery Time Objective (RTO) defines maximum acceptable downtime.
The four AWS DR strategies are Backup and Restore (cheapest, slowest), Pilot Light, Warm Standby, and Multi-Site Active/Active (fastest, most expensive).
Near-zero RPO requires continuous replication (e.g., Amazon Aurora Global Database or AWS DRS), not periodic backups.
Manual failover processes are too slow for low RTOs; automate failover with Route 53 health checks, Lambda, and CloudFormation.
Always test your DR plan with regular drills to catch hidden failures before a real disaster occurs.
For relational databases, Amazon RDS Multi-AZ provides high availability (single-Region), not disaster recovery (cross-Region).
AWS Elastic Disaster Recovery (AWS DRS) can replicate on-premises physical or virtual servers to AWS for DR.
Route 53 can route traffic away from an unhealthy Region using health checks and failover routing policies.
Cost optimisation in DR means choosing the pattern that meets RPO/RTO without overspending on resources you rarely use.
These come up on the exam all the time. Here's how to tell them apart.
Backup and Restore
RPO is typically hours (depends on backup schedule).
RTO is hours to days (provision new infrastructure from scratch).
Lowest cost; only pay for backup storage and occasional restore.
Pilot Light
RPO is minutes (continuous replication of critical data).
RTO is tens of minutes to hours (scale up minimal pre-existing environment).
Medium cost; pay for the pilot light environment and replication.
Pilot Light
Runs only core data (e.g., database) and a few small servers.
RTO can be >30 minutes because you must provision missing components.
Cheaper than Warm Standby because less compute runs continuously.
Warm Standby
Runs a scaled-down but complete copy of production environment.
RTO is typically minutes to 30 minutes (scale up existing resources).
More expensive because you pay for the scaled-down environment 24/7.
Warm Standby
One Region is primary, the other is standby (takes no traffic normally).
RTO: minutes to 30 minutes after failover triggers.
Lower cost than Active/Active because standby runs at low capacity.
Multi-Site Active/Active
Both Regions handle traffic simultaneously (load balanced).
RTO: near zero (seconds) because failover is just DNS/lb change.
Highest cost because you pay for full production capacity in two Regions.
Mistake
Disaster Recovery and Business Continuity Planning are the same thing.
Correct
DR is the technical recovery of IT systems, while BCP covers the entire organisation (people, processes, facilities, communications). BCP includes DR but is broader.
The terms are often used interchangeably in casual conversation, but the exam distinguishes them clearly. Beginners assume DR is enough to keep the business running.
Mistake
If you have backups, you have a disaster recovery plan.
Correct
Backups are just part of DR. A complete DR plan includes restoring from backups, provisioning new infrastructure, networking, security, testing, and automation. Without the other steps, backups alone don't guarantee recovery within RTO.
People equate 'backup' with 'recovery' because that's how personal data works (e.g., phone backup). At enterprise scale, recovery is far more complex.
Mistake
Multi-Site Active/Active is always the best DR strategy because it has the lowest RPO and RTO.
Correct
It is the fastest but most expensive. Many applications do not justify the cost. The best strategy depends on business requirements—RPO, RTO, budget, and application architecture.
Beginners see 'fastest' as 'best' without considering cost. The exam tests your ability to balance cost and performance.
Mistake
Synchronous replication across AWS Regions is always possible and recommended for databases.
Correct
Synchronous replication over long distances introduces high latency (network round-trip time). It is only feasible for specific databases like Amazon Aurora Global Database, and even there it's asynchronous (lag <1 second). True synchronous replication across Regions would break performance.
People think 'real-time replication' means synchronous. In practice, cross-Region replication is always asynchronous to avoid latency penalties.
Mistake
You can achieve zero RPO by taking frequent backups.
Correct
Zero RPO means no data loss. Backups are point-in-time snapshots, so there is always a gap (the time between the last backup and the disaster). To get near-zero RPO, you need continuous replication, not periodic backups.
The word 'backup' implies a copy, but backups have intervals. Beginners think 'frequent = zero', but only streaming replication can approach zero loss.
Mistake
Once you set up DR, it will work automatically without testing.
Correct
DR plans must be tested regularly through drills or 'game days'. Without testing, you discover broken automation, missing permissions, or outdated configurations at the worst possible time.
Setting up DR is like buying a fire extinguisher—you need to check it works. Beginners assume 'configured once, works forever', but cloud environments change frequently.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
High Availability (HA) keeps the system running through single-component failures (like an EC2 instance or database node crashing). Disaster Recovery (DR) is for larger-scale events like an entire AWS Region going down. HA is local redundancy; DR is geographic redundancy.
Pilot Light runs only the core data and a minimal compute footprint—a database and a few small servers. Warm Standby runs a scaled-down but full copy of your production environment. If your RTO is less than 30 minutes, go with Warm Standby. If you can tolerate an hour or more, Pilot Light is cheaper.
No. Amazon RDS Multi-AZ provides automatic failover to a standby in a different Availability Zone within the same Region. For cross-Region DR, use Amazon RDS Cross-Region Read Replicas or Amazon Aurora Global Database.
AWS DRS is a service that continuously replicates servers (physical or virtual) from your on-premises data centre or another cloud to AWS. When disaster strikes, you launch the replicated servers in AWS within minutes. It supports both failover and failback.
At least once per quarter for critical applications. More frequent testing (monthly) is better for systems with strict RTOs. Always test after significant changes to the application or infrastructure. AWS recommends 'game days'—simulated failure events.
Failback is the process of returning your workload to the original primary Region after the disaster has been resolved. Without a planned failback, you risk running in an alternate Region indefinitely, which may be suboptimal for cost, latency, or data residency.
Theoretically, yes, with synchronous replication and a multi-region active/active setup. In practice, cross-Region synchronous replication introduces network latency that impacts application performance. Most real-world systems accept a small lag (e.g., 1 second) to maintain performance.
You've finished Disaster Recovery and Business Continuity Planning. Continue through the SAP-C02 study guide to build a complete picture of the exam.
Done with this chapter?