What this prompt does
This prompt sets the model up as a senior AWS reliability engineer and asks it to build a disaster recovery plan tight enough to execute, with a real runbook. You provide [workload], your [rpo] and [rto] targets, and a [budget_posture], and it maps the four DR strategies against those targets, designs cross-region replication, writes a failover runbook with owners, schedules restore tests, plans failback, and costs each option.
The structure works because it anchors every decision to your [rpo] and [rto] instead of defaulting to the most expensive setup. RPO (how much data you can lose) and RTO (how fast you must be back) are what separate a simple backup-and-restore from a multi-region active-active design, so feeding them in lets the model recommend the cheapest strategy that still meets the targets. [budget_posture] tempers that recommendation, and [workload] grounds the replication design in your actual data stores — RDS, S3, DynamoDB. The runbook and restore-test schedule are what turn the plan from a document into something operational, because a recovery procedure nobody has rehearsed is indistinguishable from having no plan at all when the region goes down.
When to use it
- You have RPO/RTO targets and need to know which DR strategy actually meets them.
- You want a cost comparison across backup, pilot light, warm standby, and active-active.
- You need a failover runbook with named owners and clear decision points.
- You're designing cross-region replication for RDS, S3, or DynamoDB.
- You have a DR plan on paper but no restore-test schedule to prove it works.
- You need a failback plan for once the primary region recovers.
Example output
Expect a strategy recommendation that names the one DR approach fitting your RPO/RTO, a step-by-step failover runbook with owners and decision points, a restore-test schedule, a failback procedure, and a cost table comparing all four strategies so the choice is informed. The replication section spells out how RDS, S3, and DynamoDB sync across regions.
Pro tips
- Set
[rpo]and[rto]from a real business conversation, not a guess — they drive the entire recommendation. - Use
[budget_posture]honestly; "cost-conscious" steers the model away from active-active when warm standby will meet the target. - Put the restore test from step 4 on a real calendar immediately; an untested backup is a guess, not a recovery.
- Make
[workload]list your actual data stores so the cross-region replication design is concrete. - Treat the cost table as relative, not absolute — confirm regional pricing before you choose.
- After the first plan, ask it to tighten the RTO and see how much the cost jumps; it clarifies the tradeoff.
- Assign real owners in the failover runbook; a decision point with no named owner stalls exactly when speed matters most.
- Test the failback path too, not just the failover — returning to the primary region cleanly is often the step teams forget to rehearse.
