9.3 Cutting cloud cost without cutting service

Describes cloud cost engineering as of August 2026; no pricing figures, which go stale

What this is and why it exists

Given a real cloud bill, a competent engineer can usually find about a third of it without degrading anything, and the order in which they look is what makes it a repeatable skill rather than a lucky afternoon. This lesson is that order — the sweep that costs nothing, the settings that cost nothing, the architectural facts that dominate everything else, and the commitment you make last rather than first.

The vocabulary

  • Right-sizing — matching a resource's size to its measured use.
  • Idle resource — something running and doing nothing: a stopped project's machine, an unattached volume, an unused address.
  • Lifecycle rule — automatic movement of data to cheaper storage as it ages.
  • Cold tier — cheaper storage with charged, slower retrieval and a minimum billed duration.
  • Cross-zone traffic — data moving between availability zones, which is metered.
  • Chatty — an architecture whose components exchange many messages to do one thing.
  • Commitment — a discounted rate bought with a one or three year promise.
  • Utilisation — the fraction of what you are paying for that you are using.

The mental model

Work in order of certainty, and the order is deliberate: begin with what is free to remove, then what is free to change, then what needs a design conversation, and only then buy a discount. Doing it backwards — committing first — is the classic mistake, because a commitment locks in the wrong size for a year.

The idle sweep comes first and is nearly always the largest single find. Machines started for something that ended. Volumes left behind by deleted machines, still billed, still holding data. Load balancers with nothing behind them. Reserved addresses attached to nothing, which several providers charge for precisely because they are idle. Old snapshots nobody has needed since the year they were taken. Development and staging environments running through nights and weekends when nobody is working, which is roughly two thirds of every week. None of this requires a decision from anyone; it requires somebody to look, and the looking is the part that never gets scheduled.

Right-sizing is second, and it is measurement rather than opinion. Take a normal week including its peak, look at processor, memory and disk throughput, and resize to fit the peak with headroom. A machine that has never exceeded a small fraction of its capacity for a month is not a safety margin; it is a subscription. Move one step at a time so you can attribute the effect, and remember that the wrong ratio calls for a different family rather than a smaller size in the same one.

Storage is third and mostly free to fix because it is a setting. Lifecycle rules move data to colder tiers as it ages and delete what has an end date — logs, exports, old backups beyond retention. Two cautions keep it honest: cold tiers bill a minimum duration and charge for retrieval, so data you will read often or delete soon costs more there; and orphaned data is invisible until you look, so check for buckets nobody has read in a year before optimising the ones everybody uses.

Fourth, and largest at scale, the architectural facts. Three dominate. Egress and cross-zone traffic are metered, so a chatty design pays for every message and moving components together removes the charge entirely rather than reducing it. A cache in front of an expensive query or an origin server converts repeated work into a single result. And the choice of service shape matters more than any tuning within it: constant heavy load is cheaper on rented machines than on per-invocation pricing, and intermittent load is dramatically cheaper the other way round. These require a design conversation, which is why they come after everything that does not — but they are the ones that decide the bill of a system that grows.

Last, commitments. Once usage is stable and right-sized, a one or three year commitment on the steady floor is a large, safe saving. The order matters absolutely: commit to a right-sized baseline and you save on what you actually need; commit first and you have bought a year of the wrong thing, and every later improvement is measured against a floor you already paid for. Commit conservatively to the part of the load that never goes away, and leave the variation on demand.

What you should now be able to explain or do

State the four steps in order and say why committing last is not a preference but a rule. List six things an idle sweep finds. Right-size a machine from measurement and say what a month at low utilisation actually means. Write a lifecycle rule in words and name the two cautions about cold tiers. Give three architectural facts that dominate cost, and the fix each one implies. Explain what goes wrong when a commitment is bought before right-sizing.

Check yourself

Idle resources — machines from finished projects, unattached volumes, load balancers with nothing behind them, reserved addresses, ancient snapshots, and non-production environments running overnight. Removing them needs nobody's permission and is usually the biggest single find.

An oversized machine, not a safety margin. Check memory and disk too in case one of those sized it, then resize one step at a time so the effect is attributable.

When you read it often, or delete it before the minimum billed duration. Cold tiers trade a low storage rate for retrieval charges and a minimum period.

Because cross-zone traffic is metered per unit moved. Co-locating removes the charge entirely; tuning only reduces it.

Because it fixes a rate against a baseline for a year or three. Commit before right-sizing and you have bought the wrong size for the whole term, with every later improvement measured against a floor you already paid for.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Cutting cloud cost without cutting service: work through the checklist