Reserved and Committed Capacity

The discounts are large enough to matter — commonly 30% to 70% against on-demand — and the mechanism is simple: commit to a level of usage or spend for one or three years and pay less for it.

The risk is not financial complexity, it is architectural. A three-year commitment to a specific instance family assumes you will still be running that shape in three years, and teams that commit heavily and then migrate to containers, serverless or a managed service find they have pre-paid for capacity they no longer use. The commitment then becomes an argument against a good architectural decision, which is the worst outcome of all.

The practice that avoids it: commit only to the stable baseline — the floor of usage that has persisted and will persist regardless of architectural direction — and leave the variable portion on demand or on spot. Prefer flexible commitment forms that apply across instance families and regions over rigid ones tied to a specific configuration, accepting the slightly smaller discount as the price of optionality. Ladder expiry dates rather than committing everything at once, so the estate is never fully locked in a single window.

The organisational half: this needs finance and engineering in the same conversation, because the commitment horizon must be set against the architectural roadmap, and neither function has both pieces of information on its own.