What Is Resource Based Commitment?

If you are asking what is resource based commitment, the short answer is a deal where you pledge to a set quantity of compute, such as a number of vCPUs and an amount of memory, over a fixed term and receive a discount on those resources. Unlike a spend based commitment, which fixes a dollar total, a resource based commitment fixes the hardware. It is the structure behind Google resource based committed use discounts, and it tends to reward steady, predictable workloads with a deeper rate than a flexible spend pledge.

What is resource based commitment in cloud deals?

A resource based commitment pledges a quantity of compute rather than a sum of money. You agree to run, for example, a baseline of vCPU and memory for the term, and the provider discounts that baseline. The commitment is anchored to capacity, not to spend.

As of June 2026 Google Cloud resource based committed use discounts run for one or three years and apply to vCPU and memory, with flexibility across instance types within a family. The buyer commits to the resource floor and draws the discount on usage up to that floor.

Resource based versus spend based

The trade off is flexibility against depth. A spend based commitment lets your architecture shift freely as long as the dollars flow, which suits a changing estate. A resource based commitment locks you to a capacity profile, which suits a stable one and often returns a deeper discount in exchange.

Buyers with steady, always on baselines tend to favour resource based commitments for the core, then layer flexibility on top. Buyers with volatile or fast changing workloads often prefer the spend based structure so they are not stranded holding capacity they have moved away from.

How resource based commitments stack

As of June 2026 Google also offers automatic sustained use discounts that need no commitment, plus custom private pricing for large enterprises. A critical detail for buyers is that committed use discounts and sustained use discounts do not double stack on the same resource. You get one or the other on a given unit, not both.

That non stacking rule means a resource based commitment should be sized to the baseline you would run anyway, where the committed rate beats the automatic sustained rate. Commit above that baseline and you risk paying for capacity that idles, since the discount does not rescue resources you do not use.

How to size a resource based commitment

Size it to your floor, not your peak. The safe quantity to commit is the capacity that runs continuously regardless of demand swings, because that is the portion certain to draw the discount every hour of the term. Everything above that floor is better left to flexible or on demand pricing.

Watch the term length too. A one year resource based commitment carries less lock in risk than a three year one, at a shallower discount. The right choice depends on how confident you are that the workload, and the instance family it runs on, will still look the same when the term ends.

Deciding between resource based and spend based structures? Book a confidential cloud commitment negotiation review before you commit.

Condense the commitment before you sign.

A CONFIDENTIAL COMMITMENT REVIEW · INDEPENDENT · BUYER SIDE · PAID ONLY BY YOU