Resource based commitments stranded 2 to 4 times more often, and layering flexible ran 8 to 14 points cheaper
A resource based commitment locks the machine shape as well as the rate, which is why the deepest discount on the slide becomes the most expensive line on the invoice the moment a workload moves to a newer family or another region.
Prepared by Redress Compliance · August 15, 2026 · Google Cloud advisory. Based on 25 to 35 Google Cloud commitment reviews, 2024 to 2025.
Executive summary
Shape matters more than depth. Three year resource based commitments stranded roughly 2 to 4 times more often than flexible ones when a region or machine family changed.
The headline is not the rate you get. A three year resource based commitment lists up to 55 percent off and lands at 38 to 50 percent once the idle slice is subtracted.
Around 18 to 26 percent of committed resource spend sat idle inside the term after a workload moved to a newer machine family.
Layering beats maximizing. Estates that layered flexible commitments over a resource based base load ran 8 to 14 percentage points cheaper net than estates that maxed coverage on one model.
There is no clawback. An unused resource based commitment is not refunded, so the stranded commitment and the full rate replacement bill at the same time.
Two shapes, and what each one locks
| Dimension | Resource based | Flexible or spend based |
|---|---|---|
| What you commit | Fixed vCPU and memory in a region | A dollar figure per hour |
| What it locks | The rate and the machine shape | The rate only |
| Discount depth | Deepest | A few points shallower |
| Stranding risk | High on a family or region change | Low, it floats |
| Best fit | The proven, always on base load | The predictable but shifting middle |
How the double pay happens. A workload migrates to a newer machine family. The resource based commitment underneath it keeps billing, because it was a commitment to a shape rather than to spend. The replacement workload runs uncovered at on demand rates. Google does not refund the unused commitment, so both lines bill simultaneously for the remainder of the term. Nothing went wrong operationally, and nobody made a bad decision in the moment. The hardware refresh that improved performance simply stranded a discount the buyer had already paid for.
The coverage ladder
- Base load: cover the always on floor with resource based commitments, where the deepest rate applies to hours that genuinely exist.
- Swing load: cover the predictable but shifting middle with flexible commitments that float across families and regions.
- Peak load: leave the spiky top on demand, where flexibility is worth the premium and a commitment would idle.
- Size from the billing export, not from a coverage target supplied by the account team, so decisions run on measured consumption.
- Match the term to the shape's stability, since three years is only cheap if the workload will still be that shape in year three.
- Track utilization continuously, because the boundaries between the three layers move as the estate changes, per the FinOps playbook.
The Google Cloud FinOps and commitment playbook
The coverage ladder, the utilization model, and the buyer side moves that hold the commitment honest across the term.
Get the playbook →Coverage is the vendor's metric, not yours
The account team pushes maximum coverage on the three year resource based commitment, because the deepest rate looks best on the slide. In the commitment reviews we ran it looked worst on the invoice, and the reason is structural rather than a matter of degree: the deepest rate is purchased by accepting the most specific lock, and specificity is exactly what an evolving estate cannot promise for three years.
The gap between headline and realized discount is where the argument gets settled. Up to 55 percent assumes perfect utilization across the full term, and no real estate achieves that. Subtract the idle slice and the same commitment lands at 38 to 50 percent, which is still a strong number and a different one. The realized band is the only figure worth comparing between options, and it is not the figure on the proposal. Once you compare on realized rate, a shallower flexible commitment that stays attached to running workloads frequently beats a deeper one that spent part of the term attached to nothing.
What makes this failure quiet is that the stranding event is a success elsewhere. An engineering team moves a workload to a newer machine family and gets better performance for less compute; nobody in that conversation is thinking about a commitment signed two years earlier by a different function. The commitment does not object, because it has no way to. It simply keeps billing at the shape it was told to hold, while the new workload bills at on demand rates alongside it. In our file that pattern left 18 to 26 percent of committed resource spend idle inside the term.
The correction is to stop treating coverage as the objective. Coverage is a proxy the vendor optimizes and the buyer funds. The number that matters is the net effective rate after stranded commitments, and it improves by committing only the durable base load deeply, floating the middle, and leaving the peak uncommitted. Estates that did this ran 8 to 14 percentage points cheaper net than estates that maximized coverage on one model. Size it from the billing export rather than a forecast, per the p20 sizing rule, and revisit the layer boundaries yearly. The wider negotiation sequence sits in the enterprise playbook.
Watch the briefing · 6:33Google Cloud: Is There Leverage? Five TacticsA credible alternative is the only lever that improves the committed use rate without committing you to more volume, and it exists before signing and evaporates after.
- CUD, EDP and MACC commits sized from your actual consumption curve
- Right sizing for databases, storage and compute schedules with dollar figures
- A ranked savings queue your team can work through
What the commitment file shows
Across roughly 25 to 35 Google Cloud commitment reviews in 2024 and 2025, the deepest rate was routinely the most expensive choice:
Inside the term, after a workload moved to a newer machine family and left the commitment attached to nothing.
For estates that blended flexible commitments over a resource based base load rather than maximizing one model.
The patterns: coverage treated as the objective, headline rates compared instead of realized ones, and three year shapes committed by estates that refresh hardware every two.
The buyer side move is to price the net effective rate, not the discount. The wider library sits in the Google Cloud practice.
Your first five moves
- Pull utilization from the billing export and measure how much of each existing commitment is actually attached to running workloads.
- Separate the estate into base, swing and peak from that data rather than from a forecast.
- Commit the base load resource based, and only for a term the machine shape will plausibly survive.
- Cover the swing layer with flexible commitments and leave the peak deliberately on demand.
- Compare options on realized rate after stranding, not on the headline. The Google negotiation service builds the ladder with you.
Frequently asked questions
What is the difference between resource based and flexible commitments?
A resource based commitment locks a fixed vCPU and memory amount in a region for the deepest rate. A flexible or spend based commitment pledges a dollar figure per hour that floats across machine families and regions for a shallower rate. The first locks the machine shape as well as the price, which is the whole difference.
Why does the realized discount sit below the headline?
Because the headline assumes perfect utilization for the full term. A three year resource based commitment lists up to 55 percent off and lands at 38 to 50 percent once the idle slice is subtracted, and every real estate idles a slice of every commitment it holds.
How often do commitments strand?
Three year resource based commitments stranded roughly 2 to 4 times more often than flexible ones when a region or machine family changed. Around 18 to 26 percent of committed resource spend sat idle inside the term after a workload moved to a newer machine family.
What is the double pay?
The stranded commitment keeps billing while the replacement workload runs uncovered at on demand rates, so you pay twice for the same capability. There is no clawback, because an unused resource based commitment is not refunded, which is why a hardware refresh inside the term is the expensive event.
What mix actually costs least?
A layered one. Estates that layered flexible commitments over a resource based base load ran 8 to 14 percentage points cheaper net than estates that maxed coverage on a single model. Cover the always on floor deep, the predictable middle flexibly, and leave the spiky peak on demand.
Is maximum coverage the goal?
No. Coverage is a proxy metric that the account team optimizes and the buyer pays for. The goal is the net effective rate after stranded commitments, which is a different number and frequently moves in the opposite direction to coverage.
How should commitments be sized?
From the billing export rather than from a coverage target. Track utilization through the billing data so coverage decisions run on measured consumption, and commit only the durable base load you can prove from history rather than the forecast you were shown.
When is a three year term the right choice?
When the workload will genuinely run the same shape for three years, which is rarer than it sounds once machine family refreshes and regional moves are considered. Where the shape is likely to change, the shallower flexible rate is usually the cheaper instrument on net.
Negotiating Google 7: Google's Playbook, and the Counters
Five moves Google runs in almost every account: land and expand credits, quarter end pressure, the engineered renewal cliff, deadline theater, and eligibility policing, each with the counter that works.
