GCP committed use discounts, resource based or flexible. Why the deepest rate strands first.

A resource based commitment locks the machine shape as well as the rate, so the deepest discount becomes the most expensive line once a workload migrates. Commit the stable base deep, float the middle on flexible CUDs, and leave peaks on demand.

What is the difference between resource based and flexible committed use discounts?

A resource based commitment buys a fixed amount of vCPU and memory for one machine series in one region, at the deepest rate Google offers. A Compute flexible commitment buys a dollar amount of hourly spend that applies to eligible usage in any region and any project paid by the same Cloud Billing account, at a shallower rate.

The first locks the machine shape as well as the price. The second locks only the price. Workloads change shape far more often than they stop running, so that difference decides which commitment ends up cheaper.

Where the savings plan comparison fits

Buyers who come from AWS usually ask which Google instrument matches a Savings Plan. Our AWS Savings Plans and reserved instances comparison covers the AWS side of the same trade.

• Compute flexible CUD. The closer match to an AWS Compute Savings Plan, because it is a spend commitment that follows the workload across families and regions.
• Resource based CUD. Closer to an EC2 Instance Savings Plan or a standard reserved instance, tied to one family in one region.

Flexible commitments also cover eligible Google Kubernetes Engine and Cloud Run usage, which suits teams shifting work from VMs to containers. Check the eligible SKU list before you size one. Some GKE compute classes and GPU Pods sit outside it, and Cloud Run request based billing earns 17 percent on either term.

Why does the realized discount sit below the 55 percent headline?

Because the headline assumes you use every committed vCPU and gigabyte for every hour of the term. A three year resource based commitment lists at up to 55 percent off. In the reviews we ran, it landed at 38 to 50 percent once the idle part of the commitment was subtracted.

That realized band is still a strong result, and it is a different number from the one on the proposal. Compare options on the realized figure. On that basis, a flexible commitment at 46 percent that stays attached to running workloads often beats a deeper one that spent part of its term covering nothing.

How the double pay happens

Each step in the sequence is a reasonable decision on its own day.

1. An engineering team migrates a workload to a newer machine family, or to another region, and gets better performance for less compute.
2. The resource based commitment underneath the old workload keeps billing, because it was a commitment to a shape.
3. The replacement workload runs uncovered at on demand rates.
4. Google does not refund the unused commitment, so both lines bill together for the rest of the term.

The refresh that improved performance stranded a discount the company had already paid for. The engineers who ran the migration rarely know the commitment exists, because a different function signed it two years earlier.

What Google's terms say about unused commitments

You can't cancel a commitment after you buy it, and Google bills the monthly commitment fee whether or not you use the resources. The only change to the term Google offers is an upgrade from a 1 year to a 3 year plan.

You can merge and split resource commitments, but each one stays tied to the series and region it was bought for.

How much does a stranded commitment cost in practice?

In the hypothetical below, one migration in month 13 turns the deeper commitment into the more expensive option by about $399,000 over three years. It uses Google's list discounts, so you can rerun it with your own figures.

Say your Compute Engine usage is worth $100,000 per month at on demand prices. Of that, $60,000 is an always on base that will keep its machine series for three years. Another $25,000 is a steady middle that engineering expects to shift between families. The last $15,000 is spiky peak usage.

Option A: maximum coverage on one model

You commit the base and the middle, $85,000 of on demand value, to a three year resource based CUD at 55 percent off. That costs $38,250 per month, plus $15,000 of peak on demand.

In month 13, $20,000 of the middle migrates to a newer machine family, and the commitment keeps billing in full. The migrated workload runs at the full on demand price, because newer series such as C3, C4 and N4 earn no sustained use discount.

Option B: layered coverage

You commit only the $60,000 base resource based at 55 percent off, which costs $27,000 per month. The $25,000 middle goes on a three year flexible CUD at 46 percent off, which costs $13,500 per month and follows the workload when it migrates. The peak stays on demand at $15,000.

What the example shows

Option A is $2,250 a month cheaper in year one, which is the year the proposal slide shows. After the migration, 23.5 percent of its commitment is idle, inside the 18 to 26 percent range we measured in real reviews. Over the term, Option B runs 11.1 points cheaper net.

The resource commitment in Option A still realized 46.6 percent on the usage it covered. That is a respectable number, and it hides the $480,000 of on demand spend the migration added over 24 months. Judge a commitment on the total bill for the workloads it was meant to cover.

How should you split usage between resource based, flexible and on demand?

Split it into three layers by stability, and give each layer the instrument that fits it.

• Base load. Cover the always on floor with resource based commitments. The deepest rate belongs only on hours you are confident will exist in the same shape at the end of the term.
• Swing load. Cover the predictable but shifting middle with flexible commitments that float across families and regions.
• Peak load. Leave the spiky top on demand. Flexibility is worth the premium there, and a commitment would sit idle. Older series such as N1, N2 and N2D still earn sustained use discounts of up to 30 percent on instances that run most of the month.
• Review the boundaries. Track commitment usage every month, because the lines between the layers shift as your workloads change. Our FinOps playbook for Google Cloud CUDs sets out the monthly review.

Size the base from the billing export

Size each layer from measured consumption in the Cloud Billing export, not from a coverage target the account team supplies. Take twelve months of hourly usage by machine family and region, and find the level you exceeded in 80 percent of hours. That is the p20 sizing rule, and it is where the resource based commitment goes.

Match the term to how long the shape will last

A three year term is only cheap if the workload still runs that machine series in year three. Many companies refresh hardware every two years, and Google keeps releasing faster series. Where a refresh is likely inside the term, a one year resource commitment at up to 37 percent, or the flexible rate, usually costs less on net.

Why we do not aim for maximum coverage

The usual advice, repeated by the account team, is to cover as much usage as possible at the deepest rate. We disagree, because coverage is a measure the vendor optimizes and the buyer funds. The deepest rate carries the most specific lock, which changing workloads cannot honor for three years. Track the net effective rate after stranded commitments instead.

The realized rate after stranding is the only discount worth comparing between commitment options.

What have we seen in recent Google Cloud commitment reviews?

Across roughly 25 to 35 Google Cloud commitment reviews in 2024 and 2025, the deepest rate on offer was routinely the most expensive choice once the term played out.

Behind those numbers were three habits: treating coverage as the goal, comparing headline rates instead of realized ones, and committing three year shapes in teams that refresh hardware every two years.

How do you check what your current commitments are doing?

Start in the Google Cloud console and the billing data you already export. These sources tell you most of what you need before you buy anything new.

• Compute Engine commitments list. Shows each commitment with its type, region, resources, start and end dates, and whether automatic renewal is switched on.
• CUD analysis report in Cloud Billing. Shows coverage, savings and how much of each commitment was used, with a separate view for Compute flexible CUDs.
• Cloud Billing export to BigQuery. Gives hourly usage by SKU, machine family, region and project, which is the raw input for the p20 floor.
• Discount sharing setting. Shows whether resource based discounts are shared across projects on the billing account or stay in the project that bought them.

If a commitment shows idle capacity, find the workload that left it before you buy more. It is usually running on demand elsewhere on the same billing account. Then ask engineering for the migrations and region changes planned inside the term, which no console shows.

What will the Google account team say, and how should you answer?

Expect the conversation to center on coverage and the three year rate. These lines come up most often.

Common lines and replies

• "Three year resource based gives you 55 percent, the best rate we have." Reply that the rate assumes full use for the whole term, and ask for the realized rate on your past commitments before you compare it with 46 percent flexible.
• "Your coverage is below similar customers." Reply that you manage to the net effective rate after idle commitment, and that you size from your own billing export.
• "The commitment recommendations say you should commit more." Reply that the recommendations read recent usage history. They cannot see the machine series migration on your roadmap.
• "Buy before quarter end to secure the rate." CUD list rates are available in the console on any day. Quarter end pressure only matters for negotiated terms, and our note on quarter end and year end timing covers when that pressure helps you.

Inside a negotiated agreement, a credible alternative, such as a competing cloud quote for the workloads you could move, is the one thing that improves your discount without adding volume. It exists only before you sign. Our video briefing Google Cloud: Is There Leverage? Five Tactics walks through how to build one.

Which contract terms matter when commitments sit inside a larger Google deal?

A console purchase uses Google's published terms, so there is little to negotiate. When commitments sit inside a larger spend agreement, ask for these in writing.

1. A refresh conversion right. Ask for the right to convert a resource commitment into a newer machine series in the same region for the remaining term value. It removes the double pay at the point it usually happens.
2. Region substitution. Reassign commitments when a residency or disaster recovery decision takes a workload to another region.
3. Treatment against the overall commit. Confirm whether CUD fees count toward your total spend commitment. If they do not, you are funding two commitments at once.
4. Renewal notice. Get written notice before any commitment renews automatically.

Our guide to commit swap and substitution rights covers the wording in detail. The wider negotiation sequence sits in the Google Cloud enterprise negotiation playbook.

What to do next

1. Measure what you hold. Pull commitment usage from the billing export and see how much of each existing commitment is attached to running workloads.
2. Split the usage. Separate it into base, swing and peak from that data, with the refresh roadmap beside it.
3. Commit the base resource based. Choose a term the machine shape will plausibly survive, and size it to the p20 floor.
4. Float the middle. Cover the swing layer with flexible commitments and leave the peak on demand on purpose.
5. Compare on realized rate. Rank every option on its net effective rate after stranding, and check the automatic renewal flag on anything due to expire.
6. Get help with the ladder. Our Google negotiation service builds the layers with you, and the Google Cloud practice holds the wider library, including the complete guide to GCP committed use discounts.

Frequently asked questions