In cloud and FinOps conversations, discussions around commitments and discounts have long implied a single, well-understood concept – one we still refer to as a commitment discount.

That assumption no longer holds.

While a Reserved Instance, a Savings Plan and a negotiated discount all involve committing to future usage or spend in exchange for discounted pricing, they do not behave the same way operationally, commercially or analytically. Confusion arises when discount-bearing commitments are assumed to have a shared meaning – especially as discussions extend beyond the cloud, or even just beyond the three major CSPs: AWS, Microsoft Azure and GCP.

What matters is not just that a discount-bearing commitment exists.
What matters is that everyone is aligned on what they are actually discussing and working with.

What “commitment” often refers to in discount discussions

For many teams – particularly those working with AWS, Microsoft Azure or GCP – commitment in the context of discounts immediately points to familiar constructs: Reserved Instances, Savings Plans and Committed Use Discounts, collectively referred to as commitment discounts, which provide discounted pricing on a predefined set of SKUs.

They share a set of defining characteristics:

• terms are publicly disclosed and standardised
• there is no negotiation at the individual customer level
• the commitment is tied to specific spend or usage goals over a defined period
• committed spend or usage is evenly distributed across predefined fulfillment intervals, typically hourly
• unused benefits cannot be carried over to subsequent intervals
• only one commitment discount can be applied to a single charge at a time

This version of discount-bearing commitments has dominated FinOps discussions for years. However, it is not the only one.

Where the familiar model stops being enough

The characteristics above make commitment discounts well-understood and well-defined. When the scope is limited to commitment discounts, there is a solid foundation to build on because the rules are known in advance and the behaviour is standardised – whether in tooling, reporting or analysis.

Negotiated discounts do not follow the same pattern.

Their terms are privately agreed, their conditions are customised and their behaviour can vary significantly from one agreement to the next. What needs to be supported is not known in advance – and that is the challenge.

What negotiated discounts introduce

With commitment discounts, the terms are well-known and standardised. Negotiated discounts are not.

With negotiated discounts, a number of terms is agreed per contract. To name a few:

• the committed amount may not be evenly distributed across fulfilment intervals
• the fulfillment interval is not necessarily fixed – unlike the typically hourly interval of commitment discounts, it can span the full commitment term or vary over the life of the contract
• unused benefits may be carried forward to subsequent intervals rather than expiring
• multiple negotiated discounts may apply to a single charge at a time, and may overlap with a commitment discount

All of these terms can differ from one negotiated discount to the next, which makes it difficult to assume a single model of behaviour.

What starts to break when terms are variable

When the terms of a discount-bearing commitment are variable, the implications span:

• coverage and waste calculations
• savings calculations
• forecasting models
• cost allocation logic
• showback and chargeback outputs

As a result, accounting for negotiated discounts becomes a fundamentally different and more complex exercise.

Beyond commitment discounts

The real issue is not whether a commitment exists.

It is whether everyone involved understands what kind of discount-bearing commitment they are working with, how its terms behave in practice and what assumptions are built into the analysis.

Alignment in the conversation is the starting point. Once negotiated discounts enter the picture, complexity increases, and each new contract can effectively introduce a new business requirement. You cannot support everything from day one, but the broader the awareness early on, the easier it becomes to evolve over time – from abstraction in modelling, to building capabilities that can scale as new requirements emerge.