How I Cut Our AWS Bill in Half With AI

I've done this before, the old way. I've put engineers on it. I've put finance on it. I've spent my own time on it. It was always a massive, coordinated effort with a mediocre result, because nobody had the full picture and nobody had the time to build it.

This time it was me and AI. Nobody else. No committee, no ticket queue, no waiting on someone else's sprint. I had every credential, every architecture diagram (and what was missing was in my head), and twenty years of knowing where the bodies are buried in this AWS account. That combination doesn't exist twice at most companies — which is exactly why I'm writing this down. Below is the actual playbook: the tools, the prompts, and the process, not a theoretical version of it.

Bluntly — none of this was possible without AI. Not "AI made it faster." Possible. One person cannot manually account for every dollar across an org-wide multi-account AWS bill and act on it daily. An agent can.

Why I was the only person who could do this

I'm the Founder, but on this account I've also been the lead Engineering Architect for twenty years — nobody else has held either title. I have access to all the code and all the documentation. I built or approved most of the systems that created this AWS account, and I know how the pieces fit together well enough to know what's safe to turn off without asking first.

If you're the CTO or CIO reading this, that's the bar: you don't need my twenty years of tenure to run this playbook, but you do need the standing to say "turn it off" without a change-advisory board, and enough of the architecture in your head to trust your own judgment when something looks safe to kill.

I'm also the most in-demand person at the company, which is the annoying part — this became a late-night effort, 2-3 nights a week, for months. It took seven months to get here because I was careful. That said, I went full DOGE about it: I made myself prove a resource should exist, rather than being afraid of what might happen if it didn't.

I let AI write genuinely dangerous scripts — the kind that delete infrastructure. I did every engineering review myself before anything ran against production. My normal style includes a lot more process and more eyes than this; here it was just me, deliberately, because process is exactly what turns a two-week cleanup into a two-year one. Most of what I turned off got left off for 48 hours to see what broke. Because our most important systems are well documented, I wasn't worried about hitting anything mission-critical — but my posture was "turn it off and see what happens," not "keep it running just in case."

If I hadn't been willing to be that brazen, none of this progress happens.

For the record: I did delete one virtual PC that one developer wishes I hadn't. Minor inconvenience. Acceptable cost of the approach.

The actual stack

People ask "which AI did you use?" The honest answer is several, on purpose, split by job:

• Claude Opus and Fable — planning. This is where I worked out strategy and argued with the model about what was actually safe to cut.
• Claude Sonnet — writing the PowerShell collector and remediation scripts.
• OpenAI GPT-5.6 Sol — a second opinion on planning. I ran the same strategic questions past Anthropic and OpenAI models on purpose, because they disagree in useful ways. I was also willing to run sensitive workloads through this model because it runs ZDR with data protection promises in my Azure tenant.
• OpenAI GPT-5.4 — sensitive agent work, meaning anything touching live production resources directly.
• Cursor Composer 2.5 — agent work inside Cursor, mostly iterating on scripts vs output against non-sensitive configuration output data files.

Harnesses: Claude Code inside the VS Code IDE, the Cursor IDE, and our own AuditionAI Agent Automation Framework for scheduled, unattended runs.

There's no single "AI cost tool" in this stack. It's a set of models, each doing the job it's best at, wired into scripts I control end to end. I could have done the entire job in any of these tools, but each brings something unique to the table that let me move very quickly. I built AuditionAI, so if I had to pick just one tool for safety and comfort, I'd pick it. But Claude genuinely is some of the best planning in the business, and Cursor is fast and insanely cost efficient.

Step 1: build least-privilege collectors, not a one-off audit

Before I let any agent near a live AWS account, I had it help me scope an IAM policy down to the minimum needed to read cost and inventory data. The actual prompt:

"I need a read-only IAM policy that lets a script list EBS volumes, EC2 instances, load balancers, and S3 bucket inventory across every linked account in this AWS Organization, plus Cost Explorer read access. No write, no delete, nothing else. Write the policy JSON and explain every permission you included."

I made the agent justify every single permission before I attached the policy. That justification step is the "least privilege" part most people skip — it's tedious, and it's the difference between a read-only audit and a live incident.

The agents didn't query my data. They wrote scripts that query the data. The model never held a live credential — the scoped IAM role did, attached to a script I could read line by line before it ever ran.

Once the policy existed, I had the agent build and test the actual collector:

"Write a PowerShell script that authenticates with this role and pulls daily cost-by-service and cost-by-resource-tag data from Cost Explorer for every linked account, writes it to dated CSVs, and fails loudly if any account is unreachable instead of skipping it silently."

Then I scheduled it:

"Turn this into a scheduled task that runs every day at 6am, logs its own output, and emails me if it errors."

That's the entire "infrastructure" layer of this project — a read-only IAM role, a PowerShell script, and a scheduled task. No new SaaS tool, no dashboard product, no vendor to negotiate with.

For this entire project, I never once logged into the AWS console. I didn't even run scripts against AWS myself. Agents wrote scripts to collect the data. And when I was ready to take action, agents wrote scripts that took that action. Every touch of a live resource happened through code I could read first, not a click I made in a browser tab.

Side note, for anyone who cares about the infrastructure side of this as much as the cost side: my team is working toward 100% infrastructure-as-code, and this effort turned into a big step in that direction. Anything we spin up now is already IaC, and going resource by resource to find waste has already helped convert legacy, click-ops infrastructure into code-first infrastructure along the way.

Step 2: the daily routine — real prompts against real data

Once the daily CSVs started piling up, my routine was to open them and go hunting for anything that looked interesting. Some of the actual prompts I used, verbatim:

"Give me total daily spend on storage every day this billing cycle, compared to the same day on the previous 3 billing cycles."

"Of these EBS volumes, which ones are not attached to any running instance, and how much are we spending on each one per month?"

"Find a way to save me 50% on this bill."

That last one is deliberately blunt, and I asked it separately of all three planning models — Opus, Fable, and Sol — then compared the answers. Most of what came back I already knew: turn off idle instances, right-size, delete orphaned volumes. But each model also surfaced one or two ideas I hadn't considered, usually around tagging gaps or commitment coverage rather than exotic architecture changes.

The work was iterative because the data I had was never quite enough. When I hit a wall, the fix was another prompt, not a new tool:

"Update the daily collector script to also break out cost by availability zone for EC2, so I can see if we're paying cross-AZ transfer costs we don't need to."

Every time I asked a "why is this so expensive" question and didn't have the breakdown to answer it, I had the agent extend the collector instead of going digging through the AWS console by hand. The collector script grew for months this way — each addition earning its keep by answering a question I'd actually asked.

Step 3: every action becomes a GitHub issue, titled by the dollar amount

This is the part I'd tell anyone to copy verbatim, because it's the single highest-leverage habit in the whole project. For every finding, before touching anything, I used this exact prompt:

"Make a GitHub issue clearly outlining the objective, risk, approach, and recovery strategy for [the finding]. Title it with my estimated monthly savings up front."

Issue titles ended up looking like:

• [$620/mo] Delete 14 unattached EBS volumes in prod-east account
• [$140/mo] Consolidate 11 idle ALBs down to 1 with host-header routing
• [$1,200/mo] Stop dev/test EC2 instances nights and weekends

With hundreds of issues open, sorting by the dollar figure in the title let me triage instantly — biggest number first, every time. No spreadsheet, no project-management tool. Just GitHub issue titles doing the prioritization for me.

Every issue closed only after live verification: an actual API response showing the resource was gone or resized, not "I ran the script and it looked fine."

The morning ritual: a thermometer in the README

Every morning, before email, before Slack, before a single AWS console tab, I opened that repo and read the README.md. At the top was one goal and one bar, updated by the same daily collector run:

That's it. No dashboard, no BI tool, no weekly deck for an audience of one. A goal, a bar, and a number that moved when I did the work and sat still when I didn't.

That thermometer is what got me back at the keyboard at 11pm on a Tuesday. It's easy to lose motivation cutting a bill nobody else is watching. It's much harder to ignore a bar that's stuck exactly where you left it because you skipped a week.

What the early wins actually looked like

• Disconnected EBS volumes — hard drives spinning in the cloud, attached to nothing, billing us every hour. Hundreds of dollars a month, no application dependent on them. Delete.
• Right-sizing after metrics, not guesses — 30 days of CloudWatch data before touching any instance size. Some "obvious" downsizes turned out not to be safe once I actually looked at the numbers.
• Scheduling instead of 24/7 — EventBridge Scheduler to stop dev boxes at night, weekday stop/start windows, off-hours resize on production where the workload allowed it.
• Consolidating redundant infrastructure — one VPC had 11 load balancers fronting 3 EC2 instances with near-zero traffic. One ALB with host-header routing replaced the pile.
• S3 surgery — stale backup prefixes, versioned deletes, orphaned multipart uploads, lifecycle policies.
• Terminating idle compute — instances with no purpose left, dev environments nobody remembered to shut down.

Seven months later: the numbers tell the real story

In the first few months, individual issues were saving us $800–$1,200 a month, each. Single findings, single issues, four figures a month, over and over.

Now, seven months in, my open issues read [$0.50/mo] and [$15/mo]. The dollar-in-the-title trick still works — it's just telling me the truth, which is that I'm scraping the bottom of the barrel. Every remaining issue takes real digging for a fraction of what the early ones took minutes to find.

Current work looks like:

"Scale these servers down more aggressively when they don't need this much compute" — pushing past the safe, obvious right-sizing pass into workloads where the margin is thinner and the risk calculus is harder.

"Let's get smarter about our 2-3 year compute commitments" — Reserved Instance and Savings Plan coverage, where the savings are real but the analysis is slower and the cost of over-committing is higher than the cost of under-committing.

This is the part nobody warns you about going in: the graph of dollars-saved-per-issue is a steep curve down, and you will spend as much time on the last 10% as you spent on the first 50%.

What I'd tell a CTO or CIO staring at a big AWS bill

You don't need a FinOps team on day one. You need:

• A private place to work — repo, issues, evidence.
• Least-privilege, daily, read-only collectors across the whole org, built and scheduled by an agent, not bought as a platform.
• A stack of models split by job: planning models you can argue with (Opus, Fable, Sol), a script-writing model (Sonnet), an agent harness for the sensitive, hands-on-resources work (GPT-5.4), and a separate harness for iterating on non-sensitive config and script output (Cursor Composer 2.5).
• A habit of literal prompts: "give me X compared to the last 3 billing cycles," "find a way to save me 50% on this," "update the collector to break out Y."
• A discipline for every action — objective, risk, approach, recovery strategy — captured as a GitHub issue, titled with the dollar amount, so triage happens automatically.
• An explicit rule: low-hanging fruit first, and an honest expectation that the fruit gets smaller every month you keep going.

AWS cost reduction isn't one audit. It's a daily habit, run with real prompts against real data. The bill is a to-do list. The first items are ugly and easy. The last items are subtle, slow, and worth doing anyway.

You don't need to be the Founder to run this. You need the standing to say "turn it off," a place to keep score, and the willingness to ask an AI the blunt question — "find a way to save me 50% on this" — and actually act on what comes back.