Skip to main content
Welcome back, students of AWS Solutions Architect Associate Certification. This lesson covers designing for reliability with a focus on disaster recovery (DR) models. The content maps directly to topics tested on the AWS Solutions Architect Associate exam, so review carefully. Disaster recovery (also called business continuity planning) defines how workloads recover when disruptions occur. Resiliency — the ability to restore services after disruption — is a core responsibility for an architect. Your job is to ensure workloads include a tested recovery strategy for plausible disasters, including whole-region failures such as floods, earthquakes, or large-scale outages. Key DR metrics
  • Recovery Point Objective (RPO): How much data can you afford to lose? RPO is driven by backup frequency and replication lag — it defines the point in time to which data must be recovered.
  • Recovery Time Objective (RTO): How long can the service be unavailable? RTO is the allowed time between an outage and full service restoration (including data restoration).
AWS operates under a shared responsibility model: AWS maintains the infrastructure, but you are responsible for your data, application configuration, and enabling DR mechanisms (cross-region replication, backups, failover automation). Many AWS services provide cross‑AZ resilience and optional cross‑region features, but customers must configure, automate, and test them. RPO concerns data loss; RTO concerns downtime. They interact — long data restores increase RTO. For example, if restoring a database takes four hours, your effective downtime will be at least that restore time plus any additional time to cut over services, even if backups are frequent.
A simple diagram showing a timeline with a fire icon labeled "Disaster" that separates a Recovery Point (RPO) on the left (data loss) from a Recovery Time (RTO) on the right (downtime). The image highlights the questions of how much data you can afford to lose and how quickly you must recover.
In short:
  • RPO = maximum acceptable data loss
  • RTO = maximum acceptable downtime
Both are business-driven and together determine the DR architecture and operational processes you choose (backup cadence, replication strategy, automation, runbooks, and testing cadence). Common AWS disaster recovery strategies AWS recommends four common DR patterns. They trade cost and complexity against RPO and RTO. From lowest cost / highest downtime to highest cost / lowest downtime:
  • Backup & Restore
  • Pilot Light
  • Warm Standby
  • Multi-site Active-Active
Three of these are primarily active-passive (data is active in primary, passive in standby); the multi-site pattern is active-active. Below is a practical description of each pattern, typical RPO/RTO expectations, and example AWS features you might use. Backup & Restore
  • Description: The simplest option. You create and store backups (often cross-region) and rebuild the environment when a disaster happens.
  • Recovery: Typically manual or scripted restores; RTO ranges from hours to days depending on data size and environment complexity.
  • Best practices: Use Infrastructure as Code (IaC) to recreate compute, network, and configuration programmatically, and include automated backup/restore steps in runbooks and CI/CD pipelines.
Use Infrastructure as Code (CloudFormation, Terraform, or CDK) to automate environment rebuilds and integrate backup restore steps. Automation reduces human error and shortens RTO.
Pilot Light
  • Description: A minimal, critical portion of the system runs in the standby region — usually databases and core configuration — while application servers and other components remain off or minimal.
  • Data: Continuous replication to the standby core (cross-region replicas, continuous backup streams).
  • Failover: On disaster, scale up remaining components (app servers, front-end) and redirect traffic to the standby region.
  • Typical RTO: tens of minutes to hours (depends on scale-up time, DNS propagation, and load balancer registration).
An AWS architecture diagram titled "Models of Disaster Recovery – Pilot Light" showing an active primary region and an inactive standby region. It illustrates Route 53, load balancers, auto-scaling front-end and app servers, and an Amazon Aurora primary/replica with cross-region replication.
In Pilot Light the standby region hosts the essentials (most often the database). The rest of the environment is provisioned during failover, so plan for instance boot times, auto-scaling policies, and DNS/health check behaviors when estimating RTO. Warm Standby
  • Description: A scaled-down but fully functional environment runs in the standby region and may handle a small portion of traffic.
  • Data: Continuous cross-region replication (database read replica that can be promoted, or streaming replication).
  • Failover: Scale the standby up to full capacity; often faster than Pilot Light because services are already running and warmed up.
  • Typical RTO: minutes (depends on scaling and traffic cutover).
An AWS architecture diagram titled "Models of Disaster Recovery – Warm Standby." It shows two regions with Route 53 routing, Elastic Load Balancers, auto-scaling front-end and application servers, and Amazon Aurora primary/replica cross-region replication.
Warm Standby reduces failover complexity by keeping the standby environment running at reduced capacity (e.g., smaller instance sizes or fewer instances). When the primary fails, promote replicas as needed and scale the standby. Multi-site Active-Active (Active-Active)
  • Description: Both sites actively handle production traffic (traffic split via DNS or global load balancing).
  • Data: Near real-time replication across sites (DynamoDB Global Tables, Aurora Global Database for reads, or multi-master setups where supported). Be mindful of consistency and potential conflict resolution in multi-master topologies.
  • Failover: Minimal downtime — surviving site(s) continue serving traffic; systems scale as needed.
  • Typical RTO/RPO: near-zero downtime and minimal data loss (dependent on replication consistency and network conditions).
  • Complexity/cost: Highest.
An AWS architecture diagram titled "Models of Disaster Recovery – Quick Snapshot" showing a continuum from Backup & Restore through Pilot Light and Warm Standby to Multi-site. Each stage lists typical RPO/RTO (hours → real-time), example solutions (backup, replication, database/cloud services) and relative costs.
Active-active architectures are appropriate for business-critical, latency-sensitive, or global applications where the cost of downtime exceeds the operational cost of running multiple active regions. Quick comparison table Trade-offs and decision factors
  • Backup & Restore: lowest cost, highest downtime and potential data loss depending on backup frequency.
  • Pilot Light: moderate cost, moderate RTO, low data loss if replication is continuous.
  • Warm Standby: higher cost, faster failover than Pilot Light because components are running.
  • Active-Active: highest cost and operational complexity, lowest downtime and minimal data loss.
A slide titled "RTO and the Models" with a chart plotting cost/complexity versus length of service interruption showing a blue curve (recovery cost/complexity decreasing) and a red curve (business impact cost increasing). It labels recovery options like Multi‑Site Active/Active, Warm Standby, Pilot Light and Backup & Restore, and shows lines for Acceptable Recovery Cost and the Recovery Time Objective.
Practical considerations
  • Business requirements drive RPO/RTO: always start with the business impact analysis to choose an appropriate DR model and budget.
  • Data size and restore time: large datasets can make restores time-consuming; replication or continuous backup often reduces effective RTO.
  • DNS and health checks: Route 53 health checks and routing policies affect failover behavior and must be tested (failover propagation times vary by TTL and client caching).
  • Automation & testing: Automate provisioning, replication, failover, and rollback steps. Run regular disaster recovery drills to validate assumptions and update runbooks.
Data loss expectations by model
  • Multi-site Active-Active: typically no data loss if replication is synchronous or near-real-time and conflict resolution is handled.
  • Warm Standby / Pilot Light: usually minimal data loss due to replication, but exact RPO depends on replication method and lag.
  • Backup & Restore: data loss equals the backup window (e.g., hourly, every 8 hours) plus any data generated since the last backup.
Always test your disaster recovery plan and failover procedures. Validate recovery times, data consistency, DNS/health propagation, and rollback plans regularly.
Summary
  • Disaster recovery is essential for business continuity and resilience. A DR plan defines how to respond to region-level events and restore service.
  • RPO defines acceptable data loss; RTO defines acceptable downtime. Both are business-driven and guide architecture choice.
  • Common DR patterns: Backup & Restore, Pilot Light, Warm Standby, and Multi-site Active-Active — moving from Backup & Restore toward Multi-site reduces RTO/RPO but increases cost and complexity.
  • Architects should translate business requirements (RPO/RTO, budget, and acceptable complexity) into a specific DR model, automate the design with IaC, and test recovery regularly.
A presentation slide titled "Summary" with a blue gradient panel on the left and four colorful numbered points on the right. The points summarize disaster recovery: DR as part of business continuity, RTO/RPO definitions, common DR patterns (pilot light, warm standby, active/active, backup/restore), and the trade-off of lower RTO/RPO versus higher cost.
Thanks for reviewing this lesson. I’m Michael Forrester — great talking to you. Links and references

Watch Video