Google Cloud committed use discounts (CUDs) let you trade flexibility for a lower price: commit to a minimum level of usage or spend for 1 or 3 years, and Google applies a significant discount to that usage. This post explains how the two CUD types work, which GCP services support each, how BigQuery CUDs specifically work, and how to calculate the right commitment level.

What is a Google Cloud committed use discount?

A committed use discount is a contractual agreement to pay for a minimum level of GCP resource usage or spend for 1 or 3 years. In exchange, Google applies a discount to that usage for the duration of the commitment.

Google offers CUDs because predictable revenue allows them to plan infrastructure capacity more efficiently. The discount is Google’s way of passing part of that planning benefit to customers who are willing to reduce uncertainty on their end. The trade-off is asymmetric: you commit to the minimum level regardless of actual usage — if you consume less than you committed, you still pay for the committed amount.

Two types of commitments exist in GCP: resource-based and spend-based. They differ in what you commit to, how flexible they are, and how large the discount is.

What is the difference between resource-based and spend-based CUDs?

Resource-based commitments apply to specific Compute Engine configurations: a fixed combination of machine type (or vCPU/memory), series, and region. You are committing to run a specific kind of machine in a specific location.

Spend-based commitments apply to a minimum dollar amount of hourly spend on eligible GCP services. You commit to a spend level, not to a specific resource configuration, which makes them more portable across machine types and services.

The trade-off:

For Compute Engine, both types are available. If you apply both, Google applies resource-based first, then spend-based covers remaining usage.

The practical rule: if you are confident your workload will stay on the same machine type and region for the full term, resource-based gives the larger discount. If you expect machine type or region changes (or need to cover multiple services), spend-based is more appropriate. Both can be combined: cover your stable, predictable core with resource-based commitments and use spend-based to cover the rest.

Which GCP services support committed use discounts?

Only Compute Engine supports both types. The following services support spend-based CUDs only:

• BigQuery
• AlloyDB for PostgreSQL
• Cloud Bigtable
• Cloud Run
• Cloud Spanner
• Cloud SQL
• Google Cloud VMware Engine
• Google Kubernetes Engine (GKE)
• Memorystore

For all services outside Compute Engine, you are working with spend-based CUDs only: no resource locking, just a minimum hourly spend commitment in exchange for a discount.

Do committed use discounts apply to BigQuery?

Yes; BigQuery supports spend-based CUDs only. Here is how they work:

• You commit to a minimum dollar amount of BigQuery pay-as-you-go spend per hour
• The commitment applies to all PAYG slot usage under the billing account in the committed region, including autoscale slots
• Discount rates: 10% off for a 1-year term, 20% off for a 3-year term
• CUDs do not apply to capacity-based reservation charges (baseline slots purchased via commitments); they only affect PAYG usage

For BigQuery teams, this means CUDs are most valuable if you run a significant volume of on-demand queries or have reservations with active autoscaling. If most of your BigQuery spend is already on committed baseline slots, the CUD will apply to a smaller portion of your bill.

Related reading:
What Does a BigQuery Job Actually Cost on a Reservation?

BigQuery CUDs vs capacity commitments: these are two separate cost levers. Capacity commitments (buying baseline slots for reservations) typically offer larger savings on compute; CUDs are an additional discount layer on top of any remaining PAYG usage. They are complementary, not alternatives.

Related reading:
BigQuery Pricing Models Explained: On-Demand vs Capacity-Based

Learn all about BigQuery Editions and Reservations. Download our white paper:

How much do GCP committed use discounts save?

Discount levels vary by type, service, and term:

Commitments are available for 1 or 3 years. The 3-year term always offers a larger discount, but it also locks you in for longer, so the right choice depends on your confidence in usage stability over that window.

How do you calculate the right CUD amount?

There are two strategies, and most teams combine them.

Strategy 1: maximize savings

Commit to a level above your consistent minimum but below your peak. During low-usage periods (nights, weekends) you will over-commit and pay for unused capacity. During high-usage periods, those hours more than offset the low-usage waste: the net savings across the full period are higher than the minimum-usage strategy.

Strategy 2: cover minimum stable usage

Commit only to what is always on — the floor of your usage across all periods. There is no over-commitment risk. This approach is conservative and appropriate when usage is unpredictable or when you are making your first commitment and want to validate the pattern before going larger.

Combining the two strategies

For Compute Engine workloads, a practical combination is:

• Use resource-based commitments at the minimum stable usage level for your most stable machine configurations
• Layer spend-based commitments on top using the maximize savings approach to cover the variable portion

This gives you the deeper resource-based discount on the predictable core and spend-based portability on the rest.

How do you handle existing commitments?

Three options when a commitment already exists:

1. Wait for expiry, then commit fresh. Calculate a new commitment once the existing one expires. Best when the expiry date is close and your usage pattern may have changed.

2. Add a new commitment on top. Make an additional commitment alongside the existing one. A useful approach is to make small monthly or quarterly commitments. This lets you revisit the commitment level regularly and adjust as usage evolves, rather than locking in a large multi-year amount in one go.

3. Merge the existing commitment into a new one. Google allows merging a commitment into a larger or longer-term one (you cannot reduce). A new commitment is created, and the old one merges into it. The end date becomes the later of the two. Note: merging cannot be reversed: the new term and amount are binding. See Google’s documentation on merging commitments.

What to check before committing: machine type and family

Before making a Compute Engine commitment, verify that your target machine configuration is stable and correctly sized:

Run on the target CPU first. If you are considering switching machine families (for example, moving from Intel to AMD), run the workload on the target CPU type before committing. CPU families differ in concurrency behavior and per-core performance characteristics, and you want to validate the usage pattern before locking in.

Check machine family pricing. AMD machine families can be priced up to 12% lower than Intel equivalents before discounts. If your workloads are CPU-tolerant, validating on AMD first and then committing to AMD series instances can compound the savings with the CUD on top. See AMD vs Intel machine types on GCP for a detailed comparison.

How does Rabbit help with BigQuery commitments?

For BigQuery teams, the larger savings lever is typically capacity commitments (baseline slots + capacity commitment terms), not spend-based CUDs. Rabbit’s Reservation Planner helps size BigQuery slot commitments by simulating different baseline, commitment term, and autoscale configurations against your historical usage to find the setup that minimizes your effective slot-hour cost. If you already have a reservation with autoscaling, see How to Cut BigQuery Autoscaling Costs When You Have a Commitment for how to reduce waste on top of your committed baseline.

For teams running significant on-demand BigQuery workloads, the BigQuery Savings Calculator can help estimate potential savings from both commitment strategies before you configure anything.