Committed use, reserved instances and savings plans compared

Every large cloud provider offers the same basic bargain: promise to spend for one or three years and pay significantly less. The discount is real and substantial, frequently a third or more.

What differs, and what determines whether the commitment is a saving or a stranded cost, is exactly what you are promising.

The three things you can commit to

A specific resource shape. You commit to a particular instance family and size, in a particular region, for a term. The discount is the deepest available, and the flexibility is the lowest. If you stop using that shape, the commitment continues.

An amount of resource. You commit to a quantity of vCPU and memory in a region, without naming the instance type. Somewhat more flexible: you can change shapes as long as the total resource stays committed.

An amount of spend per hour. You commit to a monetary figure and any usage up to it is discounted, across families and often across regions and services. The discount is usually smaller than the resource-specific option, and the flexibility is much higher.

Terminology varies. Google’s committed use discounts come in resource-based and flexible spend-based forms. Amazon offers reserved instances and savings plans. Microsoft offers reservations and savings plans. The concepts map closely even where the names do not.

Which one to choose

The decision is about how confident you are, and about what specifically you are confident of.

Choose a resource-specific commitment when the workload is stable, the shape has been unchanged for months, and you can say with a straight face that it will still be that shape next year. Databases and long-running platform components often qualify.

Choose a spend-based commitment when you are confident about the total but not the composition: you know you will spend at least a certain amount monthly, but you expect to move between instance families, adopt new services or shift regions.

Choose neither, for now if you have been running for less than a few months. Committing before the workload has settled is the single most common way commitments end up unused.

Commit to the floor, never the average

This is the rule that prevents almost all waste.

Plot hourly usage over the last few months and find the level below which usage never falls. That is the floor. Commit to it, or slightly under it.

Committing to the average means that whenever usage is below average, part of the commitment is paying for nothing. Committing to the peak guarantees substantial waste. Committing to the floor guarantees the commitment is always fully used, and everything above it runs at on-demand or spot rates.

You can always add a second commitment later if the floor rises. You cannot easily unwind one that is too large.

Term length

One year and three years are the usual options. Three years discounts more deeply.

The question is not whether you will still be using cloud infrastructure in three years. It is whether you will still be using this shape of infrastructure. Three years is a long time in a technology stack: new instance generations arrive and are cheaper per unit of work, architectures change, workloads move to managed services.

A reasonable default is one-year terms for most things, and three-year terms only for genuinely fixed, boring infrastructure whose shape you can predict confidently. The deeper discount on a commitment you stop using is not a discount.

The parts people forget

Payment options change the discount. Paying all upfront discounts more than paying monthly. The difference is effectively an interest rate, and whether it is worth it depends on what else you would do with the cash.

Regional scope matters. Some commitments are locked to a region; some apply more broadly. A region-locked commitment becomes stranded if you move workloads.

Commitments do not stop resources being wasteful. A committed instance running at eight percent utilisation is discounted waste. Right-size first, then commit to the right-sized figure. Doing it the other way round locks in the oversizing.

Coverage and utilisation are different metrics. Coverage is what share of your usage is discounted. Utilisation is what share of your commitment is being used. You want utilisation near a hundred percent and coverage matching your stable baseline. High coverage with low utilisation means you over-committed.

Renewal is not automatic in the way you might hope. Track expiry dates. A commitment lapsing unnoticed means an abrupt return to on-demand pricing, which shows up as an unexplained bill increase.

A sensible sequence

1. Run on demand until the workload’s shape has been stable for two or three months.
2. Right-size everything, because committing to oversized resources locks in the waste.
3. Find the floor of hourly usage over that period.
4. Commit to the floor with a one-year term, using a spend-based commitment unless the shape is genuinely fixed.
5. Review quarterly, checking utilisation and adding a second commitment if the floor has risen.
6. Diary the expiry so renewal is a decision rather than an accident.

Followed in order this captures most of the available discount with very little risk of stranded commitment.

Where you run this matters less than how, but if the provider is still open, the cloud account catalogue compares the options side by side.

For the vendor’s own reference on the services involved here, see the Google Cloud documentation.

If you want to work through this yourself, our Google Cloud accounts come in six configurations with every price shown, and the cloud account catalogue compares them against the other nine platforms.

Questions people ask