Google Cloud Committed Use Discounts. Up to 70 percent off three year on resource based, and a commit shortfall trap most customers walk into.

Google Cloud Committed Use Discounts (CUDs) are the published commitment vehicle for GCP compute and selected services. They come in three variants, each with its own discount ceiling and flexibility profile.

• Resource based CUDs. Commit to a specific vCPU and memory allocation in a specific region for one or three years, with the deepest discount: up to 57 percent off on demand for one year and up to 70 percent off for three years on stable Compute Engine workloads.
• Spend based CUDs. Commit to a dollar hourly spend rate against a service family (Cloud SQL, Cloud Run, Cloud Spanner, Bigtable, BigQuery slot pricing) for one or three years, with discounts typically in the 20 to 28 percent range.
• Flexible CUDs. A newer variant that commits to a dollar hourly Compute Engine spend across machine families and regions, delivering up to 46 percent off on demand for three years with materially better flexibility than resource based.

The three variants stack with sustained use discounts (automatic up to 30 percent on long running Compute Engine instances) and with any negotiated PPA discount on top. This paper sets out actual CUD discount rates, the three variant decision logic, the under utilization trap, the commit shortfall risk, and the eleven move buyer side playbook. Read the related Google Cloud services practice, the Google Cloud PPA negotiation, and the GCP negotiation leverage framework.

The three CUD variants compared

Resource based delivers the deepest discount but the lowest flexibility. Flexible delivers the best balance for most Compute Engine estates with mixed machine families. Spend based is service specific and only worth running on managed services where there is no resource based option.

Resource based CUDs: when they win

Resource based CUDs apply to a specific vCPU count and memory amount in a specific region, for a specific machine family (n2, n2d, c3, e2, etc.). A three year resource based CUD on n2 standard delivers approximately 57 percent off on demand pricing. The commitment is rigid: the customer pays for the committed capacity regardless of whether it is consumed, and changes to machine family or region require burning the original CUD and starting over. Resource based works for predictable steady state workloads where the customer has high confidence in the instance mix for three years. Production application servers, predictable database tiers, and stable analytics infrastructure are typical candidates.

Spend based CUDs: the managed service path

Spend based CUDs commit to an hourly dollar amount of consumption on a specific service. They cover Cloud SQL, Cloud Run, Cloud Spanner, Bigtable, App Engine, Cloud Functions, and BigQuery slot commitments. The discount ceiling is lower than resource based (typically 20 to 28 percent for three year commits) but the commit is more forgiving because it applies across instance configurations within the service. For BigQuery customers, the slot commitment math is particularly important: slots can be purchased as flex (no commit), one month, one year, or three year, with progressively deeper discounts. Three year BigQuery slot commitments at scale frequently land at 40 percent below on demand BigQuery pricing.

Flexible CUDs: the sweet spot for most estates

Flexible CUDs (introduced by Google as the modern replacement for the older spend based Compute Engine CUD) commit to a dollar hourly Compute Engine spend that applies automatically across machine families and regions. The three year discount is approximately 46 percent off on demand. Flexible CUDs sit between resource based (rigid, deeper discount) and spend based (very flexible, lower discount), and for most enterprise customers running a mix of Compute Engine machine families this is the right default. The buyer side rule is: use resource based CUDs to cover the predictable steady state baseline at the deepest discount, layer flexible CUDs against the variable but committed compute spend, and leave on demand for the burst layer.

Commitment sizing and the shortfall trap

CUD commitments are billed regardless of actual usage. If the customer commits to a three year resource based CUD covering 100 n2 standard vCPUs and only uses 70, they pay for the full 100.

The buyer side rule is to size the resource based commit at the conservative baseline (typically the p20 or p30 of trailing twelve months consumption), with the flexible CUD layer covering the next ten to twenty percent of utilization, and on demand handling the variable layer above that.

• Average consumption sizing. Customers who size CUDs at average consumption (instead of p20 baseline) regularly hit fifteen to twenty five percent commit forfeit by year three as workloads shift machine families.
• Optimistic projection sizing. Customers who size CUDs at the optimistic projection forfeit thirty percent or more.

The four named CUD exposure traps

1. The commit shortfall. Committing above the realized utilization baseline results in paid but unused capacity. The deepest CUD discount is meaningless if the customer is paying for thirty percent unused commit.
2. The machine family migration trap. Resource based CUDs lock the customer into a specific machine family. When Google releases a new generation (c3, c3d, n4) that is materially better, the old CUD prevents migration without forfeit.
3. The region lock trap. Resource based CUDs are region specific. Multi region disaster recovery and active active deployments require multiple CUDs, or flexible CUDs at the lower discount.
4. The renewal escalation. Google reads the customer's three year consumption telemetry and proposes the next CUD commit at the actual utilization, often above the original commit, with a smaller relative discount band because the customer is now baseline locked.

The eleven move buyer side CUD playbook

1. Build the consumption baseline. Twelve months of Compute Engine telemetry by machine family, region, and workload classification.
2. Identify the p20 conservative baseline. The compute capacity used at the twentieth percentile of trailing twelve months. This is the resource based CUD target.
3. Identify the p70 variable baseline. The capacity used at the seventieth percentile. The gap between p20 and p70 is the flexible CUD target.
4. Layer resource based CUDs against the p20. Maximum discount, locked to specific machine family and region.
5. Layer flexible CUDs against the p20 to p70 band. Better discount than spend based, more flexibility than resource based.
6. Run spend based CUDs only on managed services. Cloud SQL, Cloud Run, Cloud Spanner, BigQuery slots where no resource based option exists.
7. Negotiate the BigQuery slot commitment separately. Three year slot commitments at scale frequently land 40 percent below on demand. Push for the deepest discount on this specific line.
8. Stack CUDs on the PPA flat discount. CUDs and the PPA flat discount apply on top of each other on covered services. Negotiate both layers, not just one.
9. Build the CUD ramp. Stagger CUD commitments across quarters so they do not all renew simultaneously. Avoids forced renewal on a single negotiation cycle.
10. Run the multi cloud frame. AWS Savings Plans and Reservations, Azure Reservations and Savings Plans as documented alternatives. Even credible threat changes Google's renewal posture.
11. Plug into Vendor Shield. CUDs do not stand alone. They interact with the PPA, with BigQuery slot pricing, with Vertex AI dedicated capacity, and with Google Workspace commitments. Read the related Vendor Shield, the GCP PPA negotiation, and the GCP negotiation leverage framework.

How we engage on Google Cloud CUDs

• CUD scoping. Six week buyer side review of twelve months of Compute Engine telemetry, machine family mix, region coverage, and the current CUD portfolio if any. Outputs the resource based / flexible / spend based commit recommendation with dollar values.
• CUD negotiation. Twelve week engagement covering the resource based commit sizing, flexible CUD layer, BigQuery slot commitment, PPA stacking, and the renewal mechanics.
• FinOps integration. CUDs are a FinOps lever, not just a commercial lever. We work with the customer's FinOps team to model the CUD impact against rightsizing and machine family migration plans.
• Vendor Shield. Always on multi vendor engagement covering GCP CUDs alongside AWS Reservations / Savings Plans and Azure Reservations / Savings Plans.
• Run the assessment. The benchmarking practice compares CUD coverage and discount realization against comparable customers.