Commitment purchasing is the most reversible-looking decision in cloud financial management that is in fact almost entirely irreversible. A three-year commitment made in the wrong month quietly taxes every architectural improvement you make for the following three years.
The sequencing rule
Do the structural work first. Rightsizing, scheduling, modernisation and Graviton migration all reduce steady-state consumption. Commit before those and you have purchased a discount on consumption you were about to eliminate — and the commitment does not shrink when the usage does.
The exception is a genuinely stable baseline you have no plans to change. Those exist, and they are rarer than people assume.
A commitment is a floor under your spend. Put the floor in before the optimisation and you have capped how much the optimisation can save you.
Commit to the trough, not the average
The single most useful heuristic: identify your minimum sustained consumption over the last ninety days — the trough, not the mean — and commit to somewhere between seventy and eighty per cent of it.
The uncovered portion runs on demand. That is not a failure to optimise; it is the premium you pay for the ability to change your architecture without penalty.
| Coverage | Effective saving | Flexibility |
|---|---|---|
| 50–60% | Modest | High — architecture can change freely |
| 70–80% | Most of the available benefit | Comfortable for most organisations |
| 90%+ | Marginally better | Low — improvements now strand commitment |
| 100% | No better in practice | Any reduction in usage is pure waste |
The curve flattens well before full coverage. The last twenty per cent of coverage buys very little.
Term and payment structure
Three-year all-upfront produces the largest headline discount and the largest regret when circumstances change. For a first purchase we almost always recommend one-year, no-upfront:
- It captures the large majority of the available discount
- It preserves cash, which matters more than the incremental percentage for most organisations
- It expires soon enough to be re-based against a changed architecture
- It makes the second purchase decision much better informed than the first
Move to three-year terms for the portion of your baseline you are confident will still exist in three years — typically core data stores and steady-state platform services, not application compute mid-modernisation.
Compute Savings Plans versus everything else
Compute Savings Plans apply across EC2, Fargate and Lambda regardless of instance family, size, region or operating system. That flexibility costs a little discount relative to EC2 Instance Savings Plans, and it is almost always worth paying for during a period of change.
EC2 Instance Savings Plans and Reserved Instances make sense for genuinely fixed workloads — a database fleet that is not moving, for instance. Applying them to application compute during modernisation is how organisations end up locked to an instance family they are trying to leave.
Buying commitments immediately after a migration completes, when consumption looks stable but has not yet been optimised. Wait for the rightsizing and scheduling work to settle — usually two to three months.
Running it as a rhythm
- Monthly: review coverage and utilisation; flag anything below 95% utilisation
- Quarterly: re-base the trough calculation and top up incrementally
- Before expiry: re-derive from current consumption rather than renewing like for like
- Before any major change: check what a modernisation program will do to the committed baseline before it starts, not after
Incremental top-ups beat annual bulk purchases. Several smaller commitments made quarterly track a changing baseline far better than one large decision made once a year on incomplete information.
Commitment renewal coming up?
We will model your trough, your planned architectural changes and the coverage level that leaves you room to keep improving.