Google Cloud CUD Negotiation: Resource-Based vs Spend-Based Discounts

How Google Cloud CUDs Work

A committed use discount is a one- or three-year spending or resource commitment made in exchange for a reduced rate compared to on-demand pricing. Unlike AWS Reserved Instances, which are purchased as discrete reservations against specific instance types, Google Cloud CUDs are applied automatically against any eligible usage in the billing account, without needing to manage reservation inventory manually.

The distinction that matters most in practice is the type of commitment: resource-based or spend-based. Each has a different discount ceiling, a different definition of what counts as "used," and a different risk profile if your cloud footprint changes during the commitment term.

Understanding this distinction before you commit is not optional. Google does not allow you to cancel a CUD once purchased. You pay for the committed amount whether or not your actual usage reaches it — which means an over-commitment in a resource-based CUD covering a specific machine type in a specific region can produce waste that persists for three years.

Resource-Based CUDs: Maximum Discount, Maximum Commitment

A resource-based committed use discount — sometimes called an RCUD — commits you to a specific quantum of compute resources: vCPUs, memory, local SSDs, GPUs, or TPUs within a particular Google Cloud region. In return, Google applies discounts of up to 37% for a one-year term and up to 55% for a three-year term on those committed resources, with higher rates available for memory-optimised machine types (up to 70% off).

The resource-based approach delivers the highest possible discount because you are making the most specific commitment. Google knows exactly which resources you have pre-purchased and can optimise its infrastructure planning accordingly. That specificity is also the constraint: if you commit to 100 N2 vCPUs in us-central1 and then migrate workloads to N2D machine types in europe-west1, your RCUD provides no coverage for the new footprint while you continue paying for the old commitment.

When resource-based CUDs are the right choice

RCUDs work best when your compute footprint is stable, predictable, and unlikely to migrate across regions or machine families during the commitment term. Specifically, consider RCUDs when your steady-state usage of a particular machine type has been consistent for at least six months with less than 15% variance; when you have no planned infrastructure migrations, re-platforming projects, or significant workload re-architectures during the term; and when you need the maximum discount to hit a specific cost reduction target.

Enterprises running long-lived VM fleets for internal systems, batch processing pipelines, or database workloads with predictable sizes are strong candidates. Where you see volatility is typically in growth workloads — new products, experimental environments, or autoscaling clusters that respond to demand spikes.

Commitment sizing for resource-based CUDs

Sizing methodology matters. The standard approach is to commit only to your confirmed baseline — the level of usage you have sustained for the preceding three to six months with reasonable confidence it will persist. Do not include projected growth in your RCUD baseline. Instead, cover baseline usage with RCUDs and layer spend-based CUDs (described next) on top to capture savings on the variable portion.

Spend-Based CUDs: Flexibility at a Lower Discount

A spend-based committed use discount — sometimes called an FCUD or Flex CUD — commits you to a minimum hourly spend level across a broader range of services rather than a specific resource configuration. In return, Google offers discounts of 28% for a one-year term and 46% for a three-year term.

The lower discount rate reflects the additional flexibility: spend-based CUDs apply across any eligible service or machine type, are not region-locked in the same way as RCUDs, and cover usage even if your resource mix shifts substantially during the term. If you migrate from N2 to N2D, move workloads across regions, or add new services covered by the CUD program, your commitment continues to generate savings.

When spend-based CUDs are the right choice

Spend-based CUDs are more appropriate when your total cloud spend level is predictable but your resource mix is likely to change. They suit organisations undergoing migration or re-architecture projects where the destination state is not yet confirmed; teams planning to adopt new machine generations as Google releases them; and environments where workloads spread across multiple regions and locking to a single region would require managing multiple RCUDs simultaneously.

They are also useful as a supplement to RCUDs — you commit your confirmed baseline to resource-based discounts to get the maximum rate, and cover the remaining predictable spend with a spend-based CUD to capture savings on variable or migrating workloads without assuming resource-level precision you do not have.

The Laddering Strategy: Combining Both CUD Types

The approach that extracts maximum value while managing commitment risk is to layer the two CUD types based on your confidence level about different parts of your footprint. Google's documentation confirms that spend-based CUDs apply after resource-based CUDs in the discount hierarchy — meaning Google applies the cheaper discount first, leaving more of your spend covered by the higher-value resource-based commitment.

A practical laddering framework

Start by analysing your Cloud Billing data for the prior 90 days across all projects. Identify the sustained compute baseline — the minimum usage level you have maintained without interruption. This becomes your RCUD foundation. Size it at 80–90% of that baseline rather than 100%, preserving a small buffer for measurement variance and minor reductions in the event of optimisation work.

Next, identify your predictable spend envelope beyond the RCUD baseline — the portion of your bill that is consistently present but not tied to specific resources (perhaps because it spans multiple regions, or because you are planning to migrate machine types within 12 months). Cover this with a spend-based CUD at the appropriate term length.

Finally, leave your genuinely variable or experimental workloads on-demand or covered by sustained use discounts (SUDs), which Google applies automatically for workloads running more than 25% of a calendar month without any commitment required. SUDs are less powerful — approximately 20–30% — but require no commitment and act as a natural safety net.

The Multiprice CUD Transition: What Changed in 2025

In July 2025, Google introduced a significant change to how spend-based CUDs work — one that affects every enterprise with existing or planned spend-based commitments. The new model, called "multiprice CUDs," replaces the legacy system of CUD credits with a direct discount-on-billing approach.

Legacy model versus new model

Under the legacy spend-based CUD model, Google applied CUD savings as credits against your bill, which could obscure the true per-SKU discount rate and made it difficult to attribute savings to specific workloads in billing exports. The new model applies discounts directly at the SKU level, making the saving visible as a reduced unit price on your bill rather than a separate credit.

The transition timeline followed three phases. Customers who created new billing accounts or purchased new spend-based CUDs on or after 15 July 2025 entered the new model automatically. Existing customers gained the option to opt in from 15 July 2025. All remaining customers were automatically migrated to the new model on 21 January 2026.

What the multiprice model changes in practice

The multiprice model is more granular than its predecessor. Rather than applying a single discount rate to a broad spend commitment, Google now breaks down the discount by resource type and SKU. This means a spend-based CUD may apply different effective discount rates to compute versus storage versus networking usage — reflecting the actual pricing structure rather than an averaged credit.

For BigQuery users specifically, this transition also expanded CUD coverage. BigQuery was not previously covered by spend-based CUDs in the same way, but the new model includes 11 additional services, with BigQuery among the most significant additions. M-series memory-optimised VMs and Cloud Run are also newly eligible.

The practical implication for procurement and FinOps teams is that your BigQuery export configuration needs to be updated. The enhanced "Detailed cost data (new schema)" option in Cloud Billing exports is required to access the expanded fields — cloud_product, pricing_unit, resource_type, and commitment_name — that expose multiprice CUD attribution at the granular level.

Moving Beyond Self-Service: Private Pricing Agreements

Self-service CUDs — whether resource-based or spend-based — are purchased directly in the Google Cloud Console without negotiation. The discount rates are fixed and published. For most organisations with annual Google Cloud spend below $5M, this is the primary optimisation lever.

Above certain thresholds, however, private pricing agreements unlock discount levels that self-service CUDs cannot match. Data from ProsperOps' 2025 Google Cloud benchmarking study shows that among companies with $10M or more in annualised compute spend, the median Effective Service Rate (ESR) is 54.3% — compared to just 9.4% for companies spending under $500K annually. A majority of companies at the $10M+ level have private rates that exceed the published 55% three-year RCUD ceiling.

Negotiating private rates with your Google Cloud account team

Private pricing agreements are negotiated directly with your Google Cloud account team and typically take the form of a Cloud Commitment or Enterprise Agreement. These agreements cover multiple services, can include cross-product discounts that do not exist in self-service CUDs, and usually involve a total spend commitment to Google Cloud over a multi-year period rather than a resource-level commitment.

The negotiation dynamic mirrors AWS Enterprise Discount Program negotiations in some respects: Google wants predictability and volume commitment in exchange for preferential rates. The leverage points are your total spend commitment, the term length you are willing to accept, the proportion of your workload you will run on Google Cloud versus competing clouds, and your willingness to adopt Google-specific services (particularly Vertex AI and Google Workspace) as part of the agreement.

A key nuance is that the $10M threshold is not a hard floor for private pricing — it is the inflection point at which private rates become significantly more advantageous than self-service CUDs. Organisations spending $5–10M annually on Google Cloud should still initiate a conversation with their account team about agreement structures, particularly if they anticipate growth that will push them above $10M within the agreement term.

What to include in a private pricing negotiation

When approaching Google for a private pricing agreement, several elements beyond the headline discount rate deserve attention. First, the auto-escalation provision: some Google agreements include a clause that adjusts the committed spend level upward at a set percentage each year, reducing the discount benefit if your actual usage does not keep pace. Insist on flat or usage-based escalation rather than automatic increases.

Second, the scope of covered services: verify that the services most material to your spend — including BigQuery, Cloud Storage egress, and any AI/ML workloads on Vertex AI — are explicitly covered at the negotiated rate. Not every Google Cloud service is automatically included in every agreement structure.

Third, the end-of-discount-term clause: NPI Financial and other advisory firms have flagged that some Google Cloud agreements include provisions that significantly reduce discounts at the end of the term, creating leverage for Google at renewal time. Negotiating away from these clauses, or at minimum understanding their financial impact, is important before signing.

CUD Governance: Managing Commitments at Scale

Once CUDs are in place, the operational challenge is monitoring commitment utilisation and preventing the gradual accumulation of under-utilised commitments as your cloud footprint evolves. A CUD with a low utilisation rate means you are paying for discounted capacity that is not generating cost savings proportional to the commitment.

Utilisation monitoring

Google Cloud Billing exports to BigQuery provide the raw data for CUD utilisation analysis. The key fields are cost_type (which distinguishes commitment costs from usage costs) and the new commitment_name and resource_type fields introduced in the multiprice CUD data model. A well-structured BigQuery dashboard over your billing data should surface commitment utilisation as a primary metric, with alerts when utilisation drops below 80% for any active CUD.

Commitment staggering

Rather than purchasing all your CUD capacity in a single large block, staggered purchasing reduces concentration risk. If you purchase all your three-year RCUDs in January, they all expire simultaneously in January three years later — a point at which you face a cliff-edge decision about renewal with no overlapping commitments to provide coverage continuity. Staggering purchases across quarters or years means you always have some commitments entering and some maturing, which smooths the renewal negotiation dynamic and provides natural checkpoints to reassess your footprint.

The relationship between CUDs and sustained use discounts

Google's sustained use discounts (SUDs) are often overlooked in CUD planning discussions, but they interact with CUDs in ways that affect your optimisation strategy. SUDs apply automatically to VMs that run for more than 25% of a month without any commitment, at rates starting around 20% and reaching approximately 30% for full-month usage. Importantly, CUDs and SUDs do not stack — Google applies whichever discount is higher, not both.

This means that for workloads running at 100% uptime, the incremental benefit of a resource-based CUD over SUD is roughly 25 percentage points for a one-year commitment and 25 percentage points for a three-year commitment (SUD at ~30% versus RCUD at 55%). Quantify this incremental savings value when making the business case for a CUD commitment, rather than citing the gross CUD discount, which overstates the true marginal benefit for always-on workloads already receiving SUD.