N100FN100F
Published on

Optimising: rate versus usage

There are two levers for bringing cloud cost down, how much you consume and at what price. The order in which you pull them matters, and getting the order wrong locks the organisation into commitments it never needed.

Service line FinOps Engineering

Two levers, not one

All cloud cost is, at bottom, usage times rate. There are two ways to bring it down:

  • Reduce usage: consume less to do the same thing.
  • Reduce the rate: pay less per unit consumed, usually by committing consumption in exchange for a discount.

Both are legitimate. The problem is the order.

Usage first, rate second

Committing before or after optimisingCommitting first leaves 30% of the commitment unused; optimising first uses the whole discount.FINOPS · OPTIMISATIONThe order changes the outcomeCommit firstYou commit on inflated consumption; then you clean up.Real usage after clean-up: 70Paid for, unused: 3030% of the commitment is paid for and unused for 1 to 3 years.Optimise firstYou clean up and right-size; then you commit only what is stable.Committed: 60On-demand: 10Usage 70, no idle capacity: the discount is used in full.1. Remove2. Right-size3. Schedule4. CommitIllustrative data; they do not correspond to any real caseN100F · n100f.com

  1. Remove what is not used. Orphaned resources, forgotten environments, disks and backups nobody looks at. It is the fastest saving and carries no risk for the business.
  2. Right-size. Resources sized for a peak that never comes. They are adjusted using real utilisation data over several weeks, not a snapshot from a single day.
  3. Schedule start-up hours. Development and testing environments that do not need to run overnight or at the weekend.
  4. Commit stable usage. Only after the three steps above: with consumption already clean, you commit the base you know to be stable at a better rate (savings plans, reservations, committed-use discounts).

Why the order matters

Commit first and you are buying a discount on inflated consumption. Then, as you clean up and right-size, usage drops below what was committed and you end up paying for capacity you no longer use. The commitment that was supposed to save money becomes a fixed cost lasting one or three years.

The other way round, with usage already optimised, the commitment covers only what is genuinely stable and the discount is used in full.

How to decide what to move

  • Order by impact and effort. Many small, automatable opportunities usually add up to more than one big one nobody dares touch.
  • Measure the commitment: what percentage of eligible consumption is covered and how much of the commitment is actually used. Both numbers should be reviewed every month.
  • Record every decision: what was changed, how much it was expected to save and how much it saved. Without that, optimisation leaves no learning behind.

Optimising once is easy. Keeping it optimised takes owners and a review rhythm, which is what the next article covers.

How we apply it: FinOps Engineering.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk