Cloud bills shock people because nobody watches the meter while it runs. Cost Explorer will tell you the truth sooner or later, but out of the box a spike shows up at month end, on the invoice, weeks after whatever caused it started running. Someone tries a new instance type and leaves it on overnight. A service quietly scales past its usual ceiling. Something lands in a region nobody meant to use. Each is a tiny choice that later becomes a line item nobody can explain.

So we gave the job to an agent on Machine. It checks AWS spend every day in one long-running session that remembers what "normal" looks like for each service and each account. It only reads billing data. Its single output is a Slack alert showing how far spend moved and its best guess at why. That's how we catch a cost problem when it's a day old instead of an invoice old.

The problem

Spend is easy to look up and hard to keep an eye on. Ask Cost Explorer what you spent over any period and it will answer. What it won't do is speak up on its own to say one service cost 40% more yesterday than it usually does. Nobody opens the console each morning to scan forty line items across a dozen accounts, so a spike keeps running up the bill until someone spots the invoice.

The standard fixes leave a gap. A monthly budget alert only fires once the total for the month crosses a line, and by then you've overspent many times over. A single fixed threshold per service treats one that usually costs $50/day the same as one that usually costs $5,000/day, so it ends up either shouting all the time or missing things. And none of these tell you why. A dashboard shows that the number changed, not what changed it.

What we built

A daily timer on Machine wakes the same long-lived agent session each time, with read-only access to AWS Cost Explorer. It pulls yesterday's spend, split by service and by linked account, and updates its running baseline for each pair. Then it flags anything that leaves its usual range. That isn't one fixed threshold. It's a departure from what this exact service in this exact account normally costs. For every anomaly it works out the likely cause (a resource that just launched, a surge in traffic, spend in a region that had none before) and posts a single alert to Slack with the change and the suspected cause. AWS gets nothing written back: no resource is touched and no budget is changed.

How it works

The pattern

A daily cron reopens one long-lived session with a read-only connector into AWS Cost Explorer. The baseline is kept in skills and memory and carries over from one run to the next. The agent reads everything, and the Slack alert is the only thing it writes.

Guardrails

This agent can see billing for every linked AWS account, so its access is narrow and only ever flows one way:

• Isolation. Each run happens in its own sandbox. The session can reach only AWS Cost Explorer, and the Slack alert is the only thing that leaves it.
• Scoped secrets. The AWS credential is stored encrypted in the Secrets Manager, delivered into the sandbox when the run starts, and only handed to the agents you grant them to.
• Read-only, no exceptions. The AWS connector can only read. The agent can't launch, change or delete a resource, and it can't alter a budget or any spending control. Alerting is its whole job.
• Alert only. A Slack post is everything it produces. There's no automatic fix, no change to auto-scaling and no resource shut down. A person decides what, if anything, to do about a spike.
• Everything is code. The baseline logic, the thresholds and the permissions for each system are files in your repo. They're versioned, and you change them through a reviewed change request, not a dashboard toggle.

The outcome

A cost problem that once turned up as a baffling line item at month end now turns up the next morning, already labelled with the service, the account, the size of the jump and a likely cause. The agent reads and alerts. Your engineering team decides what to do about each one.