Cloud commitments: price the unused hours before buying the discount

A cloud commitment is a forecast with a payment obligation attached. The FinOps lead signing off the purchase needs confidence in the demand that will remain eligible throughout the term, including after a migration, product cancellation or engineering efficiency improvement.

The advertised discount answers only what happens to covered usage at the quoted rates. It does not establish how much of the commitment the organisation will use. A smaller commitment can deliver less nominal coverage yet leave the business in a better position when demand changes.

Separate the stable workload from the roadmap

Begin with observed eligible usage at the billing interval used by the offer. Identify the base demand that persists through quiet periods, then distinguish growth assumptions, temporary projects and workloads already approved for retirement. A monthly average can hide expensive unused periods if the commitment is applied hourly.

Ask engineering which planned changes reduce eligibility as well as consumption. Rightsizing may reduce the amount needed. Moving to a different service or region may change whether the same offer applies at all. Treat approved migrations as part of the purchasing model, rather than as a problem for the team that will inherit the commitment later.

For a named example, AWS Savings Plans involve an hourly commitment for a one- or three-year term, with different payment options. AWS’s purchase documentation makes a distinction worth carrying into the model: the entered hourly commitment is at the Savings Plans rate, not the equivalent on-demand spend. Copying the on-demand number into the commitment field would misstate what is being purchased.

The break-even point belongs in the decision

Consider a simplified fictional offer covering one unit of capacity over a 365-day year, or 8,760 hours. On-demand use costs £1 per hour. The commitment costs £0.70 for every hour in the term, whether used or not. Demand never exceeds the covered unit; there are no other charges, discounts, taxes or financing costs in this example. These are illustrative prices, not an AWS quotation.

The annual obligation is £0.70 × 8,760 = £6,132. On-demand cost is £1 multiplied by the number of hours actually used.

Eligible use	Hours used	On-demand cost	Commitment cost	Effect of committing
40% of the term	3,504	£3,504	£6,132	£2,628 more expensive
75% of the term	6,570	£6,570	£6,132	£438 saving
100% of the term	8,760	£8,760	£6,132	£2,628 saving

Break-even occurs at 6,132 hours, or 70% use. The nominal 30% rate reduction becomes only a 6.67% saving against actual on-demand cost in the 75% case: £438 divided by £6,570. At 40% use, the lower hourly rate produces a larger total bill.

This simple threshold works because the example fixes the workload, rates and coverage. A real spending commitment can cover a changing mix of eligible services, so replay that mix under the actual product rules. Include uncovered usage at its applicable rate and unused commitment cost. Do not substitute average processor utilisation for the billing measure that determines whether the commitment is consumed.

Pay for flexibility only where it protects a plausible change

AWS’s Savings Plans type documentation distinguishes Compute Savings Plans, which can apply across EC2 families and regions and to Fargate and Lambda, from EC2 Instance Savings Plans tied to an instance family in a chosen region. The latter still allow variation in instance size, operating system and tenancy within that scope.

That difference matters if an application is likely to move from EC2 to Fargate during the term. Evaluate the broader offer against the actual destination and rates. Flexibility across named services is not permission to move the obligation to any service or another provider.

For a workload expected to disappear, flexibility helps only if there is other eligible demand to absorb the commitment. Do not justify a purchase by pointing to possible replacement workloads that have no approved owner, funding or implementation date.

Compare offers at the same boundary: total term, eligible workload, payment timing and downside assumptions. An upfront payment also has a cash consequence that a simple effective hourly rate does not show. Have finance assess that timing separately from the engineering estimate of consumption.

A short return window is not a migration exit plan

AWS documents limited returns for recently purchased Savings Plans. The published conditions include an hourly commitment of $100 or less, purchase within the preceding seven days and the same UTC calendar month, and remaining return quota, alongside other eligibility restrictions. These provisions address purchase errors; they do not provide a general right to reverse a commitment after a later architecture change.

Check the actual offer’s return, exchange, cancellation and expiry conditions before approval. Keep those concepts separate. A right to vary eligible usage is different from a right to exchange the product, recover an upfront payment or cancel future obligations.

In the purchase decision, show the expected saving, the downside cost and the assumptions that would invalidate the case. Assign an owner to watch eligible usage, upcoming retirements and expiry. Plan the renewal decision early enough to avoid replacing an old commitment automatically with the same amount.

If the eligible-demand history or cost boundary is still disputed, first build a defensible FinOps baseline. The opportunity to buy a discount will remain; an unsupported demand assumption can stay on the bill long after the project that justified it has ended.