A commitment strategy treats all of a company's reservations, Savings Plans and committed use discounts as one commitment portfolio, with types, scopes, terms and end dates, instead of deciding each purchase on its own. Its core: the stable base load is covered, the fluctuating top runs at the on-demand rate, and purchases are staggered so that nothing expires all at once. Only as a portfolio does it show how coverage, flexibility and expiry combine; no single purchase decision shows that.
How it works
The register
The starting point is a list of every active commitment:
| Field | What it is for |
|---|---|
| Programme and type | sets what the commitment binds and in which order it applies |
| Scope | account, subscription, project or shared; sets which usage it can find |
| Commitment and payment | hourly amount or quantity, upfront or monthly |
| Start, end, renewal | the expiry calendar, and whether it renews itself |
| Utilisation and share of coverage | whether it is too large, too small or right |
| Owner | who bought it and decides on renewal |
On AWS the Cost and Usage Report carries each commitment's end date in reservation_end_time and savings_plan_end_time. How renewal, exchange and expiry alerts work per provider is covered in exchange, cancellation and expiry of commitments.
Base and top
What runs every hour is covered; the top stays on demand or, where it tolerates interruption, moves to spot capacity. The providers' recommendations draw the line differently. Google offers two models: stable usage sizes the commitment on resources that ran continuously for 30 days, while optimal savings maximises net savings and also counts intermittent usage where it reaches the break-even threshold. Usage already covered by a commitment does not count. Microsoft simulates many savings plan candidates against actual on-demand costs and always returns the lower of the 3-day and 30-day results, so that a drop in usage does not lead to overcommitment. A higher commitment lowers utilisation per hour; a lower one leaves more hours uncovered. AWS recommends the amount with the largest estimated saving over a lookback of 7, 30 or 60 days and says the recommendation is no forecast.
All three work from the past; a planned migration, a retired product or a large new customer is not in the data. The base is therefore a decision made with a forecast, not the output of a recommendation, and it is sized after rightsizing, because a commitment locks in the usage it covers, as the optimisation loop explains.
Layering
Specific commitments, meaning reservations and resource-based CUDs, apply before flexible ones; the order per provider is in cloud commitment discounts compared by type. A layering follows from that: a specific layer for usage whose type, family and region are settled, and a flexible layer above it for usage that moves. Microsoft advises at least seven days between buying a savings plan and a reservation for the same usage, and never both at once. AWS builds its Compute and EC2 Instance Savings Plans recommendations from the same usage; they are not meant to be acted on together.
Staggering
Buy the whole base on one day and everything has one end date, with a single decision at the wrong moment. The FinOps Foundation's Rate Optimization capability recommends spreading purchases across the year so that commitments expire regularly and can be reassessed; Microsoft advises starting small and buying where confidence is high. Staggering works in tranches, each covering part of the base and expiring on a different date. Each tranche is checked against fresh recommendations, because the old ones lag behind every purchase.
Who decides
The Foundation places analysis and purchasing centrally, negotiation with procurement, and policy with finance and leadership. Microsoft recommends a process for central purchasing owned by a named team or person, and consistent monitoring of utilisation and coverage across all accounts. In a small company that is often one person working with engineering; the roles are covered in FinOps roles and responsibilities, the approval in guardrails and approval thresholds.
What it means for your cost
The portfolio is reviewed on a fixed cadence, with coverage and utilisation as the input:
| Finding | Decision |
|---|---|
| utilisation high, coverage low, usage stable | consider the next tranche |
| utilisation falling | buy nothing more; find the cause, widen the scope or exchange where allowed |
| migration or change of family planned | choose a flexible type, do not renew the specific layer |
| a tranche expiring soon | reassess the base, then renew, shrink or let it lapse |
| usage growing above the base | wait until the growth has become a stable base |
The outcome is measured by the effective savings rate, which combines coverage, utilisation and discount depth in one number. A portfolio aimed only at coverage can lose through poor utilisation what it gains through the discount. Upfront and monthly payment fall differently into billed and effective cost, as list, billed, effective and amortized cost shows; how an upfront payment is accounted for is for the tax adviser or auditor to decide.
Where it goes wrong
- Everything expires at once. Symptom: in one month the cost of unchanged workloads jumps to on-demand level, or a large renewal has to be decided within days. Cause: the base was covered in one purchase, and there is only one end date.
- A recommendation right after a purchase. Symptom: shortly after a purchase the tool recommends almost the same commitment again. Cause: the recommendation has not caught up; Azure lowers it for the same scope on the purchase day but needs up to 25 days for other scopes, and AWS asks for a refresh after a purchase, return or expiry and ignores queued purchases.
- Two recommendations for the same usage. Symptom: a Savings Plan stays partly unused. Cause: the Compute and the EC2 Instance recommendation, or a reservation and a savings plan, were bought for the same usage.
- A purchase without an owner. Symptom: nobody knows who decides on renewal. Cause: the register has no owner, and the renewal default decides alone.
Example
The base is a commitment B, as an hourly amount or a quantity. Instead of buying B on one day, the company buys B/4 at the start of each quarter, each with the same term T.
| Quarter of the first year | Share of the base covered |
|---|---|
| 1 | B/4 |
| 2 | B/2 |
| 3 | 3B/4 |
| 4 | B |
Across the first year, on average 5/8 of the base is covered rather than all of it; that is the price of staggering, part of the first year's discount. In return, once T has passed, exactly one tranche of B/4 expires each quarter, and every renewal is a decision about B/4 with the usage data of that moment. If the base shrinks, the portfolio shrinks by a quarter with each expiring tranche instead of staying overcommitted until the end of a single term.
Sources
Read on 2026-10-16. FinOps Foundation Rate Optimization (CC BY 4.0); Microsoft rate optimization in the FinOps Framework and savings plan recommendations; AWS understanding your Savings Plans recommendation calculations, CUR 2.0 reservation columns and Savings Plan columns; Google Cloud recommendations for committed use discounts.