A committed use discount, or CUD, trades a one or three year commitment for a lower rate, and GCP offers it in two shapes. A spend based CUD commits to a dollar per hour of eligible spend on a service such as Compute Engine, and applies flexibly across machine families, sizes, and regions, so it follows your fleet as the mix changes. A resource based CUD commits to a specific quantity of vCPUs and memory in one region and machine family, giving a deeper discount in return for that specificity. Neither is the right answer alone. Resource based CUDs reward the stable core you are certain will not move; spend based CUDs cover the part of the floor that is steady in total but shifting in shape. The skill is splitting coverage so the deep discount lands on what is genuinely fixed and the flexible discount carries the rest, with commitments sized to a forecast you can defend.
Here is how each works, the lock in each carries, and how to divide the floor.
How does each CUD discount?
| Dimension | Spend based CUD | Resource based CUD |
|---|---|---|
| What you commit | A dollar per hour of eligible service spend | A quantity of vCPUs and memory |
| Flexibility | Across families, sizes, and regions | Fixed to one region and family |
| Discount depth | Lower, in exchange for flexibility | Deeper, in exchange for specificity |
| Best for | A steady total spend with a shifting mix | A stable, specific, long lived workload |
Both sit in roughly the 20 to 70 percent range against on demand depending on term, product, and configuration, with resource based generally deeper. All percentages are indicative; verify against current GCP pricing for your machine family and region before committing.
What does each lock you to?
The discount you accept is paid for with a constraint, and the two CUDs constrain different things. A resource based CUD locks the configuration: you have committed to vCPUs and memory in a specific region and family, so if you migrate to a newer machine type, change region, or shrink that workload, the commitment can strand. A spend based CUD locks the spend level but not the shape: it keeps applying as long as you run eligible spend at or above the committed rate, even as the underlying instances change, but it discounts less for that freedom. Read the constraint before the rate. A deep discount on a configuration you will abandon in six months is more expensive than a shallower one that survives a migration.
How do you split coverage between them?
Treat your committed floor as two layers. The bottom layer is the part of the fleet you are highly confident will stay on its current family and region for the term, for example a steady stateful tier with no migration planned; cover that with resource based CUDs to capture the deeper discount. Above it sits demand that is steady in total but likely to shift family or region as you adopt newer machine types or rebalance regions; cover that with spend based CUDs so the discount follows the change. Leave genuinely variable peak on demand, and never commit against a fleet you have not yet right sized, because committing first locks in waste. Monitor utilization so an underused CUD is caught and the next purchase corrected.
A worked example
A scaling fintech ran almost everything on demand and was about to buy a large resource based CUD across its whole fleet. The fleet was not as fixed as it looked: a major tier was scheduled to move to a newer machine family within the year. We split the floor. The stable database and a long lived processing tier, with no migration planned, went onto resource based CUDs for the deeper rate. The compute that would change family went onto spend based CUDs so the discount would follow the migration rather than strand. The variable daytime peak stayed on demand. Coverage matched defensible demand instead of the whole fleet, nothing stranded through the migration, and the purchasing redesign was part of the program that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
What is the difference between spend based and resource based CUDs?
Which CUD discount is deeper?
Can you stack CUDs with sustained use discounts?
Size your CUDs to a forecast you can defend
We model GCP demand and split CUD coverage between spend based and resource based commitments sized to a defensible forecast, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the GCP committed use discount kit, read the deeper GCP cost optimization guide, and set coverage targets with commitment coverage targets on GCP.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.