A retail platform I reviewed had 71 percent of its compute spend under three year standard reserved instances, bought in a single purchase by a finance team that had been told coverage was the number to maximise. Fourteen months later the engineering group finished a migration to a newer processor family, and two thirds of that commitment no longer matched anything they ran.

Nobody had done anything wrong by the letter of their job. Finance bought a discount. Engineering shipped a performance improvement. The two decisions were made eleven months apart by people who never spoke, and the result was a monthly invoice that went up after an optimisation project. Commitment discounts are the strongest single instrument in cloud cost management and the only one you cannot reverse, which is exactly why they deserve more care than the rest of the practice combined.

What you are actually buying

A commitment is a promise to pay for a fixed amount of something every hour for one or three years, whether or not you use it, in exchange for a lower rate on that amount. That is the whole mechanism. It is a volume contract, and the vendor is not doing you a favour, they are buying certainty about their own capacity planning and paying you for it.

Two words carry most of the weight in every conversation that follows. Coverage is the share of your eligible usage that a commitment applies to. Utilisation is the share of your commitment that actually got used. Teams chase coverage because it is the number on the dashboard, and they discover utilisation later, usually at renewal. Coverage without utilisation is not a discount, it is a subscription to capacity you are not consuming.

The baseline is the third term that matters. Your baseline is the floor of demand: the level your usage never drops below across a full business cycle. Commit to the floor and utilisation stays near 100 percent. Commit to the average and you have guaranteed yourself waste on every quiet day of the year, because half your hours sit below the average by definition. Almost every disappointing commitment I have looked at was sized against an average.

Three clouds, three shapes of commitment

Every provider now offers roughly the same two shapes with different names. One shape locks you to a resource, meaning a specific machine family in a specific region, and pays the deepest discount because it gives the vendor the most certainty. The other shape locks you to an hourly spend figure and lets the discount float across families, regions and sometimes services, paying less in exchange for that freedom.

AWS calls the resource shaped one an EC2 Instance Savings Plan or a reserved instance, and the spend shaped one a Compute Savings Plan. Azure calls them reservations and savings plan for compute. Google calls them resource based committed use discounts and compute flexible committed use discounts, usually shortened to CUDs. The names differ, the trade is identical: how much flexibility will you sell for how many points of discount.

Verified against AWS, Microsoft and Google documentation in July 2026. Headline percentages are ceilings for the best case machine and region, not the rate you will see on a mixed estate. Discounts and product names change, so confirm in your own console before committing a budget to them.

How much of your bill should you cover?

This is the question every FinOps practitioner gets asked and the one most often answered with a vague target lifted from a conference talk. Here is a verdict instead: cover the floor, not the forecast, and start at about 60 percent of current eligible spend for a first purchase on a growing estate.

The reasoning is arithmetic rather than taste. Work through what happens to a 100,000 USD monthly compute bill under a three year commitment at 46 percent, when demand later falls by 30 percent because a rightsizing programme and a platform migration both land in the same year. That is not a pessimistic scenario, it is the normal outcome of doing the rest of this series properly.

Worked from a 100,000 USD monthly list bill, a 46 percent commitment discount, and demand settling at 70,000 USD of list usage. Figures are arithmetic from those assumptions rather than a quote from any price list.

Look at the two ends. Buying 100 percent coverage and missing by 30 points costs 54,000 USD a month. Buying 40 percent and missing by the same 30 points in the other direction costs 51,600 USD. The symmetric error is not symmetric in money, because unused commitment is paid at 100 percent of its value while uncovered usage still buys you real capacity. That asymmetry is the strongest argument I know for buying conservatively and topping up, and it gets stronger as the discount gets deeper.

Choosing the instrument

The choice comes down to two questions asked in order. Is the workload going to stay on the same machine family and in the same region for the whole term, and is the baseline itself stable enough to survive that long? If both answers are confident, take the resource shaped instrument and the deeper rate. If either is uncertain, take the spend shaped instrument and pay for the option to change your mind.

Term length follows the same logic. Three years roughly doubles the discount against one year on Google Cloud general purpose families, moving from 28 percent to 46 percent, which is a large enough gap that people reach for it automatically. Ask a harder question first: what did your compute estate look like three years ago? For most organisations the honest answer involves at least one processor architecture change, a container platform migration, or a large workload moving somewhere else entirely. A three year term is a bet that the next three years will be quieter than the last three, and that bet is usually wrong for platform teams and usually right for stable regulated back office systems.

flowchart TD
  A{Has the baseline held for 12 months} -->|No| B[Buy nothing yet, revisit next quarter]
  A -->|Yes| C{Will the machine family change}
  C -->|Migration is planned or likely| D[Spend based instrument, one year term]
  C -->|No change expected| E{Is the region fixed for the whole term}
  E -->|Yes| F[Resource based instrument, three year term]
  E -->|No| D
  D --> G[Size to the floor, cover about 60 percent]
  F --> G
  G --> H[Buy in tranches across the quarter]
  H --> I[Review coverage and utilisation every quarter]

The order discounts apply in

When you hold more than one instrument, the provider decides which one gets consumed first, and the order is not arbitrary. Azure documents it plainly: reservation benefits are applied before savings plan benefits, because reservations are more restrictive and usually carry the deeper discount, so consuming them first reduces the chance of waste. The same principle holds on the other clouds, where narrower commitments are burned down before broader ones.

This matters when you layer instruments, which you should. A sensible mature position looks like a base layer of resource shaped commitments covering the workloads that genuinely will not move, a middle layer of spend shaped commitments covering the rest of the stable floor, and everything above that running on demand or on spot capacity. The application order means the base layer gets used first, which is exactly what you want, because it is the layer you cannot redirect.

Microsoft also publishes a purchase sequence worth adopting whatever cloud you run: rightsize first, exchange any underutilised reservations onto better fitting configurations, trade rigid reservations for flexible savings plans where usage has become variable, then buy new reservations only for stable well understood workloads, and finally add new spend based commitments sized against the cleaned up baseline. Read that list backwards and you have a description of how most organisations actually do it, which is why most organisations are disappointed.

Getting out of a commitment

Assume you cannot. AWS states that the terms of a Savings Plan commitment cannot be changed after purchase, and Google states that a committed use discount cannot be cancelled after purchase, with monthly billing continuing to the end of the term whether or not the resources are used. Those two sentences should be read aloud in the meeting where somebody proposes a three year purchase.

Azure is the exception and it is a narrow one. Reservations can be exchanged for a different configuration, and refunds are possible, but the total cancelled commitment cannot exceed 50,000 USD in a rolling twelve month window per billing profile or enrolment. Refunds arising from an exchange do not count against that cap, which makes exchange the route to reach for. Microsoft also notes that no early termination fee is charged at present but that a 12 percent fee may apply in future, so do not build a strategy on the current position.

What you can always do is stop making the problem larger. A stranded commitment has a natural expiry, and the discipline that matters is refusing to renew it out of habit. I have seen renewal treated as an administrative task on a finance calendar, with the same quantity rolled forward because it was easier than reopening the analysis. Every renewal is a fresh purchase decision and deserves the same scrutiny as the first one.

Run the purchase as a quarterly cycle

The single structural fix for the failure in the opening story is to stop treating commitment purchase as a finance event and start treating it as a joint decision with a fixed rhythm. Engineering holds information finance cannot see, namely which platforms are about to change, and finance holds information engineering does not care about, namely the cash implication of a three year obligation. Neither can size a commitment alone, and the failure mode is always that one of them tries.

Buying in tranches is the other half of the fix. Splitting an annual purchase into four quarterly tranches means no single decision commits the whole estate, and each tranche gets the benefit of three more months of evidence. It also creates a natural ladder of expiry dates, so you are never renegotiating everything at once, which is a considerably better negotiating position with any vendor.

sequenceDiagram
  participant F as FinOps
  participant E as Engineering
  participant B as Finance
  F-->>E: Share the 12 month usage floor by family and region
  E-->>F: Flag every migration planned inside the term
  F-->>F: Subtract planned migrations from the floor
  F-->>B: Propose tranche size, instrument and term
  B-->>F: Approve and record the multi year obligation
  F-->>F: Buy one tranche, not the whole year
  F-->>B: Report coverage and utilisation monthly
  F-->>E: Reopen the floor next quarter

Buy a one year spend based commitment at 60 percent coverage

Here is the recommendation for this part, stated without hedging. For a first purchase, buy a one year spend based commitment sized to about 60 percent of your current eligible compute spend, split into two tranches three months apart, and leave every workload with a known migration ahead of it completely uncovered. On AWS that is a Compute Savings Plan, on Azure a savings plan for compute, on Google Cloud a compute flexible commitment, checking the memory optimised exclusion first.

You will give up perhaps 15 to 20 points of headline discount against the deepest three year resource shaped instrument. Buy that certainty deliberately. Once you have run four quarterly review cycles and can show a baseline that held while the estate changed underneath it, promote the stable portion to a three year resource based commitment and take the deeper rate on the part you have earned the right to be confident about. Almost nobody regrets moving in that direction. Plenty of people regret the reverse.

Part 13 moves to the opposite end of the pricing spectrum, covering spot and interruptible capacity, which is where the deepest discounts live and where the engineering work is real rather than contractual. The rightsizing that has to happen before any of this was covered in Part 11, the forecast that tells you whether a baseline will hold came from Part 8, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: pull your current commitment utilisation figure and find out who signed the largest one and what evidence they used. If nobody can answer the second half of that question, you have found the process gap before it costs you a renewal.

References

• Savings Plans types, AWS Savings Plans User Guide
• Decide between a savings plan and a reservation, Microsoft Cost Management
• How a savings plan discount is applied, Microsoft Cost Management
• Self service exchanges and refunds for Azure Reservations, Microsoft Cost Management
• Committed use discounts for Compute Engine, Google Cloud documentation

Discount percentages, term options, eligibility rules and refund limits were verified against AWS, Microsoft and Google documentation in July 2026 and change over time. Monetary figures in the worked tables are arithmetic from stated assumptions rather than quotes from a live price list.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts