The template
Ours Our version, built from his article. He had Claude Code write a reusable prompt but didn't publish it. Fill in the [BRACKETS].
Audit these AWS accounts for waste and write a cost plan. Read-only first. You propose; I approve every change.
ACCESS
- Use only the AWS CLI profiles I name: [profiles]. Start with read-only access.
- Never delete, resize, stop, disable, buy, renew or change anything without my yes for that exact item. Deleting and buying always need a human.
1. DIAGNOSE (each account)
- Monthly cost by service, and the biggest movers vs last month.
- Look for, with the number behind each:
- crawlers, jobs or schedules running against big buckets (requests and compute hours)
- buckets with no lifecycle rules: size, access pattern, storage class
- databases capped far above real use: pull average, peak and connections from CloudWatch for the last 14 days before you suggest anything
- log groups with no retention
- idle load balancers, unattached IPs and volumes, old snapshots and unused images
- gp2 volumes that could be gp3
- premium monitoring tiers that don't earn their cost
- traffic through NAT that an S3 gateway endpoint would carry
- tables that would benefit from TTL, and functions with zero calls for months
2. PLAN
- One table: item, account, what it costs now, the change, saving per month, risk (low / medium / high), how to roll back, and the evidence (metric or command output).
- Split into: safe in one session with no code change, and needs other teams, tests or a window (consolidations, reserved-instance renewals, resizing, caching).
3. EXECUTE (only after I approve each row)
- Run one approved change at a time, then check it worked and nothing broke. Stop and tell me if a check fails.
4. MAKE IT REPEATABLE
- At the end, write a reusable prompt with the method, the waste types you found, the pitfalls, the commands that worked and the safeguards, so I can run this every month.
What they did
- His company runs two AWS accounts: a heavy production account (Aurora MySQL and PostgreSQL clusters, SQL Server, ECS Fargate, Lambdas, load balancers, terabytes of S3, Glue, DynamoDB) at about US$7,759 a month, and an inherited data-pipeline account at about US$3,467 a month with no cost review for over a year.
- He pointed Claude Code at both accounts' AWS CLI profiles with one instruction: investigate them, find every bit of waste and put together a plan. He asked for a diagnosis of both accounts in parallel.
- The second account was burning about US$100 a day: Glue crawlers running against a bucket of more than 1 TB (millions of HEAD/LIST requests a day), buckets with no lifecycle policies, an Aurora Serverless v2 cluster with MaxACU at 32 while it averaged a fraction of one ACU over 14 days, log groups with no retention, and idle load balancers, orphaned IPs and EBS snapshots from 2019. It went from US$3,467 to a projected ~US$900 a month.
- Before recommending a database change, it pulled real use from CloudWatch (average ACU, peaks, connections). For buckets it listed size, access pattern and storage class; for crawlers, the DPU-hours used and the S3 request cost.
- The production account had dozens of small fixes: premium database monitoring tiers turned off where they weren't worth it, EBS gp2 to gp3, orphaned volumes and old snapshots, lifecycle rules to move cold data to IA/Glacier, an S3 gateway endpoint so traffic stopped flowing through the NAT gateway, log retention, Athena partition projection in place of a log crawler, DynamoDB TTL, DevOps Guru off, and Lambdas with no calls for months. It went from US$7,759 to about US$6,500.
- Combined: US$11,226 to about US$7,400 a month, 34%, about US$46K a year. He says there were no code changes, no maintenance window and no incidents.
- Left for later, because they need other teams, tests and planned windows: merging near-idle Aurora clusters, not blindly renewing reserved instances, resizing EC2 instances running under 5% CPU, and caching a DynamoDB table read 11.5 million times a day. He puts that at another US$1,500 to 2,000 a month and about two weeks of work, with per-step human confirmation.
- His most valuable step, he says: asking Claude Code to turn the method, the waste types, the pitfalls, the commands that worked and the database safeguards into a reusable prompt to run monthly on any account. He didn't publish it.
“Every recommendation came attached to the number that justified it”— Pedro Rosa (Medium), Medium
Summary written by Agent Cookbook. The amount is quoted as the creator stated it in their own public post or interview; we link it but can't see their accounts. See the original for full context. How we verify
Our notes
- What it takes
- Claude Code, AWS CLI profiles for each account (start read-only), CloudWatch metrics and billing data. He had Claude Code write a reusable monthly prompt but didn't publish it; ours follows his article.
- Where it breaks
- Changing database limits without real usage data, deleting snapshots or logs you still need, renewing reserved instances by habit, and rushing changes that need other teams. Some of his after-figures are projections.
- Human checkpoint
- Claude Code audits and proposes. You approve each change before it runs, and you decide on anything that deletes data, resizes, renews or needs a maintenance window.
- Tools involved
- Claude Code, AWS CLI profiles for each account, CloudWatch metrics for real usage (he used the prior 14 days), Billing data to compare months, A person who confirms each change
✓ Verified Source link checked and still live. Notes by Thomas, editor. How we verify
Approval rule
🛡
In our version Claude Code audits with read-only access and proposes. You approve each change before it runs, and nothing is deleted, resized, switched off or committed to without your yes for that item. Sending, buying, posting and deleting always need a human.
Set it up
- Create read-only AWS CLI profiles for each account and give Claude Code those first.
- Ask it to diagnose all accounts in parallel and back every finding with a number from CloudWatch or billing.
- Review the plan table and approve the low-risk, no-code rows one by one.
- Let it run each approved change with your confirmation, and check each one before the next.
- Put the bigger changes (consolidations, renewals, resizing) into a separate plan with tests and a window.
- Ask it to write the session up as a reusable prompt and run it monthly.
Common failures
⚠
- Changing a database's limits from a guess. He had it pull 14 days of real use from CloudWatch first.
- Deleting snapshots, versions or logs you'll need later. Lifecycle and retention rules remove data for good.
- Renewing reserved instances out of habit when the instances run at single-digit CPU.
- Rushing structural changes into the same afternoon. He left those for planned windows with other teams.
- Counting projected savings as money saved before a month's bill confirms it.
Variations
- Run the same audit on a new account you inherit, before anything else.
- Start with one account that nobody has reviewed in a year; his second account had the biggest leak.
- Feed it last month's bill each month and only report what changed.
Get the next money recipe. Free.
New recipes every week, plus the top 10 agent setups pack.
Unsubscribe anytime. Privacy