Resource Based vs Spend Based CUDs Explained

Resource based vs spend based CUDs explained, from the buyer side, is a question of where you want your flexibility and where you can accept lock in. Both are Google Cloud committed use discounts that trade a lower rate for a one or three year commitment, as of June 2026. Resource based CUDs commit to compute capacity. Spend based CUDs commit to an hourly dollar amount of spend. The right choice depends on how predictable your usage is and how much you expect it to change.

Resource based vs spend based CUDs explained side by side

A resource based CUD commits you to a quantity of compute resources, typically vCPU and memory, within a region. In return you get a discounted rate on that committed capacity for the term. The flexibility is that the commitment applies across instance types within the relevant family, so you can change machine shapes without losing the discount, as long as you stay within the committed resources.

A spend based CUD commits you to a steady hourly dollar amount of spend on eligible services. Instead of locking to a quantity of vCPU and memory, you lock to a spend floor, and the discount applies to eligible usage up to that floor. This is broader, because it is not tied to a specific resource family, and it suits workloads where the services vary but the underlying spend stays steady.

The simplest way to hold the difference in mind is this. Resource based CUDs lock capacity and flex the machine type. Spend based CUDs lock spend and flex the services. Both reduce the rate. They differ in what they constrain and therefore in what risk they carry when your usage shifts.

Where each one fits

Resource based CUDs fit stable, compute heavy workloads in a known region where you can predict the floor of vCPU and memory you will always run. If you operate a steady fleet of virtual machines and you mainly change instance sizes over time, the resource based commitment rewards that stability while letting you re shape the machines underneath it.

Spend based CUDs fit broader or evolving estates where the mix of services changes but the total spend floor is reliable. If you cannot predict exactly which instance families you will run, but you are confident you will always spend at least a certain hourly amount on eligible services, the spend based commitment protects the discount without pinning you to a resource shape you might outgrow.

Many enterprises use both. A resource based CUD covers the predictable core fleet, and a spend based CUD covers the steady but less predictable remainder. The layering lets you commit confidently to the parts of the estate you understand and keep the rest flexible on demand, sustained use discounts, or spot capacity.

Flexibility and risk tradeoffs

The resource based risk is shape drift. If your workloads migrate to a family the commitment does not cover, or to a different region, the committed capacity can strand and you pay for it while also paying for the new usage. The spend based risk is the opposite. It is broad, but it commits real dollars, so if your overall spend falls below the floor you still owe the committed amount.

Neither type rolls unused commitment forward, and neither double stacks with sustained use discounts on the same resource, as of June 2026. So in both cases the discipline is the same. Commit to the floor you are confident you will sustain for the whole term, and let the variable layer above it stay flexible. We cover the sizing method in sizing GCP CUDs to avoid overcommitment.

Term length sharpens every tradeoff. A three year commitment deepens the discount but multiplies the cost of getting the shape or the floor wrong. Where your architecture may change, a one year term or a smaller commitment can be worth more than the deeper rate. See our guide to CUD term length for the full comparison.

How to decide as a buyer

Pull your usage history and find two numbers. The first is the floor of compute capacity, in vCPU and memory by region and family, that you run continuously. The second is the floor of total eligible spend that you sustain regardless of which services you use. Resource based CUDs match the first number. Spend based CUDs match the second.

Commit resource based where the capacity floor is stable and predictable, and spend based where the spend floor is reliable but the service mix is not. Layer them so the predictable core is covered by the more specific commitment and the steady remainder by the broader one. Keep everything above both floors flexible, because that is where overcommitment hides.

At scale, fold this into a wider negotiation. The standard CUD rates are a default, and large buyers can pursue custom private pricing that blends committed and flexible spend on better terms. A buyer side review models the resource based and spend based mix against your real data before you lock any of it in.

A decision framework you can apply today

Turn the choice into two questions about your usage history. First, is there a stable floor of compute capacity, in vCPU and memory by region, that you run continuously and expect to keep running? If yes, a resource based CUD captures that floor efficiently while letting you re shape the machines underneath it.

Second, is there a reliable floor of total eligible spend that holds even when the specific services change? If yes, a spend based CUD protects that floor without pinning you to a resource family you might outgrow. Many estates answer yes to both, which is why layering a resource based commitment on the predictable core and a spend based commitment on the steady remainder is so common.

Whatever the mix, size each commitment to the floor rather than the average, keep the variable layer flexible, and revisit the structure as your architecture evolves. The wrong type is rarely fatal on a one year term. On a three year term, the wrong type or an oversized floor compounds, so the modeling matters most exactly when the commitment is longest.

Sources, method, and as of date

The program mechanics and ranges on this page reflect publicly available provider documentation and our buyer side negotiation experience, as of June 2026. AWS, Microsoft, and Google revise their programs frequently, so treat every figure as a point in time reference and confirm the current terms directly with the provider before you act.

This page is commercial negotiation advisory, not legal, tax, or accounting advice. We are independent and buyer side, with no reseller margin and no hyperscaler incentive, and we are paid only by the buyer. For interpretation of any commitment contract or program term, engage your own legal counsel.

Choose the right CUD structure before you commit.

A CONFIDENTIAL COMMITMENT REVIEW BEFORE YOU SIGN