TL
The short answer

Every cloud sells the same bargain in different words: commit to steady usage and pay less, carry the risk that your usage falls and pay for capacity you no longer need. AWS calls it Savings Plans and Reserved Instances, Azure calls it Reservations and the Azure savings plan, GCP calls it Committed Use Discounts, and Oracle calls it Universal Credits. They discount roughly twenty to seventy two percent against on demand, and they all shift utilization risk to you. Manage them as one portfolio and the discount is real. Manage them per cloud in separate spreadsheets and you get silent lapses, stranded coverage, and renewals negotiated from weakness.

Coverage follows a forecast, not a discount

The most common commitment mistake is buying to the largest discount tier instead of to a defensible forecast. A three year commitment on a workload you might sunset in eighteen months is not a saving; it is a bet you will keep running something you wanted to retire. Coverage should track the steady baseline you are confident about, with on demand and short commitments absorbing the uncertain top layer. That means the right coverage number is below one hundred percent by design, sized to the part of the estate you would run no matter what. Commitment strategy is risk adjusted, not discount maximised, and the difference is the whole discipline.

A commitment portfolio ledger tracking Savings Plans, Reservations, CUDs, and Universal Credits with utilization across clouds.
One ledger for every instrument, across four clouds

Utilization is where the leak hides

A commitment you bought and stopped using is worse than no commitment, because you are paying the discounted rate for capacity that sits idle. Utilization needs watching continuously, not at renewal, because a workload that moved or shrank turns a good commitment into a standing loss the moment it changes and nobody notices. The instruments differ in how forgiving they are: a flexible Savings Plan reshapes with your usage, while a specific Reserved Instance does not, and that flexibility is worth paying a little for in an estate that changes often. A portfolio view that shows utilization per instrument catches the leak while you can still act on it, by exchanging, adjusting future coverage, or letting a poor commitment lapse deliberately rather than by accident.

Expiry and renewal, timed on purpose

Commitments expire, and an expiry you did not plan for is a spike in the next bill as covered usage snaps back to on demand. The portfolio should surface what lapses when, far enough ahead that renewal is a decision rather than a scramble. Timing matters for leverage too: a renewal negotiated twelve months before your commitment ends, with a clean forecast and the credible option of placing workloads elsewhere, goes very differently from one negotiated the week before expiry with no alternative. Tie the forecast to the portfolio and renewal becomes a position of strength.

A twelve month forecast used to size commitment coverage and time renewals across clouds.
A forecast that sizes coverage and times renewals
Buy commitments last

Cover a bloated estate and you lock in the bloat. Rightsize, remove idle capacity, and clean up storage first, then size commitments to the lower steady state. A commitment bought over waste is a two year contract to keep paying for it.

Why a portfolio, not four spreadsheets

Each cloud gives you a console that shows its own commitments and none of the others. For a single cloud estate that can be enough. For a multicloud estate it guarantees blind spots, because coverage decisions interact: a workload you are about to move off one cloud changes what you should commit to on another, and no single console sees the whole picture. One portfolio view across AWS, Azure, GCP, and OCI, tied to one forecast, is what lets you set coverage, watch utilization, and time renewals as a single strategy rather than four disconnected guesses. For the coverage math itself, see commitment coverage targets that make sense.

Frequently asked questions

How much coverage should I commit to?
Below full coverage, by design. Commit to the steady baseline you are confident about and let on demand or short commitments absorb the uncertain top layer. Coverage follows a defensible forecast, not the largest discount tier.
What happens if I stop using a commitment?
You keep paying the discounted rate for idle capacity, which is worse than no commitment. That is why utilization needs continuous watching, so you can exchange, adjust future coverage, or let a poor commitment lapse on purpose.
Why manage commitments across clouds together?
Because coverage decisions interact and each cloud's console only shows its own. A workload moving off one cloud changes what you should commit to on another, and only one portfolio view tied to a single forecast catches that.

See every commitment in one place

Datum tracks Savings Plans, Reservations, CUDs, and Universal Credits as one portfolio, with utilization and expiry across clouds. Tour the platform, or bring us a renewal.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.