Compute Engine resource-based CUDs deliver 37 percent off three-year on-demand on locked machine types, while Flex CUDs deliver 28 percent off three-year on-demand on any compute usage in a region across machine families. The 9-point discount gap is the price of portability. For workloads that will never change machine family or region, resource-based CUDs are the better choice. For everything else, Flex CUDs preserve negotiating room and avoid the stranded-commit problem that catches every enterprise GCP buyer in year two. This page documents the math, the SKU coverage, and the workload patterns that decide which CUD class fits.
CUD discount tables for 2026
Google publishes CUD discount percentages by commitment term and product. The numbers below reflect the GCP public pricing as of Q1 2026 for North American regions. EU and APAC pricing vary by 2 to 4 percentage points in either direction depending on region.
| Commitment type | Term | Discount vs on-demand | Scope |
|---|---|---|---|
| Resource-based CUD (Compute) | 1 year | 20 percent | Specific machine family and region |
| Resource-based CUD (Compute) | 3 years | 37 percent | Specific machine family and region |
| Flexible CUD (Compute) | 1 year | 20 percent | Any machine family, single region |
| Flexible CUD (Compute) | 3 years | 28 percent | Any machine family, single region |
| Spend-based CUD (database) | 1 year | 25 percent | Cloud SQL, Cloud Spanner, Memorystore |
| Spend-based CUD (database) | 3 years | 52 percent | Cloud SQL, Cloud Spanner, Memorystore |
| CUD (sole-tenant nodes) | 3 years | 55 percent | Sole-tenant node groups |
The gap between resource-based and Flex CUDs grows wider as the commit term lengthens. At one year, both products deliver 20 percent. At three years, resource-based wins by 9 points. That gap reflects Google's view of the future-resale risk on flex commitments. Resource-based commitments lock the customer to a specific SKU, removing Google's exposure to changing customer mix.
Resource-based CUD: what you actually buy
A resource-based CUD purchases a specific quantity of vCPUs and memory within a specific machine family, in a specific region, for a specific term. A typical commit: 200 vCPUs and 800 GB of memory of N2 machines in us-central1 for three years. The commit applies automatically to matching usage. Any consumption above the commit pays on-demand. Any consumption below the commit pays the commit anyway (the "use it or lose it" mechanic).
The catch is the matching rule. The commit applies only to the exact machine family configured. An N2 commit does not match N2D, C2, C3, E2, or T2D usage. Workloads that migrate to a newer machine family for performance or price reasons strand the older commit until term-end.
Resource-based CUDs do not apply across regions. A commit in us-central1 does not match consumption in europe-west1. Multi-region deployments require commits in each region the workload runs.
| Scenario | Commit applies? |
|---|---|
| 200 vCPU N2 commit, 200 vCPU N2 in same region | Yes, full match |
| 200 vCPU N2 commit, 200 vCPU N2D in same region | No, stranded |
| 200 vCPU N2 commit, 200 vCPU N2 in different region | No, stranded |
| 200 vCPU N2 commit, 250 vCPU N2 in same region | Yes, 200 vCPU at commit rate plus 50 vCPU on-demand |
| 200 vCPU N2 commit, 150 vCPU N2 in same region | Yes, full 200 vCPU billed at commit rate (50 wasted) |
The stranded-commit pattern: Customers who bought N1 commits in 2020, then migrated to N2 in 2022, then to N2D in 2024, accumulated three layers of stranded commitments. A 2024 review of one Fortune 500 GCP estate found $1.8M in stranded resource-based commitments across N1, N2, and C2 generations. Flex CUDs would have preserved the discount through the migrations.
Flexible CUD: portability across families
Flex CUDs commit to a dollar amount of compute spend per hour in a region, regardless of machine family or specific SKU. The commit applies to any combination of N1, N2, N2D, C2, C3, E2, T2D, T2A, and the GPU-attached machine types in the committed region. The customer can shift workloads across families without losing the discount.
Flex CUDs do not apply to all GCP services. Out of scope: GKE Autopilot, App Engine Flexible, Cloud Run, Cloud Functions, Bare Metal Solution, and most specialised compute (TPUs). For workloads that primarily run on Compute Engine VMs or GKE Standard, Flex CUD coverage is comprehensive. For workloads heavy on serverless, the Flex CUD discount captures less of the bill.
The discount is 28 percent at three years versus 37 percent for the equivalent resource-based commit. The trade-off is therefore 9 percentage points of discount in exchange for the right to repurpose the commit across machine families and changing workload mix.
Decision framework: which CUD fits which workload
The decision rule is straightforward. Workloads with stable, predictable machine-family selection over the commit term should use resource-based CUDs to capture the full 37 percent discount. Workloads with any reasonable probability of migrating across machine families should use Flex CUDs to preserve the discount through the change.
| Workload pattern | Recommended CUD | Reasoning |
|---|---|---|
| Legacy ERP on dedicated N2 VMs, no migration planned | Resource-based N2 | Captures full 37 percent; migration risk near zero |
| Kubernetes platform with mixed machine families | Flex CUD | Pool size changes; family mix shifts as workloads evolve |
| Stable production database on Cloud SQL | Spend-based CUD (database) | 52 percent at three years; better economics than compute CUD |
| Data engineering platform on Dataproc, ad-hoc | Flex CUD plus on-demand | Variable usage; Flex absorbs the baseline |
| GenAI inference on GPU machines (A100, H100) | Resource-based GPU CUD | GPU machine family rarely migrates; capture the deeper discount |
| Mixed multi-region production | Flex CUD per region | Per-region commits give shorter-stranded exposure |
A common hybrid pattern: cover 60 to 70 percent of the predictable production base with resource-based CUDs and lay Flex CUDs on top for the variable tier. The blended discount lands at 32 to 35 percent. The customer captures most of the resource-based premium while preserving optionality for the variable portion of the estate.
Purchase options and renewal mechanics
Both CUD types are available as upfront paid, monthly paid, or annual paid. Upfront payment unlocks an additional 0 to 2 percent discount depending on commitment value. Annual payment is the most common enterprise pattern. Monthly payment carries no payment-term penalty but does not capture the upfront discount sleeve.
At term-end, neither CUD type auto-renews. The customer must purchase a new commitment or accept on-demand billing on the previously committed capacity. This is a positive feature, not a negative one. Auto-renewing commitments at terms that may not match the customer's evolving workload mix are a common SaaS trap. GCP CUDs default to manual renewal.
CUDs are non-cancellable for their term. The customer who buys a three-year commit cannot return it for partial refund. The commit applies as a non-recurring monthly charge regardless of consumption. Sizing discipline is therefore the single most important commit decision.
Negotiation lever: For enterprise customers with committed Google Cloud spend through a Customer Annual Spend Commitment (CASC), additional CUD discount of 3 to 7 percentage points can be negotiated outside the public discount sleeve. Google account teams treat CUDs as a strategic lever for committed customers. The negotiation move is to bundle CUD discount escalation into the broader CASC discussion, not to negotiate CUDs in isolation. See our GCP Enterprise Agreement guide for the CASC commercial framework.
CUDs versus AWS Savings Plans and Azure Reservations
The closest AWS analogue to Flex CUD is the Compute Savings Plan. Both commit to a dollar amount of compute spend per hour and apply across instance families and AWS regions. The discount level on a three-year Compute Savings Plan is 50 to 66 percent off on-demand depending on instance type, materially higher than the 28 percent Flex CUD discount. The AWS counterpart is therefore better economics, with the caveat that the Savings Plan applies across AWS regions while Flex CUD is regional only.
The closest Azure analogue is the Azure Savings Plan for Compute. Three-year discount is 5 to 11 percent versus Reserved Instances at 30 to 40 percent. Azure's flex-style commit is therefore meaningfully weaker than either AWS or GCP. Azure customers seeking flex behaviour typically combine 1-year Reserved Instances with the Savings Plan to cover the variable tier.
The cross-cloud comparison favours AWS on flex commit economics, GCP on database CUD economics (52 percent at three years), and Azure on hybrid scenarios where Hybrid Benefit stacks with Reserved Instance discounts. See our AWS vs Azure vs GCP pricing comparison for the full pricing model.
For the broader GCP commercial structure, see GCP Enterprise Agreement, Google Cloud CUD overview, and the Google Cloud vendor hub. For workload-specific guidance, see our cloud cost optimization guide and the cloud portability comparison. Engagement starts at cloud contract negotiation.