Automating AWS Cost Optimization with an AI Agent: From Monthly Audits to Daily Savings

On the 3rd of the month, someone exports last month's Cost Explorer data and notices NAT gateway charges doubled. The traffic that caused it started on the 9th of the previous month. It billed for 24 days before anyone looked, and it will bill for another week or two while a ticket finds an owner. Nothing about the audit was wrong. It was just late, the way monthly audits always are.

Part one mapped the seven places AWS bills leak. Part two audited all seven with native tools: Cost Explorer, Trusted Advisor, Compute Optimizer, CloudWatch and the CLI.

If you ran that audit, you have a findings document and a problem. The audit took hours, the findings started decaying the moment you exported them, and every fix still needs a ticket. Meanwhile waste regenerates daily: every deploy can orphan a volume, every scale-up can open a coverage gap. Monthly audits against daily waste is a race you lose.

This part covers the step after: how CloudThinker Optimize runs the same seven checks continuously, what its first analysis of a typical account looks like, and what it won't do without your approval.

Why the audit can't keep up

Part two's audit has four limits, and none of them is effort. It's a snapshot of one day. It costs engineer hours every time, so monthly drifts to quarterly. Its findings decay as traffic shifts. And it ends at a ticket, not a fix.

The deeper problem is the judgment step. Each finding needs verifying before anyone acts: is the instance idle or just quiet between batch runs, does anything restore from that snapshot, who owns the load balancer. That verification is what gets skipped when the audit runs long, and skipping it is how a rightsizing ticket turns into an incident. Doing it faster requires the same evidence, gathered by something that doesn't get tired at finding forty.

Connecting AWS: a read-only IAM role, about five minutes

01Your account

AWS

Cost Explorer and Savings PlansSpend, usage types, coverage, utilization
Compute Optimizer and Trusted AdvisorRightsizing and pre-built cost checks
EC2, EBS, RDS, ELB, VPC, CloudWatchInventory and the metrics behind it

Read-only cross-account role

02Optimize

CloudThinker

Scan every region dailyAll seven leaks from part one
Verify before reportingSpikes, memory, owners, dependencies
Propose the fixSaving as a range, with rollback notes

No agents on instances

03Where the team works

Chat and tickets

Slack or TeamsFindings and approvals in the thread
JiraOwned follow-ups with the evidence linked
Audit trailWho approved what, and what changed

Nothing new to watch

The same APIs you used in part two, called every day instead of every quarter.

Optimize connects to AWS the way your security team would insist on anyway: a cross-account IAM role with read-only permissions. No agents on instances, no long-lived credentials stored, no write access at connection time. You create the role from a provided template, paste the role ARN, and the first scan starts. The connection guide has the exact policy JSON, so your security review can see precisely what is and isn't granted.

Continuous scanning of all seven leaks

Once connected, the agent runs the checks you ran by hand in part two, continuously and across every region:

Unattached EBS volumes and orphaned snapshots
Idle or oversized EC2 instances (low CPU over 30 days)
Reserved Instance and Savings Plans coverage gaps
Unused Elastic IPs and idle load balancers
Over-provisioned RDS instances
Data transfer costs (cross-AZ, NAT gateway)
Non-production environments running 24/7

The checks aren't the difference. The cadence is. A volume orphaned on Tuesday is a finding on Tuesday, not a line in next quarter's audit. Each finding carries the evidence you'd have gathered yourself: the metrics window, the current cost, and the projected saving as a range.

01Detect

Cost moves

A usage type, a resource or a coverage ratio changes in the daily data.

02Explain

Trace it

Down to the resources, the metrics and the change that started it.

03Judge

Verify

Rule out the readings that would make the fix wrong: spikes, dependencies, owners.

04Output

Proposal

One fix, its saving as a range, how to roll it back, and who must approve.

Step three is the one the manual audit skips when it runs short on time.

One finding, investigated

Here's the NAT gateway jump from the opening, the way CloudThinker works it. The details are illustrative.

On the 10th, daily NatGateway-Bytes cost in us-east-1 is up 2.4x against the previous 30-day average. Three readings fit, and each predicts different evidence:

S3 or DynamoDB through the NAT. Predicts a VPC with no gateway endpoint and a new workload reading from S3.
Cross-AZ routing to the NAT. Predicts private subnets in one AZ routed to a NAT gateway in another, with matching inter-AZ charges.
New internet egress. Predicts a service calling an external API or pulling from a public registry.

Which NAT gateway? Bytes processed by gateway (BytesInFromSource plus BytesInFromDestination, since processing is billed both ways) shows one NAT in vpc-0abc carrying almost all of the increase, starting the 9th. Inter-AZ charges didn't move, which makes the second reading unlikely.

Is there an S3 endpoint?

aws ec2 describe-vpc-endpoints \
  --filters Name=vpc-id,Values=vpc-0abc Name=service-name,Values=com.amazonaws.us-east-1.s3 \
  --query 'VpcEndpoints[*].{ID:VpcEndpointId,Type:VpcEndpointType,State:State}'

Empty. vpc-0abc was created on the 8th for a new data pipeline, from a template that doesn't add endpoints. The pipeline's role reads from three S3 buckets. VPC Flow Logs aren't on for that VPC, so the destination can't be proven to the byte. The timing and the missing endpoint make the first reading the strong one.

One more check before proposing. Gateway endpoints change the source address S3 sees, from the NAT's public IP to a private one. Any bucket policy that allows access by aws:SourceIp would start denying the pipeline. CloudThinker reads the three bucket policies: none uses aws:SourceIp.

The finding, posted in the FinOps channel:

NAT gateway in vpc-0abc: S3 traffic, add a gateway endpoint. About 14 TB a month of pipeline reads from S3 are going through the NAT since the 9th, roughly $630 a month at $0.045/GB. The VPC has no S3 gateway endpoint. Bucket policies don't depend on source IP, so the change is safe for access. Proposed: create a free S3 gateway endpoint on the two private route tables. Rollback: delete the endpoint. Needs approval from: the platform team, which owns vpc-0abc.

The command it would run, once approved:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0priv1 rtb-0priv2

Found on day two instead of day 25, with the access risk already checked.

You decide what the agent may touch

CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval. Commitment purchases (Savings Plans, RIs) and production resizes are the obvious ones to keep behind an approval.

Every action lands in an audit trail: what was found, what was proposed, who approved, what changed and when. Your part-two audit skills aren't wasted. You review the same evidence, minus the hours of collecting it.

What the first analysis typically returns

These numbers are illustrative, a composite of what a first scan tends to surface on a mid-market account around $60K a month. Your account will differ.

Finding	Detail	Est. monthly impact
Unattached EBS volumes	23 volumes, 4.1 TB, oldest 14 months	~$380
Orphaned snapshots	1,900 snapshots past any plausible retention	~$640
Idle or oversized EC2	14 instances under 10% average CPU over 30 days	~$3,100
Savings Plans gap	Coverage at 41%, stable baseline supports ~75%	~$4,800
Elastic IPs and idle ALBs	11 unassociated Elastic IPs, 3 ALBs at near-zero requests	~$110
Over-provisioned RDS	2 db.r5.2xlarge at 8% CPU, candidates for db.r5.xlarge	~$1,050
NAT gateway traffic	18 TB a month, mostly S3, VPC endpoint candidate	~$1,300
Non-prod running 24/7	Staging and dev fleets, no schedule	~$5,200

That's roughly $16,500 a month identified on day one, about a quarter of the bill, before deeper architectural items. Look at the shape: two boring rows (Savings Plans coverage and non-prod scheduling) dominate, which matches what you'd find by hand. The value isn't exotic findings. It's that the table refreshes every day, and each row arrives with a verified, approval-gated fix.

Why this beats the traditional approach

	Monthly or quarterly audit	Optimize on top
When waste is found	Weeks after it starts	The day it shows up in the data
Verification	Done when there's time	Done for every finding, written down
Engineer time	Hours per audit	Minutes per approval
From finding to fix	A ticket that needs an owner	A proposal routed to the owner
Changes	Manual, untracked	Gated by Auto Mode, fully audited

The deeper difference is where the hours go. In the audit, most of the time goes to collecting evidence and too little to judging it. With the agent collecting, your time goes to the decision.

Prompts to try in your first session

Optimize is conversational. Ask in plain language, and each answer cites the underlying data (the same Cost Explorer and CloudWatch evidence from part two), so you can verify it rather than trust it.

"Analyze spending trends over the last quarter and flag anything growing faster than 10% month over month. Explain each one down to the resources."

"Find unattached volumes and unused Elastic IPs across all regions. Propose only, change nothing."

"Recommend Savings Plans purchases for our stable workloads, with the break-even point and what happens if usage drops 20%."

"Which non-production resources ran between midnight and 6 a.m. last week, and what would a business-hours schedule save?"

"Estimate what a gateway VPC endpoint for S3 would save on our NAT gateway costs, and check whether any bucket policy depends on source IP first."

What the agent won't do

"AI agent with access to prod" should make you ask. Here are the answers.

Read-only by default. The connection role grants no write permissions. Remediation needs scoped write access you grant explicitly, and every write goes through Auto Mode.
No deletes, resizes or purchases you haven't allowed. Whether a change runs on its own or waits for you is set in Auto Mode.
Nothing outside the audit trail. Every proposed and executed action is logged with its evidence and approver.
No architectural decisions. It will tell you the NAT gateway is carrying 18 TB of S3 traffic. Whether to re-architect the VPC is an engineering decision, and it stays yours.

If you did the part-two audit by hand, the right mental model is that audit running daily, with a remediation queue attached. It isn't an autopilot you hand the keys to on day one.

From audit to habit

You know where AWS bills leak. You know how to audit every leak with native tools. What's left is cadence, and that's an automation problem, not an effort problem. Teams that move from monthly manual reviews to continuous, approval-gated optimization typically reduce their AWS bill by 30 to 50% over the following months, with the biggest wins from coverage and scheduling.