Cloud cost management: the four controls that actually reduce the bill

Start with what you can measure

You cannot negotiate a bill you cannot attribute. The first control is allocation: every resource gets an owner, an environment and a cost centre at creation, enforced by policy rather than convention.

Commitment coverage before discounts

Most accounts chase percentage discounts while running less than half of their steady-state workload on commitments. Measure coverage first: the target for a stable estate is 70 to 80 percent of baseline compute under a one or three-year commitment.

Right-sizing is a weekly habit, not a project

Instance recommendations go stale within a fortnight. Put the top twenty services by spend on a weekly review, and require a written reason to keep a resource below 20 percent utilisation.

Egress and storage classes

Data transfer and cold storage tiers are where unpredictable invoices come from. Review egress paths quarterly, and set lifecycle rules on anything not read in ninety days.

Showback versus chargeback

Showback reports the cost; chargeback moves it onto the business unit’s budget. Showback changes behaviour slowly and survives politics; chargeback changes it immediately and creates an incentive to hide usage. Most organisations should run showback for two quarters before introducing chargeback, and always with a shared-services pool for networking, identity and observability, which no team can attribute cleanly.

Storage lifecycle rules that pay for themselves

Three rules cover most of the waste: transition objects unread for ninety days, delete incomplete multipart uploads after seven days, and expire non-current versions after thirty. The last two are the ones nobody sets, and they quietly account for a surprising share of the bill in accounts with heavy automation.

Kubernetes and the shared-cost problem

A cluster’s bill is one line item and its consumers are dozens of namespaces. Allocation requires both the tooling — request and usage metrics per namespace — and an agreed markup for control plane, networking and monitoring. Decide the markup percentage once, document it, and never negotiate it per team.

A ninety-day plan

Days 1–30: enforce tagging, publish a weekly top-twenty spend report, and find unowned resources. Days 31–60: measure commitment coverage against steady-state baseline and buy coverage for the floor only. Days 61–90: right-size the top twenty services, set lifecycle rules on object storage, and review egress paths for anything that can move off the public internet path.

Each step makes the next one measurable, which is why the order matters more than the tools.

What the four controls return, in numbers

Control	Typical effect	Effort	Payback
Allocation and tagging	Makes every other saving visible	Medium, ongoing	Immediate
Commitment coverage	20–40% off steady-state compute	Low once measured	One quarter
Right-sizing	10–25% of compute spend	Weekly habit	Weeks
Lifecycle and egress review	15–30% of storage and transfer	Low	One quarter

Treat the percentages as ranges, not promises: the return depends on how much untouched resource you started with, which is why allocation always comes first.

Commitment strategy for spiky workloads

Commit to the floor, not the average. Plot ninety days of usage per service, take the fifth percentile as the baseline, and cover that with a one-year commitment before considering three-year terms. Spiky services — batch processing, seasonal retail, anything with a launch calendar — should stay on demand and be governed by budget alerts instead.

The mistake that costs the most is committing to peak capacity during an optimistic quarter, then paying for unused reservations for a year.

The role of the finance team

Cost engineering fails when it lives only in engineering. Finance needs three things from the platform team: a monthly report per cost centre, a forecast that accounts for commitment amortisation, and a documented definition of what counts as waste. In return, engineering needs a budget owner per service who receives the report and answers for it — otherwise the numbers are interesting and nobody acts on them.

What to do when the bill is already out of control

A bill that has already doubled calls for a different sequence: freeze new commitments, list the ten services with the largest month-over-month increase, and ask their owners one question — what changed? In practice three answers cover most of it: a workload moved region, a debug flag turned off lifecycle rules, or a batch job started running hourly instead of daily. Fixing the answer is faster than running an optimisation programme, and it is the only step that stops the growth rather than trimming it.

After that, the ordering in this guide applies: allocation so the next surprise is attributable, commitment coverage on the baseline, right-sizing as a habit, and lifecycle rules on object storage.

The four controls in practice, on one service

Take an API service running six instances and one managed database. Tagging gives it an owner and cost centre. Commitment coverage moves the stable baseline of four instances onto a one-year reservation. Right-sizing removes the two instances that exist for a peak that arrives twice a month, replacing them with autoscaling. Lifecycle rules move backups older than ninety days to cold storage. The visible saving is usually a third of the line, without any change to the product.

Frequently asked questions

What order should we fix these in?

Allocation, then commitments, then right-sizing, then egress. Each step makes the next one measurable.

Do reserved instances still make sense with autoscaling?

For the floor of your estate, yes. Commit to the baseline and let autoscaling cover the peaks.

How do we stop costs creeping back?

A monthly report to the budget owner with the top five movers, and a rule that new services ship with an owner tag.

Check also

• Enterprise cloud computing services — the tier decisions that set the baseline this guide optimises
• CASB vs SSE vs SASE — security tooling is a visible line in the same bill
• Hospitals in Singapore — the same allocation problem in hospital IT budgets

Sources

Provider pricing documentation and public committed-use terms, reviewed on the publish date above.