Google Cloud committed use discounts cut compute costs by up to 70 percent on resource-based three-year commitments and by 20 to 57 percent on flexible spend-based commitments, in exchange for a one or three year lock to a minimum hourly resource use or hourly spend. The discount is real and large, but the lock is real too, and the buyers who save the most are the ones who commit to the floor of their usage rather than the forecast their account team prefers.
What a committed use discount is
A committed use discount, or CUD, is Google Cloud's mechanism for trading a usage commitment for a lower rate. You agree to use, or to spend, a defined amount for a one or three year term, and in return Google charges that usage at a discount to on-demand pricing. The model rewards predictability: Google gets guaranteed revenue and you get a lower unit price, with the deepest discounts reserved for the longest commitments on the most specific resources. Unlike a sustained-use discount, which Google applies automatically for running an instance most of the month, a CUD is a deliberate commitment you make in advance, and that commitment is binding whether or not you use what you committed to. Understanding the two commitment shapes Google offers is the first decision.
Resource-based versus spend-based commitments
Google offers two CUD shapes, and they trade flexibility against discount depth. The table sets out the difference.
| Attribute | Resource-based CUD | Spend-based CUD |
|---|---|---|
| Commit to | Specific vCPU and memory in a region | A dollar-per-hour spend on a service |
| Discount depth | Deepest, up to ~70% (3-year) | Lower, ~20-57% by service |
| Flexibility | Low, tied to machine type and region | High, applies across eligible usage |
| Best for | Stable, known workloads | Changing or mixed workloads |
| Main risk | Stranded commit if workload moves | Smaller discount left on the table |
Resource-based commitments give the biggest discount but bind you to a specific machine type and region, so if the workload moves or changes shape, the commitment can strand. Spend-based commitments give a smaller discount but apply flexibly across eligible usage, so they tolerate change. The right choice depends on how stable and how specific your workload is, and most large estates use both, resource-based for the stable core and spend-based for the variable layer.
The stranded-commitment trap: A resource-based CUD is tied to a specific machine family and region, so if you re-architect, move regions, or migrate to a newer instance type, the commitment can be left paying for capacity you no longer use. Before taking the deepest resource-based discount, confirm the workload is genuinely stable for the full commitment term, and prefer spend-based commitments for anything you expect to change. The deepest discount on the wrong commitment shape costs more than a shallower discount that flexes with your usage.
The discount rates by service
CUD rates vary by service and term, and the spread is wide enough to change which workloads are worth committing. Compute Engine resource-based three-year commits reach the deepest discounts, around 70 percent off on-demand for the committed vCPU and memory. Spend-based commits on Compute Engine sit lower, and other services such as Cloud SQL, Google Kubernetes Engine Autopilot, and certain analytics and AI services carry their own published CUD rates, generally in the 20 to 57 percent range depending on service and term. The practical implication is to commit hardest where the discount is deepest and the workload is most stable, and to leave variable or short-lived workloads on on-demand or spend-based commits. The full Google Cloud pricing structure these rates sit within is covered in our Google Cloud licensing guide.
Sizing the commitment
The single most important decision in a CUD is the commitment level, and the safe rule is to commit to the floor of your usage, the level you are confident you will use regardless of what happens, rather than to your average or your forecast. Committed usage is billed whether or not you consume it, so a commitment set above your true floor pays for capacity you may not use, erasing the discount you committed to win. Analyze at least the trailing 12 months of usage, find the stable baseline that persists through normal variation, and commit to that baseline. Leave the variable layer above it on on-demand or spend-based commitments, where flexibility matters more than the deepest rate. This is the same conservative-commit discipline that governs all usage-metered pricing, covered in our consumption-based licensing models guide.
CUDs inside an enterprise agreement
For large customers, CUDs do not sit alone; they sit inside a Google Cloud enterprise agreement that can add a further negotiated discount on top of the published CUD rates, along with committed-spend incentives and custom terms. The published CUD rate is the floor of what a large buyer should pay, not the ceiling, because the enterprise agreement layer is negotiable and Google discounts meaningfully against committed spend and competitive pressure. How the agreement layer works and what is negotiable in it is covered in our GCP enterprise agreement guide. Treating the published CUD rate as the final price, rather than as the starting point for the enterprise negotiation, leaves the most accessible savings on the table.
How CUDs compare to AWS
Buyers running multiple clouds often want to compare Google's CUDs to the AWS commitment models, and the structures rhyme but differ in flexibility and rate. AWS savings plans and reserved instances trade the same commitment-for-discount logic, but the specific flexibility rules, the way commitments apply across instance families, and the discount depths differ enough that a direct comparison matters when you are choosing where to place a workload. Our GCP CUD vs AWS savings plan guide sets the two side by side, and the broader Google Cloud commercial position sits in our vendor hub at Google Cloud advisory. The right cloud for a committed workload is sometimes decided by which commitment model fits its shape best, not by the on-demand price.
Stacking CUDs with sustained-use and flex discounts
CUDs do not operate in isolation, and understanding how they interact with Google's other discount mechanisms changes how you should size them. Sustained-use discounts apply automatically to Compute Engine usage that runs for a large share of the month, so a portion of your steady workload is already discounted before any commitment, which means committing the full amount can double-count savings you would receive anyway. Flexible CUDs apply across machine types and regions within a service, trading some discount depth for the ability to shift workloads without stranding the commitment. The right structure layers these deliberately: take resource-based commits only on the genuinely fixed core, use flexible or spend-based commits for the variable layer, and let sustained-use discounts cover the rest. Mapping which discount applies to which slice of usage is the analysis that prevents over-committing, and it sits inside the broader pricing structure covered in our GCP enterprise agreement guide.
Governing commitments after you sign
A CUD is a financial instrument that has to be managed for its full term, not a setting you configure once and forget. Commitments expire, and an expired CUD silently reverts usage to on-demand pricing, so a calendar of commitment end dates with renewal decisions scheduled ahead of each one prevents a quiet price jump. Utilization needs monitoring too, because a commitment running below the level you committed to is wasted spend that should prompt either a workload shift onto the commitment or a smaller renewal. The discipline mirrors the guardrails any usage-metered contract needs, covered in our consumption-based licensing models guide: tag usage to owners, alert on utilization, and review the top commitments on a regular cadence. A CUD portfolio left ungoverned drifts into a mix of expired commitments paying on-demand and underused commitments paying for idle capacity, which is the opposite of the saving the commitment was meant to deliver.
A worked commitment-sizing example
The sizing rule is clearest in numbers. Take a workload whose Compute Engine usage over the past year ranged from a low of 600 vCPUs to a peak of 1,000, with a steady baseline of about 650 that persisted through normal variation. A buyer who commits to the 850 average, splitting the difference, locks in a three-year resource-based rate on capacity that frequently sits idle, paying for roughly 200 vCPUs of headroom that the workload only occasionally uses. A buyer who commits to the 650 baseline instead takes the deep resource-based discount on the capacity that is always running, covers the variable layer above it with a flexible spend-based commit, and lets sustained-use discounts catch the rest, paying the deepest rate only on usage that genuinely earns it. Across a three-year term, committing to the baseline rather than the average on this workload avoids tens of thousands of dollars in stranded commitment while still capturing the headline discount on the stable core. The lesson is the same one the whole guide turns on: the discount is only a saving on capacity you would have used anyway.
Common CUD mistakes to avoid
Four mistakes account for most wasted commitment spend. The first is committing to the average rather than the baseline, which locks in capacity that sits idle during normal troughs. The second is taking a resource-based commit on a workload that is about to be re-architected or moved, stranding the commitment on a machine type the workload abandons. The third is forgetting that sustained-use discounts already cover steady usage, so a full commitment double-counts savings the platform grants automatically. The fourth is letting commitments expire unnoticed, silently reverting usage to on-demand pricing and quietly raising the bill. Each of these is avoidable with a single discipline: analyze real usage before committing, match the commitment shape to the workload's stability, and govern the commitment portfolio on a calendar after signing. Buyers who treat a CUD as a one-time purchase rather than a managed position pay for the difference, while those who size to the durable baseline and review the portfolio regularly capture the full discount the commitment was meant to deliver, the same governance principle in our consumption-based licensing models guide.
The buyer's takeaway
Google Cloud committed use discounts are among the largest cost savings available on the platform, but the discount is only a saving if the commitment matches your real, durable usage. Commit to the floor not the forecast, choose resource-based commits for stable workloads and spend-based for changing ones, treat the published rate as the starting point for an enterprise negotiation rather than the final price, and confirm a workload is genuinely stable before taking the deepest, most specific discount. We model GCP usage and negotiate the enterprise terms on top of CUD rates through our cloud contract negotiation and software licensing advisory practices. The deepest discount on the wrong commitment is more expensive than a modest discount on the right one.