It started with a billing alert.
.
I came to update one alert and I found a mess.
To be clear, these stacks weren't really costing me much. Stopped instances, a few half-deleted leftovers. If they'd been the $252, the alert would've tripped every month. But that's the point. You can't tell what's actually costing you until the clutter is gone.
So the alert could wait. I wanted these stale stacks gone first.
Normally this is a chore. Open the console, find each stack, click delete, wait, refresh, check if it worked, OR write out CLI commands. It's not hard, just tedious. The kind of task I keep putting off.
And that's exactly how this started. ClickOps through the console. I'd just finished deleting an old Directory Service directory over in the Mumbai region by hand, clicking through the screens and waiting out the spinner, when it hit me. Barely ten minutes of manual clicking, and I still had a pile of stacks to go. I didn't have to do any of this myself.
Why was I still clicking?
I opened , and just described what I wanted. I talked about how I set it up earlier in my blog
It came back with 12 stacks. Some I recognised, while some were ancient, a billing-alerts stack from 2014, a few patching and compliance stacks from 2021, the CDK bootstrap toolkit. And then the ones I actually wanted gone.
I picked and told the agent to delete four of these stacks.
It asked before it deleted
This matters, so I want to call it out first.
I got the speed of "just handle it" without giving up the checkpoint on a destructive action.
It checked the result as code, not clicks
Once the delete requests were in, the agent wrote a script and ran it in the toolkit's sandbox to check the status of all four at once.
The fourth stack, aws-sam-cli-managed-default, came back DELETE_FAILED.
So, the agent pulled the stack events to find out why. The failure pointed at one resource, the S3 bucket SAM uses for deployment artifacts (SamCliSourceBucket). The message was specific:
The bucket you tried to delete is not empty. You must delete all versions in the bucket.
This bucket had versioning enabled. So "empty the bucket" isn't enough. Every object version and every delete marker has to go, or CloudFormation still can't remove the bucket. That's why a quick "empty" in the console sometimes doesn't fix it.
The agent explained the cause, then offered to empty the bucket properly and retry. I said yes.
That whole detour, remembering the versioned-bucket gotcha, hunting down the bucket name, realising delete markers count too, emptying it manually, then coming back to retry, is the part I'd normally slog through myself. The agent connected the failed delete to the full bucket and just handled it.
, every call lands in CloudTrail. More on that next.
I could see every call in CloudTrail
This is the part that turns "I let an agent delete my infrastructure" from scary into fine.
Every action the agent took went through the managed AWS MCP Server, and every one of those calls shows up in
It scanned common services in my account. First the default region, then it expanded to the others. 4 more pages of listing. 🫣
It found a significant number of leftover resources from workshops, demos, and old projects, and gave me a Cost Impact Summary.
3 stopped EC2 instances, oldest one from 2021.
14 unattached EBS volumes, some created back in 2014, still quietly billing for storage attached to nothing.
5 Elastic IPs sitting unassociated, roughly $18 a month for addresses doing no work.
122 S3 buckets, a load balancer I forgot about, 16 Lambda functions all on runtimes that hit end of life years ago.
None of it broke anything. That's exactly why it survived this long.
SOCIAL SHARE CARD GENERATOR