Knowing what changed your cloud bill, and why
A ranked diff of two Cost Explorer periods.
Cost Explorer will show you this month and last month grouped by service, and will not tell you what changed, ranked, which is the only form of the answer anyone wants. cost-diff subtracts two periods, ranks by money moved rather than percentage, flags services that appeared from nothing, and renders a report you can read in fifteen seconds. Its numbers reconcile with the invoice because they are the provider's own.
The problem
The bill went up by $2,550 last month. Somebody in finance asks why, and an engineer spends twenty minutes in the console assembling a partial answer: exporting two periods, or finding the comparison view, then working out which services moved and whether SageMaker is new.
Because the answer costs that effort, it is produced when somebody asks rather than routinely, and that is the failure that matters. An increase noticed in month one is a conversation with the person who made the change, while they still remember making it. The same increase noticed in month four is archaeology: the deploy that caused it is forty deploys back, the person who shipped it has moved teams, and the spend has been in the budget long enough that removing it is now a project rather than a revert.
Cost increases are absorbed one change at a time, each too small to justify an investigation. Compounded across a year they are the reason the bill grew 40% and nobody can say which decisions caused it. The data was there the whole time, correct and queryable. What was missing was a report that arrived without anyone having to go and get it.
The method
A cost report succeeds if somebody reads it and acts, so several of the decisions below trade analytical depth for readability.
Rank by absolute impact. The report sorts by dollars moved. Percentages are shown alongside, because a 38% rise in EC2 reads differently from a 4% one at the same dollar value, but they never drive the order.
Mark new spend. A service that was $0 and is now $400 has an undefined percentage change. It is also, nearly always, the most important line in the report: a service appearing from nothing means somebody started using something, and unbudgeted spend enters a bill that way. It is marked (new) rather than filtered out as a division by zero. A service that disappeared has a defined change and shows as an ordinary −100% row. Letting new spend fall through a percentage filter is how surprise SageMaker and NAT-gateway bills survive long enough to become annual costs.
Truncate by default, and say so. A bill has dozens of services and almost all of them moved by a few dollars. The table shows the ten largest movements (--top N changes that), and when more rows qualify it ends with a line saying how many were not shown. Changes smaller than --threshold (default $1) are excluded before ranking.
Make the comparison axis a flag. --group selects any of four Cost Explorer dimensions:
With --group SERVICE, --why adds a usage-type breakdown of the single largest mover, at the cost of two more calls.
Make the period arbitrary. --last-month is the convenience path; --period 2026-06 --vs 2026-03 compares any two months, which turns the same tool from a monthly autopsy into a quarterly growth review.
Deliver where the conversation already happens. --slack "$SLACK_WEBHOOK" posts the report as Slack blocks. There is no dashboard, because a dashboard is a place somebody has to remember to visit.
Stay small enough to audit. One Python file, one IAM permission (ce:GetCostAndUsage), and an injectable Cost Explorer client so the tests never touch the network. A tool that runs against a billing account with credentials in the environment should be quick to read before you trust it.
The headline results
- What is reported is the provider's per-group figures, filtered and ranked.
- Ranking is by absolute delta; the percentage is context.
- Truncation is on by default and announced.
- The cost of the tool is disclosed.
- What the tests assert.
The full results, with the tables and the reasoning behind each figure, are in the PDF.
What is in the PDF
- The problem — what goes unanswered without it, and who notices first.
- Why the obvious alternative falls short — stated plainly, including where it is the better choice.
- How it works — the method, not a feature list.
- Concrete use cases — with console output quoted from the repository, never reconstructed.
- The methodology behind any number it emits — every term shown, so the figure survives a question.
- What it deliberately does not do — the section most papers leave out.
Part of the Cost & FinOps theme.
Get the PDF
This paper already selected; the download starts when you send the form. No follow-up sequence.