Cloud cost intelligence

The leak

The company's cloud bill ran to eight figures a year, and no one could say with confidence what any given part of it was for. Finance saw a total that grew every month. Engineering saw a console with hundreds of resources and no way to connect them to a product or a team. The two numbers did not reconcile and neither pointed at a decision anyone could take.

Underneath the total, the usual leaks: machines sized for a peak that never came, running at a fraction of their capacity; environments nobody had switched off; reservations that would have cut the rate substantially, never purchased because nobody owned the question; cost spikes from a misconfiguration that sat unnoticed until the invoice arrived.

The constraint

Spend was spread across shared subscriptions with almost no tagging. A resource could not be tied to a product or a team without first doing the work of attribution, and attribution is a conversation with people, not a query. Finance and engineering used different categories, so any analysis had to speak both languages. And every recommendation had to survive a meeting with the team that owned the machine, which meant it needed utilisation evidence beside it, not a hunch about what looked expensive.

The infrastructure also could not be touched by the analysis. Read-only access was the condition, which turned out to be the right constraint: it kept the system an advisor and kept the decisions with the owners.

The system

The first step was visibility: read-only access across the whole account, including reservations, utilisation metrics and billing exports, so the analysis worked from the real data rather than from spreadsheets exported by hand.

On top of it, a set of views built for one decision each. Which machines are under-used or over-provisioned, with their actual utilisation shown beside their size, so the conversation starts from evidence. Which resources should be reserved, and which should not because their usage is too variable, with the saving quantified for each. What changed in cost since yesterday, as a daily alert, so a spike becomes a question the same day rather than a surprise on the invoice. What next month will cost, predicted from the trend, day by day and month on month. A savings tracker that records what was recommended, what was acted on, and what it returned, so the programme carries its own proof.

Alongside the analysis, a tagging drive: every resource listed, every owner asked to tag it to a product and a team, and a view of what remains untagged so the drive finishes. Attribution is what turns a recommendation into a decision, because it puts the machine on someone's desk.

And a natural-language layer over all of it, so a question about the bill gets an answer in a sentence, with the numbers behind it, without opening a dashboard. Each section also carries a written summary, regenerated as the data changes, for the people who want the conclusion rather than the chart.

The number

A seven-figure monthly saving from one resource class alone, with further classes in progress and tracked in the same tool. The daily alert has caught cost changes within a day of them starting. Potential savings are identified and quantified continuously rather than in an annual exercise.

What I would do differently

Tag first. The attribution drive ran after the first analysis, which meant the first recommendations went to a room where nobody was sure whose machine it was. With owners named up front, every recommendation lands on a desk and the saving is booked faster. I would also set the daily alert threshold with finance in the first week, so the alerts are the ones they care about from the start.