What this prompt does
This prompt designs a multi-region AWS disaster recovery strategy matched to your actual recovery targets. You give it your [application_type], [primary_region], [secondary_region], an [rto], and an [rpo], and it evaluates pilot light, warm standby, and active-active before recommending one based on those targets and your [budget_constraint]. From there it specifies data replication for [database], application-layer setup in the secondary region, Route 53 DNS failover, S3 cross-region replication, and secrets replication.
The structure works because it refuses to skip the unglamorous parts. Most DR plans stop at the architecture diagram, but this prompt forces a step-by-step failover runbook and a quarterly DR test plan covering [test_scenarios] without touching production. The [rto] and [rpo] variables are the anchor — a 15-minute RTO and 1-minute RPO pushes the recommendation toward warm standby or active-active, while looser targets allow cheaper pilot light. The [failover_trigger] and [health_endpoints] shape exactly when Route 53 cuts over.
When to use it
- An application has reached the point where downtime carries real cost and needs a deliberate DR posture
- You need to choose between pilot light, warm standby, and active-active against honest
[rto]and[rpo]targets - You want cross-region replication designed for
[database]with replication-lag monitoring - You need a Route 53 failover policy tied to
[health_endpoints]and a clear[failover_trigger] - Your DR plan lacks a written failover runbook with validation at each step
- You want a repeatable quarterly DR test covering
[test_scenarios]that does not impact production
Example output
Expect a strategy document: a comparison of the three DR patterns with a recommendation justified by your [rto], [rpo], and [budget_constraint]; replication configuration for your database and S3 buckets; a Route 53 failover design; a numbered failover runbook with validation checks at each step; and a quarterly test plan. The runbook and test plan are the operational deliverables teams most often skip.
Pro tips
- Set
[rto]and[rpo]honestly — tighter targets justify more expensive standby capacity, so don't claim a 1-minute RPO unless the business truly needs it - Use
[budget_constraint]to keep the recommendation realistic; capping DR at a percentage of primary cost steers the model toward warm standby over full active-active - Be precise about
[secondary_config]— "warm standby at 25% of primary" produces a very different cost and failover profile than full-capacity - Define
[failover_trigger]carefully; too sensitive and you flap between regions, too lax and you exceed your RTO during a real outage - The runbook is only as good as your testing, so actually run the quarterly
[test_scenarios]— an untested DR plan is a guess - Validate replication-lag monitoring against your real
[rpo]; the model proposes the design, but you must confirm lag stays within target under load
