Model the savings from commitment coverage, utilisation, right-sizing, storage tiering and scheduling as one ranked plan.
Coverage and utilisation are the two core FinOps commitment KPIs and they pull in opposite directions: raising coverage saves money on spend you are not yet discounting, while low utilisation means you are already paying for capacity nobody uses. Every other lever is modelled against its own spend base, so right-sizing applies to compute, tiering to storage and scheduling only to non-production. Ranking levers by dollars stops teams starting with the most visible task instead of the most valuable one — and buying more commitments while utilisation is below 95% simply adds to the waste. Saving percentages are estimates from your own environment, not guarantees, so validate each lever on a small scope before rolling it out.
FinOps Savings
commitment saving = eligible spend × (target coverage − current coverage) × discount; unused commitment value = eligible × coverage × (1 − utilisation); each other lever = its spend base × its saving percentage.
commitment saving = eligible spend × (target coverage − current coverage) × discount; unused commitment value = eligible × coverage × (1 − utilisation); each other lever = its spend base × its saving percentage. Coverage and utilisation are the two core FinOps commitment KPIs and they pull in opposite directions: raising coverage saves money on spend you are not yet discounting, while low utilisation means you are already paying for capacity nobody uses. Every other lever is modelled against its own spend base, so right-sizing applies to compute, tiering to storage and scheduling only to non-production.
Ranking levers by dollars stops teams starting with the most visible task instead of the most valuable one — and buying more commitments while utilisation is below 95% simply adds to the waste. Saving percentages are estimates from your own environment, not guarantees, so validate each lever on a small scope before rolling it out.
This calculator takes 12 inputs: Total monthly cloud spend, Steady-state compute eligible for commitments, Current commitment coverage, Target commitment coverage, Commitment utilisation, Discount a commitment delivers, Saving available from right-sizing, Storage spend, Saving available from storage tiering, Non-production spend, Saving available from scheduling, Confirmed waste ready to delete. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Rarely. Full coverage means every hour of compute is locked to a term, so any architecture change, region move or instance-family upgrade becomes a stranded commitment. Most mature teams settle between 70% and 90% and leave the remainder on demand as deliberate flexibility.