Trough-Based Commitment

Reserved commitments trade flexibility for a discount over a fixed term. Over-committing pays for capacity you do not use for the whole period; under-committing pays on-demand rates for a predictable baseline. Both errors are expensive and the second is less visible.

The rule: commit to the trough, not the average. Capacity used at the quietest hour of the quietest day is what you are certain to consume; anything above it is variable and should be priced as variable.

Why it matters

Committing to the average feels reasonable and is a bet that the pattern will not change. It usually leaves a meaningful proportion of the commitment unused during quiet periods, which is a pure loss and is invisible because the commitment is a fixed line on the bill rather than a variable one.

Trough-based sizing produces a smaller commitment than intuition suggests, and the discipline is then to grow it as the trough rises rather than to commit ahead of it.

Implementation patterns

• Measure the trough over a representative period, including seasonal quiet periods rather than only the last month.
• Prefer commitments to spend rather than to a specific instance type, because the first survives an architecture change and the second does not.
• Shorten the term where the technology is moving quickly. For accelerated compute a three-year commitment on hardware that will be superseded in eighteen months is a bet on resale value rather than on usage.
• Commit less during architectural volatility. A team mid-migration is about to change the shape of its usage.
• Track two numbers continuously: coverage — what proportion of usage is covered by commitments — and utilisation — what proportion of commitments is actually used. Both drift, and correcting them is routine rather than a project.
• Layer the rest: on-demand for the variable middle, interruptible capacity for work that tolerates it, with the price difference exposed to internal or external consumers as a class.

Industry example

GPU platforms such as RunPod and Together AI face this acutely because the underlying hardware is both expensive and rapidly superseded, and because their own demand is highly variable. The layered structure — reserved floor, on-demand middle, interruptible top, with customer-facing priced classes — is the shape that reconciles a variable business with a fixed-cost input.

The saving that is most often left on the table is the simplest: commitments are a purely commercial change with no engineering risk, routinely neglected because they belong cleanly to neither finance nor engineering.

Failure scenarios

• Committing to the average, leaving a proportion permanently unused.
• Committing to instance types, which an architecture change strands.
• Long terms on fast-moving hardware.
• No coverage or utilisation tracking, so drift accumulates unnoticed.
• Nobody owning the decision, which is why the easiest saving is the one most often missed.

Trade-offs

Commitments reduce optionality: a business that might shrink, migrate provider, or fundamentally change its architecture is buying a liability. That risk is real and is the argument for a smaller commitment rather than for none — the trough is by construction the portion least likely to disappear.

The opposite risk is paying a premium indefinitely on a baseline that has been stable for years, which is a quieter and usually larger loss.

Interview question

"Your usage varies between 40 and 120 units through the day and week. How much do you commit to, for how long, and what would make you commit less?"