Google Cloud CUDs: the eight buyer levers that protect the commitment
A three year Compute Flex CUD pays a flat 46 percent, but it bills the committed dollar every hour whether you use it or not. The discount is the easy part. The clauses, the baseline, and the staging decide whether the commit protects your budget or traps it.
Prepared by Redress Compliance · June 2026 · Representative Google Cloud estate scenario (benchmark scenario, not a quote)
Executive summary
Google Cloud Committed Use Discounts are not one instrument. They are three: resource based CUDs locked to a machine series and region, Compute Flex CUDs that commit a dollar per hour across families, and spend based CUDs for BigQuery, Vertex AI, and other services. Each carries a different discount, a different scope, and a different trap.
The headline rates are public. Resource based CUDs reach up to 55 percent on a three year steady commit. Compute Flex CUDs pay a flat 46 percent at three years and stay transferable. BigQuery Enterprise slots and Vertex AI both reach about 40 percent at three years.
The number Google will not volunteer is the floor. A CUD bills the committed amount every hour, so over committing past your verified baseline is pure waste under the consumption model that took effect July 15, 2025.
On a representative $14.0M annual estate, a baseline anchored program cuts run rate to $10.28M, a saving of $3.72M or about 27 percent, without committing a dollar above verified steady state. The leverage is in five clauses and a staged commit, not in chasing the deepest headline discount.
How is a Google Cloud CUD actually priced in 2026?
A Google Cloud CUD is a discount in exchange for a one year or three year promise, and the promise comes in two shapes. You either commit to specific resources (a count of vCPUs and memory in one region and machine series) or to a dollar amount of spend. The shape you pick decides how much flexibility you keep.
Google rebuilt the spend based model in 2025. The new consumption based mechanic became effective for new customers on July 15, 2025, replacing the legacy system where credits offset usage billed at list price. Under the new model, the discount is applied to the rate at consumption. That sounds cosmetic. It is not.
Three instrument families matter for a 2026 negotiation. The discount, scope, and transferability of each are below.
Chart A. Indicative discount off on demand by instrument and term. Resource based reaches highest on steady single family usage; Flex trades depth for transferability.
Which CUD instrument fits which workload?
Match the instrument to the volatility of the workload, not to the size of the discount. A deep resource based commit on a fleet you are about to re architect is the most expensive mistake in this market.
| Instrument | Scope | 1 year | 3 year | Transferable |
|---|---|---|---|---|
| Resource based CUD | vCPU and memory, one region, one machine series | ~37% | up to 55% | No |
| Compute Flex CUD (spend) | $/hour across families, regions, GKE, Cloud Run | ~28% | 46% | Yes |
| BigQuery edition commit | Enterprise slot hours, per region | 20% | 40% | Within edition |
| Vertex AI spend CUD | Eligible model serving and training spend | ~20% | ~40% | Within scope |
Three rules from the engagement file decide the split.
- Stable single family core: resource based three year on the part of the fleet that has not changed shape in twelve months. This is where the up to 55 percent lives, per Google's CUD documentation.
- Mixed or migrating workloads: Compute Flex CUD. You give up roughly nine points of discount versus resource based, and in return the commit follows you across N, C, and E series and across regions, and across GKE and Cloud Run.
- Variable top layer: leave on demand or autoscale. Never commit it.
How does the Vertex AI commitment overlay change the math?
Vertex AI spend can be folded into a spend based CUD, with discounts in the same band as compute, roughly 20 percent at one year and up to about 40 percent at three years on eligible usage. The overlay matters because AI spend is the fastest growing and least predictable line in most 2026 estates.
Treat the Vertex commit as a hedge, not a forecast. Commit the floor of your inference spend, the part that runs every day in production, and keep training and experimentation on demand. Training spikes that you committed against become the over commit waste that the post July 2025 model no longer forgives.
The packaging overlap to watch
Vertex AI list pricing for Gemini models is published per token on the Google Cloud pricing pages. A spend based CUD discounts the dollar, not the token rate, so a mid term price cut on the underlying model flows through to you only if your clause pins the discount to net spend at then current rates. Pin it.
How do BigQuery editions map to a commitment?
BigQuery commitments only exist on the edition tiers. On demand and the Standard edition do not take a slot commitment, so the commitment decision starts with the edition choice.
Enterprise edition lists at $0.06 per slot hour on demand. The one year commit drops it to $0.048 and the three year commit to $0.036, the 20 and 40 percent steps you see across the spend instruments.
| BigQuery Enterprise | Slot hour rate | Discount | Commit shape |
|---|---|---|---|
| On demand / pay as you go | $0.060 | 0% | None |
| 1 year slot commit | $0.048 | 20% | Baseline slots, per region |
| 3 year slot commit | $0.036 | 40% | Baseline slots, per region |
Two mechanics from Google's BigQuery CUD documentation change the buyer move. First, slot commitments are regional, so a multi region estate needs a baseline per region, not one global number.
Second, autoscale slots above the commit bill at the edition on demand rate. The commit should sit at your steady floor and let autoscale handle the peaks. Commit the floor, autoscale the spikes.
How do egress credits and the Marketplace pull through stack with CUDs?
Two non CUD levers belong in the same negotiation because they move the same total. The first is data transfer. Egress is rarely discounted in the CUD itself, so it has to be negotiated as a separate credit or commit line, and it is the cost that most often surprises a finance team at renewal.
The second is the bigger structural advantage. Google Cloud Marketplace third party purchases retire your Google spend commitment at up to 100 percent, not the 25 percent cap AWS applies to most Marketplace spend. That asymmetry is a genuine buyer advantage.
Use the Marketplace pull through as a relief valve on the overall agreement commit, not as a reason to inflate the CUD. The two commitments are different. The CUD discounts compute and service rates; the Marketplace credit helps you attain the broader Google Cloud agreement spend floor.
How should you build a baseline and stage the commit?
The baseline is the whole game. A CUD sized to a Google forecast is a CUD sized to Google's interest. A CUD sized to your verified consumption floor is sized to yours.
Build the floor from twelve months of billing export. Map it to families and regions, and commit between the 25th and 50th percentile of steady usage, never the peak.
Baseline
Export twelve months of detailed billing. Map consumption to machine families, regions, and services. Set the committable floor at the p25 to p50 of steady usage, stripped of one off spikes.
Model and clause
Size each commit to the verified floor. Draft the five clauses: re mix, true down, exit, renewal rate, and shortfall recovery. Model resource versus Flex per workload.
Negotiate and stage
Benchmark the opening quote, stage the commit between a base tier and a variable tier, and hold the discount counter until the clauses close. Sign at quarter end for timing leverage.
Applied to a representative estate, the staging looks like the table below. Each workload is committed only to its steady share, with the variable remainder left on demand.
| Workload | On demand annual | Committed share | Instrument, 3 year | Committed annual |
|---|---|---|---|---|
| Compute Engine, GKE, Cloud Run | $8.0M | 75% ($6.0M) | Flex plus resource, 40% blended | $5.60M |
| BigQuery Enterprise slots | $3.0M | 70% ($2.1M) | Edition commit, 40% | $2.16M |
| Vertex AI | $2.0M | 60% ($1.2M) | Spend CUD, 40% | $1.52M |
| Egress and other | $1.0M | Marketplace and credit lever | n/a | $1.00M |
| Total estate | $14.0M | about 67% committed | blended | $10.28M |
Benchmark scenario, not a quote. Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.
Chart B. Representative $14.0M estate. Committed program run rate $10.28M, a $3.72M or about 27 percent reduction, with no commit above verified steady state.
Which five contract clauses decide whether the commit protects the budget?
The discount is one line. The five clauses below are what stand between you and a year end true up. Negotiate them before you trade the discount, because Google concedes terms more easily while the discount is still open.
| Clause | What it protects | Buyer side ask |
|---|---|---|
| Re mix rights | Freedom to shift commit across families, regions, and services | Quarterly re mix at no penalty, in writing |
| True down | Relief when the estate shrinks | Defined reduction points at each anniversary |
| Exit terms | What happens to unused commit at renewal or termination | Credit or portability of unconsumed commit |
| Renewal rate | Protection against renewing at then current list | Renew at the original negotiated rate, not list |
| Shortfall recovery | Grace if you miss the commit | Carry forward window and a clear net spend definition |
The auto renewal trap
CUDs renew automatically at the end of the term. Many agreements default that renewal to the then current rate rather than the rate you negotiated, and the cancellation window is short. Put the renewal rate and a clear cancellation notice period in writing, or you will re sign your hard won discount away by silence.
What buyer side moves neutralize Google's standard tactics?
The account team runs a familiar playbook. Each move has a counter that costs you nothing but preparation.
| Google move | What it sounds like | Buyer counter |
|---|---|---|
| Anchor to forecast | Commit to your projected growth for the deepest rate | Commit to verified p25 to p50 floor only |
| Three year push | Three years unlocks the best discount | Three year on stable base, one year on the rest |
| Discount for silence on terms | Lead with the headline percentage | Hold the discount counter until clauses close |
| Quarter end urgency | This rate expires at period end | Use their quarter end as your timing leverage |
| Bundle the renewal | Roll it into the broader agreement | Keep CUD terms itemized and separately exitable |
Benchmarks from the engagement file frame what good looks like across scenarios. Greenfield commits land deepest; shortfall positions land worst.
Flat rate across families and regions, fully transferable.
Enterprise slots at $0.036 and eligible AI spend at the same step.
The worked $14M estate at $10.28M, baseline anchored.
Lost when the commit is sized to forecast, not the verified floor.
Chart C. Effective discount achieved by scenario. Source: Redress Compliance advisory engagement file, 2024 to 2025.
Where the common advice on Google Cloud CUDs is wrong
The standard reseller and account team pitch is simple: commit three years against your forecast to capture the deepest discount. We disagree. In the renewals we have benchmarked, the forecast anchored three year commit is the single most reliable way to overpay.
Two reasons. First, a three year commit on your full forecast removes the re mix freedom you need when you migrate machine families or re architect, and resource based CUDs do not transfer. You end up paying the old commit and the new usage at once.
Second, since the July 2025 consumption model, over committing is unrecoverable waste rather than a credit you can spill elsewhere.
The buyer side move is to commit the verified base at three years and keep the variable tier on one year Flex or on demand. You trade a few points of headline discount for the right to be wrong about your forecast without paying for it.
The contrarian line: the deepest discount on the wrong baseline loses to a smaller discount on the right one. Size the commit to what you have verified, not to what Google forecasts.
What is your BATNA and the side letter language?
A CUD negotiation without a credible alternative is a price taker negotiation. Build the BATNA before the first call, and make sure the account team knows it exists.
- Azure: a Microsoft Azure Consumption Commitment with reservations and savings plans, sized to the same baseline.
- AWS: Savings Plans or an EDP for the portable workloads, priced for comparison.
- OCI: Oracle Cloud Universal Credits for the database heavy share, where the rates often undercut.
- Stay on demand: the always available alternative that caps your downside if the terms are wrong.
Side letter language we use
Pin the protections in a side letter when the standard order form will not carry them. Three clauses do most of the work.
- Re mix: a right exercisable quarterly at no penalty.
- Renewal: renew at the original negotiated rate with a defined cancellation notice.
- Shortfall: a carry forward window with net spend defined to include Marketplace pull through.
Get these in writing or treat the discount as unprotected.
Recommendation. Size the commit to your verified floor, win the five clauses, then trade the discount.
- Do this first: build the twelve month baseline, commit between the p25 and p50 of steady usage, and split three year resource on the stable core from one year Flex on the rest.
- Do this next: close re mix, true down, exit, renewal rate, and shortfall recovery before you accept the headline percentage, and route eligible third party spend through Marketplace for full commitment attainment.
We work on the buyer side only, and we are glad to tie a meaningful part of the fee to delivered value.
Frequently asked questions
What is the difference between resource based and Flex CUDs?
Resource based CUDs commit specific vCPUs and memory in one region and machine series and pay up to 55 percent at three years, but they do not transfer. Compute Flex CUDs commit a dollar per hour, pay a flat 46 percent at three years, and follow you across families, regions, GKE, and Cloud Run.
Does an unused CUD get wasted?
Yes, under the consumption model effective July 15, 2025. A CUD bills the committed amount whether or not you consume it, and the unused portion no longer spills onto other usage as credits did. Over committing is now a direct loss, which is why the baseline matters.
Can Marketplace spend reduce my Google commitment?
Yes. Eligible Google Cloud Marketplace third party purchases retire your Google spend commitment at up to 100 percent, far more generous than the 25 percent cap AWS applies. Route software you would buy anyway through Marketplace to help attain the commit and avoid a shortfall.
Should I always pick the three year term?
No. Pick three years only for the stable base that has not changed shape in twelve months. Keep variable and migrating workloads on one year Flex or on demand, because a three year commit on a forecast you cannot hold becomes unrecoverable waste.
Renewing a Google Cloud commitment?
Talk to a buyer side advisor. Thirty minutes, your consumption baseline and the five terms worth pinning, before the account team sets the commit for you.
Buyer side intelligence, monthly
One letter a month. Negotiation moves, audit signals, and price book shifts.