Cutting cloud spend, in the order that actually works

Cost reduction programmes usually start where the button is easiest to press: buy commitments. It works, once, and then the programme stalls, because a three-year commitment on a workload nobody has examined locks in the waste for three years.

The order matters more than any individual technique. This is the sequence we run, and the reasoning behind it.

1. Attribution, before anything is changed#

You cannot reduce a number nobody owns.

The first week is spent making the bill legible: tags enforced at provisioning time, one account or project per team where the boundary allows it, and a cost per environment that someone recognises as theirs. Not a dashboard for the platform team. A number that lands in the channel of the team that generated it.

This step saves nothing on its own and it is the reason everything after it works. In the median engagement the attribution pass alone reveals between 8 and 15 percent of spend belonging to nothing anyone will claim.

2. Delete what nobody is using#

Unattached volumes. Snapshots from a migration finished two years ago. Load balancers in front of nothing. Idle NAT gateways. The staging cluster from a project that shipped in 2024. Log retention set to "forever" on a bucket ingesting 400 GB a day.

This is not clever work and it is usually the largest single line in the first month. It is also the safest: nothing is serving traffic, so nothing can break. The only real risk is deleting something that turns out to matter, which is what the attribution pass is for.

3. Right-size against observed usage, not requested usage#

Now the interesting part. Almost every platform we touch has requests set by a nervous engineer at 2 a.m. two years ago, never revisited.

The rule is to size against the p99 of observed usage over a full business cycle, with headroom, not against the peak of all time and not against the average. Averages hide the spikes that cause the incidents; all-time peaks include the one bad Tuesday that a retry storm caused and which has since been fixed.

On Kubernetes this is where most of the money is. A cluster where every workload requests 2 CPU and uses 200 millicores is paying for a fleet three times larger than it needs, and no amount of commitment discount fixes that.

4. Move the work that can tolerate interruption#

Batch jobs, CI runners, data pipeline stages, anything with a retry and no user waiting on it. Spot and preemptible capacity is 60 to 90 percent cheaper and the engineering cost is a checkpoint and a retry.

The mistake here is going too far. Spot for a stateful primary is not a cost optimisation, it is an outage with a discount. The test is simple: if the workload disappearing mid-execution is merely annoying, it belongs on spot. If it requires a human, it does not.

5. Fix the architecture that generates the spend#

The most expensive line on many bills is not compute. It is data moving in the wrong direction: cross-zone traffic between services that should be zone-aware, an egress path through a NAT gateway that should be a private endpoint, a chatty service pair separated by a region boundary for reasons nobody remembers.

This is real engineering work and it is where the durable savings live, because it changes the slope of the cost curve rather than its intercept. The savings from steps 2 and 3 are a one-time step down. Step 5 is the one that stops the number growing faster than revenue.

6. Now buy the commitments#

By this point the workload is stable, right-sized and partly on spot, so the baseline you are committing to is the real one. Commitments bought here are typically 30 to 40 percent smaller than the ones the same team would have bought in month one, at the same discount rate, covering a genuinely steady floor.

Buying last is not a rule about savings. It is a rule about optionality: every commitment is a bet that your architecture will not improve.

7. Put a budget alert in front of every team#

Everything above decays. A cost programme that ends with a report ends, full stop, and the number climbs back within two quarters.

What survives is a per-team budget with an alert that fires in that team's channel, a unit-cost metric on the same dashboard as latency and error rate, and cost as a line item in architecture review. Not a gate. A number people see while the decision is still cheap to change.

What this looks like in practice#

The most recent full programme: 62 percent reduction over 14 weeks while traffic tripled, and a $1.9M annual saving. Roughly half of that came from steps 2 and 3, which took three weeks. The other half came from step 5, which took nine, and is the half that is still holding.

The commitments were bought in week 12.