Google Cloud Committed Use Discount optimisation.
Google Cloud's discount architecture works differently from AWS and Azure — built on Sustained Use Discounts, resource- and spend-based Committed Use Discounts, and Custom Pricing Agreements rather than a single commitment vehicle. This note sets out how the instruments stack, which discount each earns, and how to build a coverage strategy that captures depth without over-committing.
No single instrument optimises Google Cloud spend. Sustained Use Discounts are free and automatic; resource-based CUDs reach 55% but lock machine family and region; spend-based CUDs trade depth for flexibility. The winning posture layers all three — then, above $1M annual spend, a Custom Pricing Agreement negotiated against a credible AWS or Azure alternative captures the discretionary discount on top.
01 Key findings
Google Cloud discounts automatically; AWS and Azure do not. Sustained Use Discounts scale to 30% for full-month Compute Engine utilisation with zero commitment — a base cost reduction the other hyperscalers require active RI or Savings Plan management to match.
Resource-based CUDs are the deepest but least flexible. They earn 37% for one-year and 55% for three-year commitments, but bind you to a specific machine family and region; move from n2 to c2 and the commitment does not follow.
Spend-based CUDs trade discount for portability. At 17% (one-year) and 22% (three-year) they apply across eligible services regardless of instance type or region — the right vehicle for migrating or evolving estates.
Coverage is an allocation problem. Over-committing to resource CUDs before architecture stabilises creates waste; relying only on spend CUDs forgoes the deeper rate on stable workloads. The value is in splitting the two correctly.
CPAs reward preparation, not size alone. GCP's commercial teams have genuine discretion above $1M spend, but without independent benchmarks a buyer cannot tell a competitive offer from one that merely beats list.
Migration credits must be modelled net. $100K–$1M+ incentives are real value, but weaker per-unit economics can repay them many times over across a three-year term.
02 CUD types & discount rates
The foundational distinction in Google Cloud cost optimisation is resource-based versus spend-based CUDs. They serve different workloads and earn materially different discounts by term.
| CUD type | Commitment basis | 1-year discount | 3-year discount | Best for |
|---|---|---|---|---|
| Resource-based | vCPU / memory / GPU in a specific region and machine family | 37% | 55% | Stable compute, defined architecture |
| Spend-based | $/hour across eligible services | 17% | 22% | Mixed workloads, migration, evolving architecture |
| Sustained Use | Automatic, no commitment (Compute Engine) | — | up to 30% | Variable workloads above 25% monthly use |
Most enterprise strategies combine both CUD instruments: resource-based cover for the stable, identifiable compute base, and spend-based cover for the variable or service-mixed remainder. Commit only to spend-based CUDs before your architecture stabilises — the deeper resource rate is captured later, as workloads settle.
03 Discount depth compared
Discount off on-demand pricing by instrument and term. Depth and flexibility move in opposite directions — the deepest rate is also the most tightly bound to specific resources.
Ladder the commitment. Cover the workload floor — the compute you are certain to run for three years in fixed regions — with three-year resource CUDs at 55%. Layer one-year resource CUDs on the next, less certain tranche, then spend-based CUDs on the flexible remainder, and let free SUDs absorb everything above 25% monthly use. Laddering terms this way captures depth on the stable base while keeping the volatile portion adjustable.
04 Sustained Use Discounts
Sustained Use Discounts apply automatically and without commitment. Run a Compute Engine instance for more than 25% of a billing month and Google begins applying incremental discounts that scale to a maximum of 30% at full-month utilisation. These sit beneath any negotiation and provide a base reduction AWS and Azure do not offer through equivalent mechanisms.
CUDs and SUDs interact. When you hold a resource-based CUD, SUDs still apply to usage above your CUD allocation — but because the committed portion is already deeply discounted, the incremental SUD value on CUD-covered resources is lower than on uncovered resources. For workloads that fluctuate above the 25% threshold yet do not justify a full commitment, the choice between a spend-based CUD and relying on SUDs alone turns on stability: at 70%+ consistent monthly utilisation a spend-based CUD is almost always superior; below 40% monthly utilisation, SUDs alone may suffice.
AWS has no equivalent to SUDs. Every AWS compute discount requires explicit action — an RI purchase or a Savings Plan. Google Cloud is therefore inherently more cost-efficient for variable workloads that AWS only optimises through active management. When modelling true cost of ownership across providers, include this structural difference rather than comparing headline committed rates alone.
05 Custom Pricing Agreements
Above $1M in annual Google Cloud spend, the Custom Pricing Agreement opens a negotiation layer beyond self-service CUDs. CPAs are private, negotiated arrangements that can include service-specific discounts beyond standard CUD rates, egress credits, support customisation, migration incentives and — in strategic cases — committed usage credits and proof-of-concept subsidies.
The CPA process is less standardised than AWS's EDP, which is both opportunity and risk. GCP commercial teams have genuine discretion to structure creative arrangements, so a well-prepared buyer arriving with credible competitive alternatives and specific requests will often beat standard terms. The risk is that, without independent benchmarks, it is hard to judge whether a CPA offer is genuinely competitive or merely better than list. The most effective negotiations occur inside a real competitive evaluation, are specific about service-level discounts on highest-spend services, and frame the deal as a primary-cloud commitment to unlock GCP's share-growth discretion.
Migration incentives are not free money. Google has historically offered $100K to $1M+ in migration credits to move workloads off AWS or Azure. Accept $500K in credits against per-unit economics 15% higher than AWS for your workload mix and you repay them many times over across a three-year term. Model the platform's long-run unit cost, then treat credits as a one-off offset — never as the basis of the decision.
06 CUD selection framework
Four inputs decide how spend should be split across instruments. Assess each before committing any tranche.
Workload stability
Only compute with 80%+ consistent monthly utilisation, fixed regions and defined machine types belongs in three-year resource CUDs. Everything less certain stays in shorter or spend-based cover.
Architecture maturity
Still migrating or optimising machine families? Favour spend-based CUDs, which follow the estate. Resource CUDs suit settled architectures where machine type and region will not move.
Utilisation profile
Above 70% consistent monthly use, commit. Between 40% and 70%, weigh spend CUDs against SUDs. Below 40%, automatic SUDs may be sufficient on their own.
Spend scale
Above $1M annually, self-service CUDs are the floor, not the ceiling — a CPA should be negotiated on top against a credible competitive alternative.
07 Coverage recommendations
Use for the compute floor you will run for three years in fixed regions with settled machine families. Capture the 55% rate — but size it below certain demand so you are never paying commitment plus on-demand after an architecture change.
Use for variable, service-mixed or migrating spend where instance types and regions will move. Accept the lower 17–22% rate as the price of portability across eligible services.
Let free SUDs cover the fluctuating remainder, and above $1M spend negotiate a CPA on top — specific service discounts, egress credits and migration terms, benchmarked against AWS or Azure.
08 Optimisation sequence
The order of operations matters as much as the instruments. Baseline first, then commit from the stable base outward.
Baseline, then ladder Recommended
Measure spend by service, region and workload and the SUD benefit you already receive. Cover the stable compute floor with three-year resource CUDs, layer spend-based cover on the variable remainder, and open a CPA above $1M — each commitment sized to demonstrated demand.
Commit first Weaker
Buying deep resource CUDs before the estate stabilises locks machine families and regions that then change — leaving you paying the commitment while consuming different compute at on-demand rates.
Optimise your Google Cloud coverage
Our Cloud & FinOps practice models CUD coverage, benchmarks CPA offers and negotiates on your behalf.
The Licensing Edge
Weekly cloud and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.