BuildWithAI: DR Toolkit on AWS
What if generating a DR runbook was as easy as pasting a CloudFormation template? Fork and deploy six AI-powered serverless tools on your AWS account - powered by Amazon Bedrock. This is the overview of the 3-part build series on dev.to.
I'd been getting more involved in disaster recovery planning recently and kept bumping into the same gap - most teams on AWS have backups, maybe some snapshots, but no actual DR plan. No documented runbooks. No tested failover steps.
That gap felt like something worth solving.
With the help of Kiro (AWS's spec-driven AI IDE), I built a Disaster Recovety (DR) toolkit: six AI-powered tools running entirely on AWS serverless, powered by Amazon Bedrock. It's free, no sign-up required, and you can fork the whole thing and deploy it to your own account in about ten minutes.
What the toolkit actually does
The toolkit covers six common DR planning tasks that most teams either skip or do manually in a shared doc somewhere:
| Tool | Model | What it does |
|---|---|---|
| Runbook Generator | Nova Pro | Paste your CloudFormation or Terraform template, get a step-by-step DR runbook back |
| RTO/RPO Estimator | Nova Lite | Fill out a short form about your workload, get recovery time and data loss targets |
| DR Strategy Advisor | Nova Lite | Answer a few questions about your setup, get a recommended DR architecture pattern |
| Post-Mortem Writer | Nova Lite | Paste raw incident notes, get a structured post-mortem document |
| DR Checklist Builder | Nova Lite | Pick your AWS services, get a tailored DR audit checklist |
| Template DR Reviewer | Nova Pro | Paste IaC templates, get a gap analysis with suggested fix snippets |
The DR strategies these tools recommend - backup & restore, pilot light, warm standby, and multi-site active/active - follow the patterns described in the Disaster Recovery of Workloads on AWS whitepaper. I didn't want the tools making up their own frameworks.
How it's built
The architecture is straightforward serverless:
- One Lambda function per tool, with a shared Lambda Layer for guardrails and common logic
- API Gateway as the front door
- DynamoDB for rate limiting counters (daily limits, per-IP throttling)
- Amazon Bedrock for model inference, using cross-region inference profiles for availability
- CloudFront + S3 (private bucket with OAC) serving a Next.js static frontend
- Serverless Framework for deployment
All model configuration lives in a single
models.config.json file. Want to swap from Nova to Claude, or mix models across tools? Change one field, redeploy. Anything in the Bedrock model selection works.IAM policies are scoped to specific model ARNs - not
bedrock:*. Security headers are set via CloudFront response headers. Prompt injection is mitigated by using Bedrock's dedicated system parameter to separate instructions from user input at the API level.Keeping costs under control
This is a free demo, so cost protection matters. I stacked five layers of guardrails to keep it under $10/month (and yes - that's a demo budget, not a production recommendation):
- API Gateway throttling - 10 requests/second, burst of 25
- Daily usage counters - 200 requests/day globally, 50 per individual tool, tracked via DynamoDB atomic increments
- Per-IP rate limiting - 3 requests/minute per IP, using DynamoDB TTL-based counters
- Token caps - Each tool has its own max_tokens (400–800 range), and all user input is truncated to 8,000 characters before hitting Bedrock
- Budget auto-shutoff - An AWS Budgets alarm at $10/month triggers SNS, which invokes a Lambda that flips a kill switch
None of these are fancy. But layered together, they've kept the demo running for weeks without a surprise bill.
Prompt patterns that made a difference
A few things I picked up while writing prompts for all six tools:
Role assignment works. Setting the system prompt role to "Senior AWS cloud reliability engineer" produces output that's noticeably more AWS-specific - service names, best practices, actual console paths. Without the role, you get generic cloud advice that could apply to any provider.
"Do not invent facts" is non-negotiable for the Post-Mortem Writer. Without that explicit instruction, the model would infer plausible-sounding root causes that weren't anywhere in the source notes. Great for brainstorming, terrible for an incident report.
System prompt separation matters. All handlers use Bedrock's
system parameter rather than stuffing instructions into the user message. Instructions and user input stay in separate lanes at the API level - it's not bulletproof, but it's a meaningful layer against prompt injection.The deeper build log
I wrote a 3-part series on dev.to covering the full build in detail:
- Part 1 - Architecture: The 5-layer cost stack, central model config, security decisions, and how the pieces connect
- Part 2 - Prompt Engineering: How all six tool prompts were designed, organized by problem type (generation vs. analysis vs. extraction), with the reasoning behind model selection for each
- Part 3 - Lessons Learned: What broke during the build, the deployment walkthrough, and a Kiro workflow for adding a 7th tool if you want to extend it
You can find the full series here: BuildWithAI: DR Toolkit on AWS
BuildWithAI: DR Toolkit on AWS Series
Try it or fork it
The toolkit is live at dr-toolkit.thecloudspark.com - go poke at it, paste a CloudFormation template, see what it generates.
If you want to run your own:
1
2
3
4
git clone https://github.com/romarcablao/dr-toolkit-on-aws.git
cd dr-toolkit-on-aws
./scripts/deploy.sh
python scripts/seed_dynamodb.py
Ten minutes, your own AWS account, under $10/month for a demo environment. Swap in different Bedrock models if you want. The full deploy guide is in Part 3 of the series.
References:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article