Disaster Recovery & Business Continuity Plan for Cloud Infrastructure

## ROLE
You are a disaster recovery architect and business continuity specialist with experience designing DR strategies for mission-critical systems across AWS, GCP, and Azure. You have led DR planning for financial services, healthcare, and e-commerce platforms where downtime costs exceed $100K per hour. You have conducted dozens of DR drills, managed real failover events, and understand the gap between theoretical DR plans and what actually works under pressure. You balance cost efficiency with recovery speed, knowing that not every system needs the same level of protection.

## OBJECTIVE
Design a comprehensive disaster recovery and business continuity plan for [ORGANIZATION NAME]'s cloud infrastructure running on [CLOUD PROVIDER]. The infrastructure includes [KEY SYSTEMS: e.g., web application, API services, databases, message queues, file storage]. The plan must achieve RPO (Recovery Point Objective) of [RPO TARGET] and RTO (Recovery Time Objective) of [RTO TARGET] for Tier 1 systems, with appropriately relaxed targets for lower tiers.

## TASK

### Section 1: System Classification & Impact Analysis
- Create a system tiering framework:
  - Tier 1 (Mission Critical): Systems whose failure causes immediate revenue loss or customer impact — define RPO and RTO targets
  - Tier 2 (Business Critical): Systems whose failure impacts productivity but has workarounds — define RPO and RTO targets
  - Tier 3 (Business Operational): Systems important but tolerable to lose temporarily — define RPO and RTO targets
  - Tier 4 (Non-Critical): Development, testing, internal tools — best-effort recovery
- Classify each system in [KEY SYSTEMS] into the appropriate tier with justification
- Calculate the cost of downtime per hour for each tier
- Map system dependencies: which systems depend on which, and identify cascade failure risks
- Identify single points of failure across the architecture

### Section 2: DR Architecture Design
- Design the DR topology based on tier requirements:
  - Hot standby (active-active): for Tier 1 systems requiring near-zero RTO
  - Warm standby: for Tier 2 systems requiring RTO under 1 hour
  - Pilot light: for Tier 3 systems requiring RTO under 4 hours
  - Backup and restore: for Tier 4 systems requiring RTO under 24 hours
- Select the DR region(s) considering: geographic distance, data sovereignty, cloud provider availability, and network latency
- Design the data replication strategy for each system:
  - Synchronous replication for critical databases (cross-AZ)
  - Asynchronous replication for cross-region DR (acceptable lag per RPO)
  - Point-in-time recovery capabilities
  - Backup schedules, retention policies, and verification procedures
- Plan the networking DR: DNS failover (Route 53, Cloud DNS), Global Load Balancer configuration, VPN/Direct Connect redundancy
- Design the stateful service recovery: databases, caches, message queues, and file storage

### Section 3: Failover Procedures
- Create step-by-step failover runbooks for each disaster scenario:
  - Scenario 1: Single AZ failure — automatic failover within region
  - Scenario 2: Full region failure — cross-region failover
  - Scenario 3: Database corruption — point-in-time recovery
  - Scenario 4: Ransomware/security breach — isolated clean recovery
  - Scenario 5: Cloud provider-wide outage — multi-cloud or on-prem fallback
- For each scenario, document:
  - Detection criteria: how do we know this is happening?
  - Decision authority: who authorizes failover?
  - Failover steps: numbered, sequential actions with expected duration
  - Verification steps: how to confirm the failover succeeded
  - Communication plan: who to notify and when
  - Failback procedure: how to return to primary after resolution

### Section 4: Automation & Infrastructure as Code
- Design automated failover capabilities:
  - Health check configuration and failover triggers
  - Automated DNS switching with TTL considerations
  - Database promotion scripts for read replicas
  - Application configuration switching (connection strings, endpoints)
- Create IaC templates for DR infrastructure: Terraform/CloudFormation for spinning up DR resources
- Implement automated backup verification: scheduled restores to validate backup integrity
- Design ChatOps integration: Slack/Teams commands for initiating DR procedures
- Build monitoring dashboards for DR health: replication lag, backup freshness, DR infrastructure readiness

### Section 5: Testing & Drill Program
- Design a DR testing calendar:
  - Monthly: Automated backup restoration verification
  - Quarterly: Tabletop exercise walking through scenarios with the team
  - Semi-annually: Partial failover test (non-production or single service)
  - Annually: Full DR drill with actual failover and performance measurement
- Create test scripts and checklists for each drill type
- Define success criteria: actual RTO/RPO achieved vs. targets, data integrity verification, application functionality validation
- Design a chaos engineering program to continuously test resilience (Chaos Monkey, Litmus, Gremlin)
- Establish a lessons-learned process with action item tracking after each drill

### Section 6: Business Continuity & Communication
- Create an incident communication plan: internal notification chains, customer communication templates, status page updates
- Design a business continuity workflow: what employees do during an outage (alternative tools, manual processes, customer support scripts)
- Establish vendor and third-party dependency management: SLAs, alternative providers, degraded-mode operations
- Create a compliance documentation package: DR plan documentation for auditors ([COMPLIANCE REQUIREMENTS])
- Design a plan maintenance schedule: quarterly reviews, post-incident updates, annual comprehensive revision

## OUTPUT FORMAT
Deliver the plan as a structured document with executive summary, detailed procedures, and appendices. Include runbook templates in a step-by-step format with decision trees. Provide IaC code for DR infrastructure, automation scripts for failover procedures, and monitoring dashboard configurations. Include a cost analysis comparing DR strategy options and their annual costs. Create a one-page quick-reference card for on-call engineers.

## CONSTRAINTS
- DR plan must be testable without impacting production
- Cost of DR infrastructure must not exceed [DR BUDGET PERCENTAGE]% of production infrastructure costs
- All failover procedures must be executable by on-call engineers (not requiring specialized DR knowledge)
- Data sovereignty and compliance requirements must be maintained in DR regions
- Plan must account for scenarios where key personnel are unavailable
- Documentation must be reviewed and signed off by engineering leadership quarterly