Disaster Recovery Patterns
Key Takeaways
- Recovery time objective (RTO) is maximum acceptable downtime; recovery point objective (RPO) is maximum acceptable data loss measured in time. AWS does not publish a single guaranteed RTO for every service.
- The AWS Well-Architected Framework lists four Regional strategies in rising cost and falling RTO/RPO: backup and restore, pilot light, warm standby, and multi-site active-active.
- AWS Elastic Disaster Recovery (AWS DRS) uses a pilot-light staging area with continuous block replication. AWS documents typical RPOs of seconds and typical RTOs of minutes (often described as about 5–20 minutes, dominated by operating-system boot).
- A payments authorization path with an RPO of minutes is not the same design as overnight settlement files that can lose hours of data. Choose the pattern per workload, not one pattern for the whole company.
- Task 1.3 treats RTO/RPO as an organization catalog; Tasks 2.2 and 2.4 choose a pattern when you design a new stack; Task 3.4 adds or upgrades DR on a running system without pretending Multi-AZ is Regional DR.
Recovery objectives before architecture
Quick Answer: Recovery time objective (RTO) is how long the business can stay down. Recovery point objective (RPO) is how much data (in time) it can lose. Pick a disaster recovery (DR) pattern from the AWS Well-Architected Framework using those two numbers plus cost: backup and restore, pilot light, warm standby, or multi-site active-active. AWS Elastic Disaster Recovery (AWS DRS) is the managed staging-area implementation of pilot light for servers.
SAP-C02 items rarely ask you to recite a slogan. They ask whether a payments authorization ledger that cannot lose more than a few minutes of writes belongs on nightly snapshots, and whether an Availability Zone (AZ) impairment is a Regional disaster. This independent OpenExamPrep chapter helps you study those tradeoffs for the AWS Certified Solutions Architect - Professional exam (SAP-C02). It is not an AWS product, and OpenExamPrep does not claim partnership, official review, or approval by Amazon Web Services.
RTO measures unavailability: from the moment the workload stops serving correctly until it serves correctly again. RPO measures data loss: the gap between the last durable recovery point and the failure. Neither number is a service-level agreement (SLA) that AWS publishes for “your application.” AWS publishes typical or order-of-magnitude figures for some products (for example DRS typical RPO in seconds and typical RTO in minutes). Do not invent a guaranteed restore time for Amazon Relational Database Service (Amazon RDS) snapshot restore, AWS Backup restore, or a full Regional rebuild. Restore duration depends on data size, throughput, infrastructure as code (IaC) readiness, Domain Name System (DNS) time to live (TTL), runbooks, and whether you must wait on a control plane API during the event.
The AWS Disaster Recovery of Workloads whitepaper stresses a control-plane versus data plane split. Failover steps that only flip already-provisioned data-plane paths (healthy load balancers, pre-created DNS failover records, Amazon Application Recovery Controller (ARC) routing-control APIs) are more resilient than steps that must create Amazon Elastic Compute Cloud (Amazon EC2) capacity, raise quotas, or deploy an AWS CloudFormation stack while the Region is impaired. That distinction shows up in every later section of this chapter.
Organization, new solution, and existing stack
Task 1.3 (organizational complexity) is a catalog problem. A bank does not assign multi-site active-active to every account in AWS Organizations. Authorization and fraud scoring may need continuous replication; batch extract-transform-load (ETL) and regulatory archives may need tested backups. The organization defines RTO/RPO tiers, which accounts are primary versus recovery, and whether recovery lands in a different AWS account (the whitepaper’s isolation recommendation when compromised credentials are in scope).
Tasks 2.2 and 2.4 apply when you design a new solution. You choose the pattern, the replication technology, and whether recovery compute is missing (pilot light), scaled down (warm standby), or already taking traffic (active-active). You also choose how much you will depend on Auto Scaling at failover time versus static stability (enough capacity already running).
Task 3.4 is the existing-workload problem. Nightly Amazon Elastic Block Store (Amazon EBS) snapshots in one Region are not a lie; they are a backup-and-restore design. Improving reliability might mean enabling AWS DRS on the EC2 estate, copying backups to a second Region, or promoting a data store to a global configuration. It does not mean declaring Multi-AZ RDS to be Regional DR. Multi-AZ is high availability (HA) inside one Region.
The four Regional strategies
AWS lists the strategies in increasing cost and complexity and decreasing RTO/RPO. The following ranges come from REL13-BP02 in the AWS Well-Architected Framework. Treat them as planning bands, not stopwatch guarantees.
| Strategy | Published planning RPO | Published planning RTO | What stays running in the recovery Region | Idle cost | Typical SAP-C02 fit |
|---|---|---|---|---|---|
| Backup and restore | Hours (point-in-time recovery can lower RPO, in some cases as low as about 5 minutes) | 24 hours or less | Backups (and, if you pre-restore, dormant data stores) | Lowest | Settlement files, archives, apps that can rebuild from IaC |
| Pilot light | Minutes | Tens of minutes | Data replication targets and core data-plane pieces; application compute not serving traffic | Low–medium | Most EC2/server estates that need faster RTO than restore-from-backup |
| Warm standby | Seconds | Minutes | A scaled-down but functional copy that can take some traffic immediately | Higher | Customer-facing APIs that must answer before you finish scaling |
| Multi-site active-active | Near zero | Potentially zero | Full production in more than one Region, all serving traffic | Highest | Global payments edges where evacuating a Region must not wait on scale-out |
Backup and restore copies data (and you must also version Amazon Machine Images (AMIs), container images, and CloudFormation or AWS Cloud Development Kit (AWS CDK) templates). At failover you deploy infrastructure, deploy code, and restore data. AWS Backup can copy recovery points across Regions and accounts; it does not, by itself, schedule automatic restore. Periodic restore tests matter because restore APIs are control-plane operations.
Pilot light keeps databases, object stores, and replication always on in the recovery Region. Application servers are not serving production; AWS’s wording is that a best practice for “switched off” is not deploying those resources until failover, then creating them from IaC. You still need point-in-time backups in the recovery Region because continuous replication will happily replicate corruption and ransomware deletes unless versioning or backups exist.
Warm standby runs a smaller but real stack. Failover is “scale up,” not “invent the VPC.” The more you pre-scale, the less you depend on Auto Scaling (a control plane). Fully pre-scaled active/passive is hot standby. Many teams that pay for hot standby decide to send real traffic and call it active-active.
Multi-site active-active serves users from multiple Regions. There is no classic failover for traffic already on a healthy Region; DR testing asks whether the remaining Regions absorb the load and whether write conflict rules still hold. Data destruction still needs backups, so RPO for a corruption event is not zero.
Pilot light versus warm standby is a frequent exam trap. Both have assets in the recovery Region. Pilot light cannot process requests until you take additional action (create compute, maybe attach remaining infrastructure). Warm standby can process a reduced load immediately and then scale.
AWS Elastic Disaster Recovery
AWS DRS continuously replicates disks at block level from on-premises servers, from other clouds, or from EC2-hosted applications into a staging area subnet in the target AWS Region and account. Staging uses affordable storage and minimal compute so you are not paying for a full duplicate fleet during normal operations. That is the pilot-light cost model. AWS Well-Architected notes that DRS can approach warm-standby targets (RPO in seconds, RTO in minutes) while keeping pilot-light idle cost.
AWS DRS documentation states:
- Typical RPO is in the sub-second range when staging storage and network keep up with source write rates. If source writes burst faster than the pipeline, RPO temporarily lengthens until replication catches up. You can still recover, but to an older crash-consistent point.
- Typical RTO is measured in minutes and is highly dependent on operating-system boot time. The concepts guide also describes typical recovery in about 5–20 minutes depending on boot time and recovery configuration. Those are typical capabilities, not a contractual RTO for every server.
- You launch recovery instances into a recovery Amazon Virtual Private Cloud (Amazon VPC) using the latest replicated state or a previous point-in-time snapshot. After the event you can stay on AWS or fail back.
- DRS is for server disks. It is not a substitute for Amazon Aurora Global Database, DynamoDB global tables, or RDS-managed engines. If the workload is RDS, design database DR with the database’s own replication.
Non-disruptive drills are part of the product story. An untested DRS implementation is still a hope, not a measured RTO.
Payments scenario: minutes versus hours
A card network’s authorization service writes every approve/decline. Losing an hour of authorizations means reconciling with the network from an incomplete ledger. That is an RPO of minutes (often seconds). Overnight settlement files dropped to Amazon Simple Storage Service (Amazon S3) might be regenerable from the ledger; an RPO of hours can be acceptable if the regeneration job is tested.
Do not buy multi-site active-active for both paths because “payments.” Put authorization on continuous replication (Aurora Global Database, DynamoDB global tables, or DRS for an EC2 ledger) plus point-in-time backups. Put settlement objects on S3 versioning, Cross-Region Replication (CRR), and AWS Backup. The organization (Task 1.3) publishes those two tiers. The new API (Task 2.2) implements the minutes tier. The legacy file drop (Task 3.4) might stay on backup and restore until someone funds a tighter RPO.
AZ loss is usually not this Regional conversation. A well-built Multi-AZ application already treats one data center as disposable. Escalate to pilot light or warm standby when the disaster definition is Region impairment, ransomware that replication would copy, or a regulatory need for geographic separation.
Design checklist SAP-C02 actually tests
- Write RTO and RPO per application, then map to a named strategy. Mixing “we have Multi-AZ” with “we will restore RDS from a snapshot in another Region” without IaC is how published 24-hour-or-less RTO bands get missed.
- Prefer data-plane failover (health checks, ARC routing controls, pre-provisioned capacity) over creating accounts, raising quotas, or clicking the console during the outage.
- Keep point-in-time copies even when replication is continuous. Replication is not an undo log for bad writes.
- For existing EC2 estates, evaluate DRS before rebuilding a second active Region. For existing RDS, evaluate Multi-AZ first (HA), then cross-Region replicas or Aurora Global Database (DR).
- Test. AWS Resilience Hub is the Well-Architected suggestion for tracking whether you are likely to meet targets; it does not replace a failover drill.
A card issuer’s authorization ledger cannot lose more than a few minutes of writes, but overnight settlement files in Amazon S3 can be regenerated and may lose several hours of objects. Using AWS Well-Architected recovery strategies, how should a solutions architect set the patterns?
An enterprise wants recovery objectives similar to warm standby for applications that run only on Amazon EC2, but it refuses to pay for a full always-on duplicate fleet in the recovery Region. Which AWS service does the Well-Architected recovery guidance describe as a pilot-light cost model with typical RPOs in seconds and typical RTOs in minutes?
A team is designing a new customer-facing API (Tasks 2.2 and 2.4) that must recover in tens of minutes after a Regional event. Leadership will not run full production capacity in a second Region. The current production monolith in another account still uses only nightly snapshots (Task 3.4). What is the appropriate pattern for the new API?