Every big cloud has the same deal: pay full price by the hour with no promise, or commit to a level of use for one or three years and pay much less. For servers that run all day, every day, a commitment is usually the single biggest saving available, bigger than any amount of tuning.

The names and rules differ between clouds, and the details matter: which services a plan covers, whether you can change your mind, and what happens if your usage drops. This post puts all three side by side, then explains how to decide how much to commit.

AWS

You commit to an amount of spend per hour, for one or three years. AWS also still sells Reserved Instances for some services. Once bought, a Savings Plan’s term can’t be changed; if you grow, you add another plan.

Azure

• Reservations: commit to a specific VM type in a region for one or three years, for up to 72% off pay-as-you-go. Instance size flexibility applies the discount to other sizes in the same group. Note a coming change: reserved VM instances bought from 1 February 2027 can no longer be exchanged.
• Savings plan for compute: commit to an hourly spend for one or three years, for up to 65% off. It applies across regions and VM series, and to App Service, Container Apps, Azure Functions Premium and more. It can’t be cancelled or changed once bought.
• Both can be paid upfront or monthly, at no extra cost for monthly.

Google Cloud

• Sustained use discounts: automatic, no commitment. VMs on eligible series (N1, N2, N2D, C2, M1, M2) that run for more than a quarter of the month get a growing discount, up to 30% for a full month.
• Resource-based committed use discounts: commit to a set amount of vCPUs and memory in a region for one or three years. These give Google’s deepest compute discounts; three years saves more than one.
• Flexible (spend-based) committed use discounts: commit to an hourly spend that applies across Compute Engine, GKE and Cloud Run. A smaller discount, much more flexibility.

Flexible or fixed?

Every cloud offers the same trade: the more specific your promise, the bigger the discount.

• Fixed (EC2 Instance Savings Plans, Azure reservations, Google resource-based commitments): biggest discount, but you are tied to a type of server and a region.
• Flexible (Compute Savings Plans, Azure savings plan, Google flexible commitments): a little less discount, but it follows you if you change server types, move regions or switch to containers.

For most companies we recommend starting flexible. The extra few percent from a fixed commitment is rarely worth it if your setup is still changing.

One year or three?

Three years always saves more per hour. But a three-year promise made today assumes you will run roughly the same thing until 2029. Choose three years only for the steady base that you are sure about, such as the core database or the always-on app servers. Use one year for everything else.

How much to commit

1. Fix the waste first. Turn off what isn’t needed and right-size what is. Committing to oversized servers locks in the waste.
2. Look at the lowest point, not the average. Find the level of usage you never go below over the last 30 to 60 days. Commit to that, or a little under it.
3. Let the busy hours run at normal prices. Spikes are what pay-as-you-go is for.
4. Use the cloud’s own recommendations as a starting point. AWS, Azure and Google Cloud all suggest a commitment based on your history.
5. Buy in steps. Commit to part now and add more each quarter as usage settles, so commitments don’t all expire on the same day.

A worked example

Take a company running 20 similar app servers on AWS. Over the last 60 days, usage never dropped below 12 servers, averaged 15, and peaked at 20 during month-end processing.

• Commit to about 11 or 12 servers’ worth of hourly spend with a one-year Compute Savings Plan. That level is used every hour, so none of the commitment is wasted.
• Run the rest at normal prices. The extra servers for busy days come and go as needed.
• Review in three months. If the floor has risen to 14, add a second, smaller plan for the difference.

Committing to 15 (the average) would look better on paper, but at quiet times three servers’ worth of commitment would be paid for and not used.

Who should own this

Commitments sit between engineering and finance. Engineering knows what will keep running; finance pays the bill and signs off on multi-year promises. Name one person on each side, agree the rules once (for example, “one-year flexible commitments only, reviewed each quarter”), and the decisions become routine instead of a debate every renewal.

Mistakes we see

• Committing before cleaning up, and then paying for idle capacity for three years.
• Buying for the average, which leaves part of the commitment unused at quiet times.
• Forgetting the expiry date, so the bill jumps the month the commitment ends.
• Nobody watching coverage and use. Check monthly that commitments are being used (utilisation) and that most steady usage is covered (coverage).

Where DevOps TechLab fits

We look at your last two months of usage on AWS, Azure or Google Cloud, clean up waste first, and then recommend what to commit to, for how long, and in what steps. Then we track utilisation and expiry dates each month so the savings hold.