FinOps: how to actually reduce a cloud bill

Cloud bills grow for structural reasons rather than careless ones. Nobody is incentivised to delete anything. Over-provisioning is invisible until someone reads a utilisation graph. Instances sized for a launch stay at launch size for years because reducing them feels risky and nobody owns the decision.

The work is not complicated. It is mostly a matter of doing it in the right order.

The order matters

Start with the changes that carry no performance risk, then move to the structural ones, and buy commitments last. Committing early is the single most common expensive mistake: a three-year Reserved Instance purchased against an over-provisioned fleet locks in that waste for three years.

1. Delete what nobody owns

Unattached volumes, snapshots past their retention policy, unassociated IP addresses, idle load balancers, old machine images. Pure waste with no performance implication. In an estate that has never been reviewed this is commonly a few per cent of the bill and carries essentially no risk.

2. Schedule non-production

Development, test and staging environments running around the clock for a team working roughly forty hours a week are idle for about three-quarters of every week. Stopping them evenings and weekends removes most of that cost.

This is usually the largest single quick win. The objection — "someone might need it at 9pm" — is answered with a self-service start button rather than by leaving everything running.

3. Right-size against measured utilisation

Use at least thirty days of real data, and look at the 99th percentile rather than the mean. A workload averaging 8% CPU with brief spikes to 70% still needs headroom for the spikes.

Be more conservative on production than the tooling suggests and exactly as suggested on non-production. Apply changes incrementally with monitoring, so a mistake is caught on one service rather than fifty.

4. Modernise instance families

Moving to a current generation, or to ARM-based instances where the workload supports it, commonly delivers materially better price-performance for what is often just an instance type change and a rebuild. ARM is the most underused lever available, mostly because nobody has tested whether their workload runs on it. Most containerised applications and managed services do.

5. Fix storage tiers

Objects that have not been read in months do not belong in the most expensive tier. Lifecycle policies or intelligent tiering handle this automatically. On block storage, older volume types are usually more expensive than current ones for the same or better performance, and the migration is typically online.

6. Look at data transfer

Cross-zone traffic and NAT gateway processing are invisible on most dashboards until you go looking. A chatty pair of services split across availability zones can cost more than the instances running them. Co-locating them, or replacing a NAT path with a private endpoint, often removes the line entirely.

7. Only now, buy commitments

With the estate right-sized and stable, commit against the steady-state baseline — not the peak. Cover most of the baseline and leave the remainder on demand for elasticity. Committing to 100% of current usage removes your ability to shrink further.

Making it stick

Savings evaporate without practice. Three things prevent that:

Enforced tagging. A minimal mandatory set — owner, environment, product, cost centre — enforced by policy so untagged resources cannot be created. Without it you cannot attribute cost to a team, and unattributed cost is nobody's problem to reduce.

Budgets and anomaly detection. Per-account budgets and automated anomaly alerts. The value is time: catching an accidental deployment on day one rather than at month end is the difference between a rounding error and a difficult conversation.

A monthly review with engineers. Not with finance alone. The people who provision resources are the only ones who can change what gets provisioned. Thirty minutes a month showing each team its own trend line changes behaviour more reliably than any policy document.

What good looks like

You know the practice is working when engineers can see the cost of their own decisions, when a spike is noticed within a day, and when the answer to "what does this service cost to run?" takes seconds rather than a spreadsheet exercise.