Reserved Instances, Savings Plans and Committed Use

The mechanisms

Prefer the flexible form where it exists. AWS Compute Savings Plans and GCP spend-based commitments apply to a dollar amount rather than a specific machine type, so the discount survives changing your architecture.

The rule that prevents regret

Commit to the baseline you would still be running if the business stopped growing tomorrow.

1. Chart hourly compute spend for the last three months.
2. Find the minimum — the level that runs every hour, including weekends and quiet periods.
3. Commit to about 70 to 80 per cent of that minimum.
4. Everything above it stays on demand.
5. Revisit quarterly and add another layer as the baseline rises.

Layering commitments over time is the practical approach. Each new commitment covers newly stable capacity, so you never bet on a single forecast.

One or three years

Three-year terms discount more — often another 15 to 20 percentage points. They also commit you through a period in which your architecture will probably change.

• One year, no upfront: the safe default. Good discount, limited downside.
• One year, all upfront: better discount if cash flow allows.
• Three years: only for genuinely stable, unavoidable baseline capacity.

Consider what happened to your infrastructure over the last three years before assuming the next three will be stable.

Right-size first, always

Committing to over-provisioned instances converts a fixable problem into a fixed cost. The correct order is: remove waste, right-size, observe for a month, then commit.

It is common to see estates where a commitment locked in machines that were four times too large, and where the “savings” were smaller than the waste. See right-sizing cloud resources first.

When commitments do not fit

• Highly variable workloads with no meaningful baseline.
• Short projects that will end before the term does.
• Anything likely to move provider or be re-architected soon.
• Workloads that suit spot capacity instead, which discounts more deeply without a term.
• Small estates where the effort exceeds the saving.

VPS providers generally price low without commitment, so this whole mechanism is largely a hyperscaler consideration.

Managing them over time

1. Track utilisation of each commitment. Unused commitment is pure waste.
2. Set a reminder ninety days before expiry, so renewal is a decision rather than an accident.
3. Watch for auto-renewal settings that silently extend a term.
4. Use convertible or flexible forms so changing instance families does not strand the discount.
5. Check whether commitments apply across accounts in your organisation; usually they can, which improves utilisation.

Common questions

Where to go next

See spot instances for the other major discount, and cutting a cloud bill.