Cloud bills do not grow because somebody decided to spend more. They grow because every individual decision to spend more was reasonable, and nobody was assigned to look at the total.
That is the whole mechanism. A consultant spins up a server for a project. A developer needs a staging environment. Someone sizes a database for launch day and picks the tier above the one they think they need, because being slow on launch day is a visible failure and being oversized is not. Each of those calls is defensible. Three years of them is a number nobody can explain.
Nobody owns the bill
When I ask a growing company who owns the cloud spend, the honest answer is usually nobody. Not finance, who sees an invoice and has no way to tell which line items are load-bearing. Not engineering, who can account for what they built and not for what the contractor before them built. The invoice gets paid because it is assumed to be the cost of running the business.
On one estate I picked up, spend was a five-figure monthly number split across two clouds. There was no villain in this story. Various consultants and developers over several years had each spun something up, and nothing had ever been decommissioned, because decommissioning is nobody's job until you make it somebody's job.
It is the same gap that produces unclosed audit findings and unanswered customer questionnaires, and it is one symptom of the technology stage most growing companies skip. The work is not hard. It is unassigned.
Tier one: things nobody turned off
Start here, because it is fast and it funds the rest of the work.
On that estate, one of the two clouds was full of legacy servers doing nothing at all. Shutting down the easy ones returned the clear majority of that cloud's bill on its own. That is the engagement paying for itself almost immediately, and it required no architectural judgment - only somebody willing to establish what each machine was for and turn it off when the answer came back nothing.
The reason this sits there for years is not laziness. It is that turning off a server you do not fully understand is frightening, and nobody wants to be the person who caused the outage. So the machine stays up, indefinitely, at whatever it costs. Somebody senior has to be willing to make that call and carry it.
Tier two: sizing chosen once and never revisited
This is where the real money usually is, and where a cost tool will not help you.
A database on that estate had been provisioned at the maximum performance tier its cloud offered. The reason was that the website had been getting slower for years, and the response each time was to buy more hardware. It worked, in the narrow sense that the site stayed up, and it cost thousands of dollars a month.
The site was not slow because it was under-provisioned. It was slow because it was missing indexes. Half a dozen of them. Adding those dropped CPU utilization by most of its previous value on the same hardware. At that point the instance was absurdly oversized, so it came down to a fraction of its provisioned capacity, and not one user noticed a difference.
Nobody involved had been careless. Adding hardware is a decision an infrastructure person can make alone in an afternoon. Adding the right indexes requires somebody who can read a query plan and knows what the application is doing to that database. That person did not work there.
Tier three: architecture you have outgrown
The slowest and largest tier is the one where the platform itself is why the bill is high.
Two examples from the same estate. The application runs on a legacy Windows-only runtime, which means it cannot run on a Linux container service. So it runs on VMs, and VMs cost a multiple of the equivalent container platform. The runtime is the cost driver, and no amount of rightsizing touches it. Rewriting those services onto a modern stack removes a large recurring line item outright.
The other is a commercial database being paid for at commercial-database prices to run a workload that uses none of the features you buy one for. An open-source engine does that job. The license is the line item, not the compute.
Neither of those is a cost optimization exercise. They are engineering projects that happen to have a cost payoff, and they only surface when somebody who can read the application is looking at the invoice at the same time.
Scope them like engineering projects too. A runtime migration or a database platform change sold internally as cost savings gets funded on the savings number and staffed on nothing else, which is how a platform migration ends up stalled with the old system still running and still billing.
It takes four people, not one
This is the part most cost reviews get wrong, and it is why they plateau right after the easy wins.
A cloud bill has at least four distinct domains inside it: application, infrastructure, network, and database. Each one takes genuine expertise to optimize, and the expertise does not transfer between them. A network engineer cannot tell you which indexes are missing. A database specialist will not spot that your runtime is forcing you onto the wrong compute product. An application developer generally knows very little about infrastructure and security, and should not be guessing at either.
Hand a cost review to any one of those people and you get back the savings visible from where they are standing. That is usually tier one, sometimes part of tier two, and essentially never tier three. Getting all of it takes somebody who can move across all four, or a small group that covers them between them, working from the same bill.
What not to cut
Not everything that looks like waste is waste, and the failed proof of concept is where I see people over-correct.
A POC that did not pan out gets deleted wholesale, on the reasoning that it did not work so it should go. Kill the running infrastructure, absolutely - that is a tier one item and it should be gone the week the POC ends. But keep the code in version control. It costs nothing to retain, and it is a record of a problem somebody already thought hard about, against your data, in your domain. That has become a good deal more valuable now that AI tooling can read an old codebase and get something useful out of it. You never know when it will find the thing.
Delete the compute. Keep the source.
Order of operations
Turn off the dead things first, because it funds everything after it and it proves to the people paying that the exercise is real. Then go after sizing, with somebody who can read the database and the application rather than only the utilization graph. Then decide which architectural changes have a payback period short enough to justify themselves, and run those as engineering projects with a business case rather than as cost cutting.
Then give the bill to somebody, permanently. A cost audit is a one-time recovery of money that should never have accumulated. If the ownership gap that produced it is still open when you finish, you will be running the same exercise again in three years, on a bigger number.