Most public cloud negotiations stop at the commitment discount. The larger lever usually sits on top of it, and few teams ever model it separately.

For most enterprises, the hyperscale cloud bill is the least predictable line in the budget. Spend is spread across hundreds of services, billing is accurate but genuinely difficult to read, and the team negotiating the next agreement is rarely the team with full visibility into what is actually driving the number.

The measurement problem comes before the negotiation problem

Engineering teams often have limited visibility into what drives spend, and it is common for workloads that should sit on a discounted commitment structure to still be running at full, on-demand price simply because nobody reconciled what was contracted against what is actually deployed. Unplanned cost also shows up in places a negotiation rarely reaches on its own — egress, data-platform queries, logging. None of that gets fixed by negotiating harder. It gets fixed by knowing what is actually being consumed before the negotiation starts.

The stacking mistake

A private, negotiated pricing agreement stacks on top of the standard commitment discount — it does not replace it. When a new deal is benchmarked against on-demand list pricing, the “savings” being shown already include optimization the team achieved on its own; the vendor ends up taking credit for a number that was already earned. Separately, and often missed, a custom discount negotiated across services based on total spend is frequently available on top of the standard commitment discount, and can be larger than the commitment discount by itself.

Multi-cloud is a lever, even without a multi-cloud strategy

If workloads run across more than one provider, that alone creates leverage a single-provider negotiation cannot produce. Terms benchmarked across providers create a competitive dynamic that a renewal conversation with one vendor, on its own, never has to respond to.

The levers most buyers never touch

  • Marketplace spend inclusion
  • Enterprise support fee tiers
  • AI and inference workloads brought inside the agreement instead of priced separately
  • Egress and data-platform terms
  • A ramp structure that does not quietly build in a growth floor the team ends up funding regardless of actual usage

Three questions worth asking before the next renewal or true-up:

  • Is the next deal being modeled against on-demand pricing, or against the post-optimization rate already achieved?
  • Does the current agreement capture AI and inference spend, or is that growing in a separate, unnegotiated line?
  • If workloads run on more than one provider, has that ever been used as leverage in the same negotiation?

This is the same approach behind how we work cloud renewals: start with the billing data, establish the post-optimization rate as the real baseline, and negotiate the levers most teams never model separately.