The answer fits in one sentence: the cloud budget is carried by the team that can move it, which is the team that deploys, with a named counterpart in finance and a monthly review. If that name was not written down before the cutover, it does not exist at month 6 — and the invoice keeps arriving all the same.
Why month 6 and not month 2
The first months are not a problem, because everyone knows why the bill is going up. The old and the new platform run side by side, capacity is oversized to de-risk the cutover, and test environments exist that never existed before. It is accepted, it is temporary, and it is funded as project spend.
By month 6, three things have happened at once. The dual run is over, so the surplus that was tolerated no longer has an explanation. The first capacity commitment decisions come up, and taking them or not is a budget call before it is a technical one. And the project team has disbanded: the people who knew why a given database was sized the way it was have moved on. The cost, meanwhile, has quietly become recurring without anyone signing up for it.
The three owners we get offered
When we ask the question in a steering meeting, the answer nearly always falls into one of three boxes. None of them holds on its own.
- Finance. It sees the amount without seeing what produces it, and it holds no direct lever: moving money between two rows of a spreadsheet does not change an instance size.
- The IT department, broadly. A budget carried by everyone is carried by no one. A figure consolidated at management level never travels back down to the technical decision that would move it.
- The provider. It optimises what it operates, and that already counts for a lot. It does not get to decide on your behalf that a staging environment shuts down overnight, or that an application nobody opens any more is switched off.
What works is an explicit split rather than a single owner: the team that deploys carries the number, finance carries the trajectory and the challenge, the operator carries the measurement and the tooling. Three roles, three names, one meeting a month.
What makes a budget genuinely carryable
- A breakdown that maps onto a real team. As long as the bill is a single number for the whole company, nobody can act on it. Separate accounts per domain, or tagging enforced at resource creation: either one works, having neither does not.
- An unallocated share that is measured and shrinking. There will always be some: shared networking, the platform layer, logging, backups. What matters is knowing it and bringing it down, not spreading it pro rata so the spreadsheet looks tidy.
- A figure the team sees without having to ask for it. An amount you have to request from someone is an amount you look at once a quarter, which is too late to act on.
- A mandate to act. The owner has to be able to switch off, resize and delete within their scope without convening a committee. Without that mandate they observe a drift; they do not carry a budget.
What we look at first
On the estates we take over under cloud managed services after a migration, the order is almost always the same, because it runs from the reversible towards the binding. First what runs without serving anything: non-production environments left on at night and over the weekend, volumes detached from any machine, backups with no retention policy, reserved IP addresses that were then forgotten. Then sizing, once there are weeks of real metrics to work from rather than the assumptions in the migration plan. Only then term commitments. Taking those first is the most expensive mistake we see: it locks in a footprint that has not been corrected yet, and turns a drift into contracted spend.
None of these levers is new, and that is not the point. We have set them out in five levers for cutting your cloud bill and, on the AWS side, in day-to-day cost management. What is missing at month 6 is not the list of levers; it is the name of the person who decides to pull them.
The signs nobody is carrying it
- The bill is only discussed in a quarterly meeting, from an export reworked by hand.
- Nobody can say, without going away to investigate, what explains last month's variance.
- The word “optimisation” only comes up after an overrun, never inside an architecture decision.
- Every request to shut an environment down lands on the same person, and that person is swamped.
Decide it before, not after
The right moment to name the budget owner is while the migration is being designed, when the account layout and the tagging convention are still a choice rather than something to retrofit. At that point it fits inside one meeting; six months later it is a project of its own. If you are already at month 6, the sequence is the same in reverse: rebuild the breakdown, name the owner, and only then measure and arbitrate.
For what the practice covers in concrete terms, see our FinOps offer, and if the question is first about the estate being operated, our consulting and audit.