The review that does not look at the bill
An infrastructure change is reviewed for security, for naming, for style. Almost never for its effect on the bill. And yet a change of instance size, an additional replica or faster storage can add hundreds of euros a month with one line of code.
That cost shows up weeks later, in a report nobody connects any more with the change that caused it.
The estimate in the same place as the plan
Since the plan already knows which resources are created, modified or removed, and at what size, public prices can be used to calculate what each will cost. The estimate is added to the change review:
- Monthly cost before and after, and the difference.
- A breakdown by resource, to see what explains the rise.
- Usage assumptions when cost depends on traffic or volume.
What changes in practice
Decisions are made with the figure in front of you. 'This replica adds €300 a month' opens a useful conversation: do we need it yet?, would a smaller one do?
Thresholds get set. A change that raises cost above a certain amount requires additional approval, just like a destructive one.
The loop closes with FinOps. Each change's estimate is the expected budget; the cost pipeline then measures the real figure. If the difference is large, one of the assumptions was wrong and there is something to learn (the same idea as in cost as a design requirement).
What it is not
The estimate is not the bill. It knows nothing of negotiated discounts or commitments, and real usage may be different. Its value is not accuracy, but that cost is visible while there is still a decision to make.
With the infrastructure's code under control, the other half of the problem remains: that each server, once created, carries on being the one it should be.
How we apply it: Automation and IaC.