Demo Cross Region Backup and Replication

This lesson reviews disaster recovery (DR) fundamentals—Recovery Time Objective (RTO), Recovery Point Objective (RPO)—and the four common DR models used in AWS: Backup & Restore, Pilot Light, Warm Standby, and Active‑Active. You’ll learn trade-offs between cost, complexity, and recovery speed so you can design a plan that meets business requirements. At an associate or practitioner level, DR is about keeping services available during failures to protect customers and revenue while choosing an appropriate cost/complexity balance. AWS follows a shared responsibility model: AWS operates the global infrastructure (hardware, compute, storage, Regions, Availability Zones, edge locations) while customers are responsible for everything they configure and run — your applications, data, IAM policies, encryption, and resiliency controls. If you can log in or change it, you own it. RTO and RPO are critical inputs to DR design and planning:

• RTO (Recovery Time Objective): the maximum acceptable time that a service can be unavailable after an incident. Example: RTO = 4 hours means the system must be recovered within 4 hours.
• RPO (Recovery Point Objective): the maximum acceptable amount of data loss before the incident. Example: RPO = 15 minutes means losing more than 15 minutes of data is unacceptable.

Both are usually measured in seconds, minutes, hours, or days. Tighter RTO/RPO requires more automation, redundancy, and cost.

---

​

Disaster Recovery Model 1 — Backup & Restore

Backup & Restore stores point-in-time copies of data and configuration in another Region (snapshots, object copies, exported data). During an outage you recreate infrastructure (typically via Infrastructure as Code) and restore data from backups. This model is cost-efficient because you don’t maintain duplicate compute, but it is the slowest option: recovery involves redeploying stacks and restoring data, which increases RTO and operational risk (drift, IaC failures). Use cases: non‑critical applications or systems that can tolerate hours of downtime or some data loss. AWS Backup centralizes scheduling, retention, and cross‑Region copy for many services. But backups are only useful if restores work—regular restore testing is essential. You can automate restore validation using AWS Backup plus Lambda and SNS to orchestrate test restores, run verification tests, and clean up test resources. Other cross‑Region options include S3 Cross-Region Replication (CRR) with versioning enabled. CRR copies objects to another Region but requires versioning on the source (and typically the destination) to support full protection and object-level restores. Backup & Restore is suitable when cost is a priority and RTO/RPO are in hours or longer. Even if you use a warmer DR model, keep immutable/point‑in‑time backups to protect against silent corruption or malicious deletion. Best practices

• Use AWS Backup to centralize and automate backups.
• Configure schedules and retention to meet your RPO.
• Enable versioning for S3 and other versionable stores.
• Maintain IaC templates (CloudFormation/CDK) for repeatable redeployment.
• Periodically perform test restores and verification.

---

​

Disaster Recovery Model 2 — Pilot Light

Pilot Light keeps core components (usually data services) running and synchronized in the DR Region while the application stack is preconfigured but not actively running. At failover you start and scale application servers. This shortens RTO versus Backup & Restore because data is already replicated; recovery focuses on bringing application services online. Pilot Light characteristics:

• Data services (RDS/Aurora, replicated object stores) are active and replicated.
• Application servers are off or minimal, but IaC is available for quick provisioning.
• Recovery involves provisioning or starting app servers and switching traffic.

Pilot Light balances cost and recovery speed—faster than Backup & Restore, less costly than a full warm standby. Automation is critical: keep IaC ready for multi‑Region deployment and use tools like AWS Elastic Disaster Recovery (formerly CloudEndure Disaster Recovery) to replicate block-level data and enable rapid launch of recovery instances. Note: AWS Elastic Disaster Recovery uses agents to replicate block-level data into a staging area in the DR Region and can build AMIs/volumes for fast recovery. It supports Pilot Light, Warm Standby, and Hot/Active scenarios.

---

​

Disaster Recovery Model 3 — Warm Standby

Warm Standby runs a fully functional, but scaled‑down, version of production in the DR Region. Some traffic or health checks may go to the standby to keep components warm. On failover you scale the standby to full capacity and shift traffic. This model gives faster recovery than Pilot Light because application servers are already running (albeit at reduced scale); failover typically involves scaling and DNS/traffic reweighting. Key points

• Both Regions run infrastructure; the DR Region is scaled down.
• Data replication may be unidirectional or bidirectional; consider global services (Aurora Global Database, DynamoDB Global Tables) for cross‑Region data.
• Failover primarily requires scaling and reweighting DNS/traffic.

Warm Standby is appropriate when you need recovery in minutes (often under 10 minutes) and accept ongoing costs for reduced capacity.

---

​

Disaster Recovery Model 4 — Active‑Active (Multi‑Site)

Active‑Active runs full production-capacity infrastructure in multiple Regions. Traffic is distributed (by latency, geography, or weighted DNS) and data replication is continuous and bidirectional so each site can serve reads and writes. This model delivers the shortest RTO/RPO (near-real‑time), but it is the most expensive and operationally complex. Active‑Active is ideal for global services that require low latency and sub-minute RTO/RPO and can absorb the operational and cost overhead.

---

​

Choosing a Model — Quick Reference

Choose the model that aligns to your RTO, RPO, budget, and operational capability. The table below summarizes common trade-offs.

---

​

Practical Tips

• Use Infrastructure as Code (CloudFormation, AWS CDK, Terraform) to codify deployments and accelerate failover.
• Automate runbooks and recovery playbooks with scripts or orchestration (Lambda, Step Functions).
• Test failover and restore scenarios regularly—both planned drills and unannounced tests.
• Monitor replication lag, backup health, and runbook execution times to ensure RTO/RPO goals are achievable.
• For databases, prefer managed global services (Aurora Global Database, DynamoDB Global Tables) when low-latency replication is required.

​

Links and Further Reading

• AWS Shared Responsibility Model
• AWS Backup
• S3 Cross-Region Replication (CRR)
• AWS Elastic Disaster Recovery
• Aurora Global Database

That covers the core DR models and how RTO/RPO influence design decisions in AWS. Use IaC, automation, and regular restore testing to ensure your DR plan works when you need it.