AWS Savings Plans: The Right Way to Buy Commitment

Every quarter I look at a client's Savings Plans coverage and have the same conversation. They are at 40% coverage. AWS told them to commit more. They are nervous about over-committing. Could I take a look.

Yes. Here is how I think about it.

The three flavours, briefly

AWS Savings Plans come in three types:

• Compute Savings Plans. Apply to EC2, Fargate, Lambda. Up to about 66% discount. Maximum flexibility: any region, any family, any tenancy.
• EC2 Instance Savings Plans. Apply to a specific EC2 instance family in a specific region. Up to about 72%. Less flexible.
• SageMaker Savings Plans. Apply to SageMaker. Niche.

Reserved Instances still exist alongside these and behave similarly. The mental model below applies to RIs too.

The temptation is to chase the deepest discount. That is a mistake. The flexibility is worth more than the extra 6% in almost every realistic scenario.

The framework

Three questions, in order:

1. What is your committed steady-state floor?

Look at your last 12 months of compute spend. Plot it daily. The bottom of that curve is your floor: the level of compute you have run for every day of the last year, no exceptions. That floor is what you should buy Savings Plans against.

If your floor is $80k a month, buy Savings Plans for $80k a month. Not $90k. Not $70k. The floor.

The mistake teams make is buying against their average. Average is too high. If your average is $100k and your floor is $80k, buying $100k of commitment means in the bottom 30% of months you are paying for compute you did not use. The discount on the part you did use does not make up for the waste on the part you did not.

2. How much of that floor should be Compute vs EC2 Instance plans?

Default answer: 100% Compute Savings Plans.

The 6-percent-extra discount on EC2 Instance plans is not worth the inflexibility for most teams. The moment you change instance family, switch a workload to Fargate, or move to a different region, an EC2 Instance plan stops applying and you are paying on-demand again.

I make exceptions for two cases:

• A workload that is genuinely pinned. A fleet of r6i boxes running a database that nobody is going to migrate for two years. Buy EC2 Instance plans for that fleet.
• A workload large enough that 6% is meaningful money in absolute terms. If you are running $5M a month of a single instance family, 6% is $300k a year and the inflexibility is acceptable.

For everyone else, Compute Savings Plans, no exceptions.

3. One year or three years?

One year. Almost always.

The discount delta between 1-year and 3-year is usually 10-15 percentage points. Sounds tempting. The problem is that the cloud market in 2024 is moving fast. Graviton 3, Graviton 4, Trainium, Inferentia, the next generation of instance families. A 3-year commitment locks you out of the optimisation curve.

I make exceptions when:

• The workload is genuinely fossilised and not going to change. Stable enterprise SaaS, regulated workloads, anything that has not changed in three years and will not.
• The customer is large enough that the negotiated EDP discount on top of the 3-year SP changes the math materially.

For everyone else, 1-year. Renew. Re-evaluate every renewal.

The buying cadence

Do not buy Savings Plans once a year as a Big Project. Buy them quarterly:

• Each quarter, look at the trailing 90 days of usage.
• Recalculate your floor.
• Top up your commitment to that floor.
• If the floor dropped, do not panic. The existing commitment continues to apply where it can.

This keeps you tracking the floor without ever overcommitting. The mistake is making one big commitment in January and then doing nothing for a year while the workload changes underneath.

Common mistakes I see

• Buying based on AWS's recommendation tool without sanity-checking. The recommendation engine is good but it does not know your roadmap. If you are migrating off EC2 to ECS Fargate next quarter, AWS does not know that. You do.
• Mixing Savings Plans across accounts without a sharing strategy. In an Organization, Savings Plans share by default. Make sure that is what you want. Sometimes it is not.
• Paying upfront when there is no reason to. All-upfront gets you a marginal extra discount. Partial-upfront and no-upfront are fine. If the company has cash that should be earning interest, do not give it to AWS for a 1.5% extra discount.
• Ignoring Lambda and Fargate. Compute Savings Plans cover both. If your serverless spend is non-trivial, you are leaving money on the table by not including it in the floor calculation.

What "doing it right" looks like

For one mid-size client this year:

• 92% Savings Plans coverage on a $4M annual compute spend.
• 100% Compute Savings Plans, no EC2 Instance plans.
• 1-year terms, refreshed quarterly.
• Net savings versus on-demand: about 38%.

That is roughly the realistic ceiling for most workloads. If you are below 30% effective discount on your compute, you have headroom. If you are at 50%, somebody is being clever. If you are at 60%+, somebody is being clever and lucky and the next workload change will hurt.

Buy the floor. Stay flexible. Re-evaluate every quarter. That is the whole game.