A cloud bill is one of the few numbers in a company that only ever goes up, and almost no one is asked to defend. It grows by accretion — a bigger instance here to fix a latency scare, a copy of production data there for a test that finished a year ago, an autoscaling floor set high during a launch and never lowered. Individually each decision was reasonable. Together they routinely add up to a bill that is two to three times what the workload actually needs. The good news is that reclaiming most of that waste requires no architectural heroics and no freeze on shipping features.
Where the money is actually hiding
Before touching anything, it is worth naming the usual suspects, because cloud waste is remarkably consistent across companies. The largest line is almost always compute that is provisioned for a peak that either never comes or comes for twenty minutes a day. Close behind is storage that no lifecycle policy ever touches — snapshots of snapshots, logs kept forever, data that could sit in cold storage at a tenth of the price. Then there is the staging and pre-production estate, which is frequently a full-size mirror of production running twenty-four hours a day to serve a team that works eight. And finally the quiet killers: data egress and cross-zone traffic, which never appear on an architecture diagram but can be a fifth of the bill.
The checklist, in order of return
We work the problem in roughly the order that returns the most money for the least risk. First, right-size compute against real utilisation data, not the size someone picked at 3am during an incident. Most instances are running at a fraction of their capacity; matching the instance to the actual load is the single biggest lever and carries almost no risk. Second, make scaling honest — set autoscaling floors to what the workload needs at its genuine minimum, and let it grow when it must, rather than paying for peak capacity around the clock. Third, put a lifecycle on storage: expire old snapshots, tier cold data down, and delete the things no one will ever read again. Fourth, shut the staging estate off when no one is using it — a scheduled shutdown of non-production environments overnight and at weekends can remove more than half their cost on its own. Fifth, once the obvious waste is gone and usage is predictable, commit to it with savings plans or reserved capacity for the baseline you now know you need.
Why it does not require a freeze
None of this asks the product teams to stop. Right-sizing, storage lifecycle, and scheduled shutdowns are operational changes that happen alongside normal delivery; they touch how the system is run, not what it does. That is the whole point of doing it this way. A "cost optimization project" that halts the roadmap for a quarter usually costs more in lost momentum than it saves on the bill, and it teaches the organisation that saving money and shipping features are enemies. They are not. The discipline is to treat cost as an operational property of the system — something you measure and tend continuously — rather than a crisis you periodically declare.
Making sure it does not creep back
The uncomfortable truth is that a one-time cleanup will fully reverse within a year if nothing changes about how the organisation works. Costs creep back the same way they arrived: one reasonable decision at a time, with no one watching the total. The fix is not another audit; it is visibility. Cost should be attributable to teams and features, so the people making the decisions can see the consequence. A dashboard that shows spend by service, an alert when a line item jumps, and a quick monthly look at the biggest movers is enough. The goal is not to make engineers frugal — it is to make the cost of a decision visible to the person making it, at the time they make it. Once that feedback loop exists, the bill stops being a surprise, and the 40-70% you reclaimed stays reclaimed.