NOTE No. 001PHASE 03 · BUILD18 MAY 20266 min read

The cloud bill nobody owned

Cloud spend goes wrong the same way in every company we have seen: it belongs to finance, who cannot change it, and not to engineering, who can.

01The situation

The bill arrives once a month, in finance. Finance can see that it went up. Finance cannot see which change made it go up, because the bill is organised by cloud service and the work is organised by feature.

So the conversation becomes a request to “look at the cloud costs”, which lands on an engineer who has no way to connect a line item to anything they did, and who is also mid-sprint. Nothing happens. Next month the number is bigger.

02What we found

In every system we have picked up, the first pass finds the same three things, in the same order.

Non-production environments running at full size, around the clock, including at four in the morning on a Sunday. Storage nobody has looked at in two years, still on the fastest and most expensive tier. And instances sized for a launch-day traffic estimate that turned out to be four times too high, which nobody has revisited because nothing forces you to.

FIG. 1 — The cheapest optimisation available to most teams is a scheduler.

03What we did

First, attribution. Every resource gets tagged with the service it belongs to and the environment it is in, enforced at creation so it cannot drift. That alone changes the conversation, because now the bill can be sliced the same way the team is organised.

Second, a schedule. Test and staging environments come up in the morning and go down in the evening. It is the least clever change on this list and it is usually the largest single line on the invoice.

Third, a budget with an alarm on it, per service, routed to the engineers rather than to finance. Not a monthly report. An alert, the same week, to the people who can actually act on it.

Cloud spend belongs to the people who can change it, not the people who receive the invoice.

04What changed

Cost stopped being a surprise and started being a number with an owner. When a change makes the bill jump, it is caught in the same week rather than the next quarter, which is the difference between a five-minute fix and an archaeology project.

The cultural change is the same one as with alerts: once spend is visible per service, engineers optimise it without being asked. Nobody enjoys owning the most expensive box on the board.

05What we would do differently

We used to do the rightsizing first, because it feels like the real engineering. It is the wrong order. Without attribution you cannot prove the saving held, and a saving nobody can prove gets quietly undone.

Tag first, schedule second, resize third. The boring order is the one that sticks.