A GCP Committed Use Discount is a trade of flexibility for a lower rate: you commit to one or three years of usage and pay roughly 20 to over 50 percent less than on demand, but you carry the risk that you will not use what you committed to. There are two forms with different trade points. Resource based CUDs commit to a specific machine type and region for the deepest discount and the least flexibility, while spend based CUDs commit to a dollar per hour of spend that applies across shapes within a service for more flexibility at a usually smaller discount. The buyer rule is that coverage follows a defensible forecast, not the maximum discount, because an unused commitment is a loss that can wipe out the saving on the rest.
This explains the instruments, the math of why coverage discipline beats discount maximising, and how to size a commitment you will actually use.
What are you committing to, exactly?
With a resource based CUD you commit to run a given amount of a specific machine type in a specific region for the term. The discount is the deepest available, but if you migrate the workload to another region or shape, the commitment does not follow you. With a spend based CUD you commit to a steady dollar per hour of spend on a service such as Compute Engine, and the discount applies to whatever eligible shapes you run up to that level, so it survives shape changes within the service. Both stack on top of sustained use discounts, which apply automatically. The practical reading is that resource based suits workloads pinned to a region and shape, and spend based suits estates where the mix of shapes shifts over time.
| Dimension | Resource based CUD | Spend based CUD |
|---|---|---|
| Commitment | Specific machine type and region | Dollar per hour of spend on a service |
| Discount depth | Deepest | Usually smaller |
| Flexibility | Low; tied to shape and region | Higher; applies across shapes |
| Best for | Stable workloads pinned to a region | Estates whose shape mix shifts |
Why does coverage discipline beat chasing the discount?
The headline discount is only realised if the committed capacity is used. Consider a simple case. A workload runs at a steady floor of demand all year, with peaks above it. If you commit to the floor, every committed hour is used and you bank the full discount on the most reliable part of the bill, while the peaks run on demand or on sustained use discounts. If instead you commit to the average, including peaks that only occur part of the time, you pay the committed rate for capacity that sits idle during the troughs, and the wasted commitment eats into the saving. Committing to the peak is worse still. The discipline is to commit to the floor you are confident in and let variable demand run uncommitted, because the floor is where the commitment is guaranteed to pay.
Plot your hourly usage for a service over the last quarter and find the floor that demand rarely drops below. That floor, not the average and not the peak, is the defensible commitment level. Commit there first, then revisit as the forecast firms up.
How do you size and stage commitments?
Build coverage in layers rather than one large purchase. Start with the floor of demand on the most stable workloads, where confidence is highest, and use one year terms where the forecast is less certain and three year terms only where you are confident the workload will persist and the deeper discount justifies the longer lock. Keep a portion of demand uncommitted so growth and migration have room, and revisit coverage on a regular cadence as the forecast firms up. Watch for workloads scheduled to change, because committing ahead of a migration or refactor is how commitments get stranded. The goal is high utilization of every commitment, not the largest possible discount on paper.
A worked example
A scaling fintech had committed to its average GCP compute usage, including seasonal peaks, and was paying the committed rate for capacity that sat idle through the quieter months. We replotted hourly demand, found the true floor, converted the over commitment toward spend based CUDs on the stable baseline, and left peak demand on a mix of on demand and sustained use discounts. Commitment utilization rose toward full, the stranded capacity disappeared, and effective compute cost fell, contributing to the work that left the estate materially lighter. Figures are verified against billing data and anonymized.
Where this fits
Choosing the form is covered in depth in spend based versus resource based CUDs, and setting the right coverage level is the subject of commitment coverage targets on GCP. The full GCP method, including how commitments sit alongside rightsizing and BigQuery, is in the GCP cost optimization guide, with the cross cloud commitment view in the cross cloud cost optimization guide.
Frequently asked questions
What is a GCP Committed Use Discount?
What is the difference between resource based and spend based CUDs?
How much do CUDs save?
Take the next step on your cloud spend
We are an independent buyer side advisory that cuts public cloud spend across AWS, Azure, GCP, and OCI. We hold over $2.4B in annual cloud spend under management, take zero provider commissions, and deliver a 31 percent median reduction in the first 90 days. Our guarantee is simple: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk to you.
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.