Reserved vs. On-Demand — the Real Maths

Commit to a discount you might not use, or pay full price for flexibility you might not need. The break-even logic is simple; getting the inputs right is not.

What you are actually buying

A reservation is not a reservation in the hotel sense. You are not holding capacity; you are pre-paying for a billing discount. The underlying instance may or may not run — the charge lands either way. That distinction matters enormously when workloads are seasonal, experimental, or subject to architectural change.

The discount in exchange for that commitment is real and substantial. One-year terms typically reduce on-demand rates by somewhere in the range of a third; three-year terms push further, sometimes approaching half or more. The exact ratio varies by provider, instance family, region, and whether you pay all-upfront, partial-upfront, or monthly. All-upfront locks in the deepest discount because you are lending the provider cash at zero interest — factor that cost of capital into the maths if it is material to your organisation.

What you receive in return is a billing credit applied to any matching usage. "Matching" is where the complexity lives. Reservations are scoped to specific instance families, sizes, operating systems, and tenancy models. Some providers offer convertible variants that let you exchange one reservation for another of equal or greater value — useful, but not free of friction. A reservation bought for a specific instance type in a specific region that you subsequently stop using becomes the idle tax paid in advance, in bulk.

The break-even calculation

Strip the maths to its core: you break even when the cumulative discount earned equals the commitment cost you would have forfeited had you walked away at that point. In practice this means asking how many hours of actual usage it takes to recover the premium you paid over the cheapest flexible alternative.

A rough illustrative frame: if on-demand costs one unit per hour and a one-year reservation costs roughly 0.65 units per hour equivalent, you save 0.35 units per hour of use. The reservation commits you to paying that 0.65 whether or not the instance runs. If the instance runs continuously, you save about 35% annually — the case is easy. If it runs about 65% of the time, your effective hourly cost across all hours, running and idle, approaches the on-demand rate. If it runs less than about 65% of the time, the reservation costs you more than on-demand would have.

The break-even utilisation threshold — the point below which on-demand is cheaper — sits roughly where your blended effective cost equals the on-demand rate. Work backwards from your actual discount percentage to find it. A 30% discount breaks even at around 70% utilisation; a 45% discount breaks even closer to 55%. Neither number is magic; both are sensitive to the specific terms your provider offers, so run the arithmetic with real figures before committing.

Where the logic breaks down

The inputs look easy to estimate and are surprisingly hard to get right. Workload growth is the obvious trap: a reservation bought for current capacity is insufficient the moment you need to scale up, and the gap is filled at on-demand rates. Workload contraction is the quieter one — teams retire services, migrate to managed alternatives, or redesign architectures. A three-year reservation on an instance family you abandon in year two is a sunk cost with no off-ramp except selling unused reservations on the marketplace, where liquidity is imperfect and prices move.

In practice this means asking how many hours of actual usage it takes to recover the premium you paid over the cheapest flexible alternative.

Technology churn compounds this. The lift-and-shift trap often lands teams on over-provisioned instance types they then optimise away. If that optimisation changes the instance family, a non-convertible reservation may not follow. Providers update their instance generations regularly; older reservations on older families do not automatically migrate.

The sensible approach is rarely all-or-nothing. Reserve the stable, predictable baseline — the floor of your utilisation curve — and cover variable demand with on-demand or, where interruption is tolerable, spot capacity. How much of your fleet actually qualifies as stable baseline is the honest question most teams answer too generously. Review actual utilisation data over at least a full seasonal cycle before committing anything beyond a one-year term.

Reserved capacity is a cash-efficiency tool, not a cost-reduction guarantee. The guarantee depends entirely on whether your usage assumptions survive contact with reality.