c3.23 Plan for disaster recovery
Have a business-continuity plan that states which workloads must survive the loss of an Availability Zone and which must survive the loss of an entire Region. Choose the DR strategy per workload based on its recovery time and recovery point objectives (RTO/RPO).
Implementation guidance
Decide what must survive what
Document, per workload, whether it must withstand the loss of an Availability Zone (most workloads) or an entire Region. Then pick a DR strategy sized to its RTO and RPO — backup and restore, pilot light, warm standby, or multi-site active/active.
A common cost-balanced pattern
For a workload that must survive a Region loss: run Multi-AZ high availability in the primary Region, continuously replicate data to a second Region, and keep infrastructure as code ready to stand up the recovery environment on demand. A key advantage of DR over pure HA is point-in-time recovery — you can restore to "before the compromise" or "before ransomware started spreading".
Tooling
AWS Elastic Disaster Recovery sets up, tests, and operates DR by continuously replicating servers into AWS, with encryption in transit and at rest. Common uses are on-premises-to-cloud DR (cost-efficient, pay-per-use recovery site) and cross-Region DR. It supports many operating systems and applications — see the Elastic DR FAQ.
Test the plan
A DR plan you have never exercised is a hypothesis. Run failover tests (Elastic DR supports non-disruptive drills) and tie them into your tabletop exercises.
How to validate
- Does a business-continuity plan state which workloads must survive AZ vs. Region loss?
- Are DR strategies matched to each workload’s RTO/RPO?
- Can you recover to a point in time before a compromise, and have you tested failover?
Threats addressed
- Without a tested DR plan, a Region-wide outage or a destructive event (such as ransomware) can cause prolonged downtime or permanent data loss because there is no rehearsed way to recover to a clean point in time.
Cloud Security Maturity Model