How the mechanism actually works
Every major cloud provider sells the same basic bargain. Commit to a level of spend or a quantity of compute for one or three years, and pay meaningfully less per unit than you would on demand. The instruments have different names and different flexibility profiles. Reserved Instances, Savings Plans, Committed Use Discounts, Reservations. The economics underneath are the same.
The question that decides everything is how the commitment level gets chosen.
It gets chosen by looking at what you currently spend.
That is a reasonable procedure and it is where the trap is set. Because in a Kubernetes estate, what you currently spend is not a measurement of what you need. It is a measurement of what your workloads asked for.
Why Kubernetes makes this worse than plain virtual machines
On a fleet of manually provisioned servers, the gap between what is provisioned and what is needed is visible to whoever provisions them. Somebody chose that instance count. Somebody could choose differently.
Kubernetes removes that person from the loop, which is the entire point of it, and in doing so removes the last human who might have noticed.
Here is the chain. An engineer declares CPU and memory requests for a workload. Those requests are padded, and the padding never gets revisited, because under-requesting fails loudly and over-requesting fails silently. The scheduler treats those requests as genuine demand, because it has no way to know otherwise. The cluster autoscaler reads the resulting pressure and provisions nodes to satisfy it. Those nodes run, bill, and appear in your usage data.
Now finance pulls twelve months of usage to size a commitment. What they are looking at is not demand. It is padding, faithfully converted into infrastructure by a system doing exactly what it was told.
At the moment of signature, that padding stops being a configuration value that anyone could change on a Tuesday afternoon. It becomes a contractual liability with a term attached.
The trap, in sequence
The sequence matters more than any individual step.
Step one. Clusters run with padded requests. Normal, and near universal.
Step two. The autoscaler provisions to match. Also normal.
Step three. Finance sizes a one or three year commitment against the observed baseline. Entirely reasonable, given the data available.
Step four. The platform team runs an optimization program. Consumption falls.
Step five. Consumption is now below the committed floor. The commitment is take-or-pay. You are billed for the floor regardless.
Every step is defensible. The outcome is that a successful program produces no financial result, and the team that ran it looks like it failed.
The second-order damage is worse than the first. That team will find it much harder to fund the next program, because everyone in the room remembers that the last one did not show up on the bill.
The two numbers people confuse
Any conversation about commitments involves two metrics that sound similar and mean opposite things.
Coverage is the proportion of your eligible usage that a commitment is covering. High coverage means you are paying discounted rates on most of what you run.
Utilization is the proportion of your commitment that you are actually consuming. High utilization means you are using what you bought.
Optimization pushes these in opposite directions. Cut consumption and coverage rises, which looks good, while utilization falls, which is where the money leaks. A dashboard showing 98% coverage can sit directly above a commitment you are underusing by a third, and both numbers are accurate.
Track both. If you only track one, track utilization, because that is the one that turns into a payment for nothing.
The audit to run before you sign
This is a short exercise and it is the highest-return hour available in cloud cost management.
Establish the request-to-usage ratio at P95 across the estate. Not average. Average smooths away exactly the burst behavior that the headroom is supposed to cover, which makes over-provisioning look justified.
Model the post-optimization baseline. If a first pass would remove a meaningful share of provisioned capacity, that is the number your commitment should be sized against, not today's.
Check the renewal calendar against the optimization calendar. If a commitment renews inside the window where you plan to do efficiency work, you have a sequencing conflict, and it is far cheaper to resolve it now than to discover it later.
Separate the durable floor from the elastic layer. There is almost always a genuine baseline that will exist in any scenario, and on an owned estate the same question has no invoice to answer it. Commit confidently to that. Leave the layer above it uncommitted until you know its real shape.
Write down who owns the decision. In most organizations, the commitment is signed by finance using data produced by engineering, with neither party fully accountable for the assumption connecting the two. That gap is where the money goes.
If you are already inside a commitment
Most organizations reading this are mid-term, which is a different problem with a smaller set of options. They are still worth knowing.
Do the efficiency work anyway, and measure it in capacity terms. Your consumption falling below the floor does not make the work worthless. It makes the benefit deferred to renewal rather than immediate. Track it in node hours and CPU hours, and keep any changes reviewed and reversible, so the result is documented even while the invoice is flat, and make sure finance understands this before you start rather than after.
Redirect freed capacity rather than releasing it. If you are going to pay for the floor regardless, the cheapest compute available to you is the capacity you have already committed to. Workloads scheduled for future migration, batch jobs, non-production environments and new services can all be moved onto it. Under-consumption is a waste. Under-consumption you deliberately fill is a discount.
Use whatever flexibility the instrument gives you. Some commitment types allow changes to instance family, region or configuration within the term. Understand exactly which levers your specific agreements permit before assuming you have none.
Start the renewal conversation early and with your own numbers. Arriving at a renewal with a documented optimized baseline changes the negotiation completely, because you can argue for a level that reflects reality instead of accepting a proposal sized from historical spend.
Sizing the next one properly
When the renewal does come, three principles.
Size against optimized consumption, not current consumption. This is the entire lesson and it is worth restating plainly, because it is the step that everyone skips.
Consider shorter terms while the estate is still moving. A three year commitment on a workload mix that is actively changing is a bet on stability you may not have. The per-unit discount on a longer term is real, and it is not free.
Ladder the commitments. Multiple overlapping agreements with staggered end dates give you a decision point every few months instead of one enormous decision every three years. It costs a little in blended rate and it buys a great deal of optionality.
Where this sits in the wider picture
Kubernetes cost lives in three distinct layers, each with its own waste pattern and its own owner. Pods, nodes, and commitments.
Most efficiency programs work the pod layer, because that is where the tooling is and where the engineering feels productive. The commitment layer sits above both, it is where the largest single-decision sums live, and it is owned by people who are usually not in the same meeting.
That is the structural problem. Not a technical one. The layer with the most money in it is the layer with the least engineering attention, and the decision gets made annually by people working from data that engineering produced without knowing what it would be used for.
The fix is not a tool. It is putting the utilization number in front of whoever signs, before they sign.
About OptOps. OptOps is the optimization layer for enterprise infrastructure, covering Kubernetes in the cloud and HPC and GPU compute on premise. It reads real workload behavior and produces sized recommendations with cost and confidence attached, which is what a defensible pre-commitment baseline is made of. Read-only by default, so it deploys where write-access tools cannot.
References
- FinOps Foundation. State of FinOps 2026. Sixth annual practitioner survey, 1,192 respondents representing more than US$83 billion in annual cloud spend.
- FinOps Foundation. Rate optimization and commitment-based discounts.
- Provider documentation for the specific instrument you hold, since terms, flexibility and exchange rules differ materially between them.