How Much AWS Savings Plans Commitment Is Right? The Sizing Problem, and How to Stop Guessing

The short answer

If you take one thing from this post: commit against your durable baseline — the compute that's genuinely on around the clock — not the average week, and not the peak. Turn that into a coverage policy you can defend (how much of your spend you want under commitment, plus a ceiling you won't cross), then add commitment in small steps toward it rather than in one big purchase.

Everything below is why that's the right answer, why the usual process makes it hard, and how to run it continuously without babysitting a spreadsheet.

Why "how much" is genuinely hard

Start with the two words people use interchangeably and shouldn't: coverage and utilization.

• Coverage is how much of your eligible on-demand spend is sitting under a commitment. If you're running about $80/hour on Savings-Plans-eligible compute and $60/hour of it is covered, you're at 75% coverage.
• Utilization is how much of the commitment you bought actually gets used. If you commit to $70/hour and only $60/hour of matching usage shows up, you're at ~86% utilization and you're still paying the committed rate for the 14% that went idle.

Here's the uncomfortable part: these two move in opposite directions when you push on them. Chase higher coverage and you buy more commitment, which makes it easier for utilization to slip if usage dips. Protect utilization by buying conservatively and your coverage — and your savings — stays low. Sizing a commitment is the act of choosing where to sit on that seesaw. Most teams never make the choice explicitly; they just react.

Then there are the levers, each of which changes the math:

Choice	Options	The tradeoff
Term	1 year vs. 3 years	3-year deepens the discount but triples the lock-in you're betting on.
Payment	No / Partial / All Upfront	More upfront buys a slightly better rate, but ties up cash and raises the stakes on being wrong.
Plan type	Compute SP vs. EC2 Instance SP	Compute SP (~up to 66% off) flexes across instance family, size, region, OS, tenancy, and even Fargate/Lambda. EC2 Instance SP (~up to 72% off) pays a bit more but locks you to an instance family in a region. Flexibility vs. discount, again.

To see what these choices are worth, look at what they do to the price of a single instance — the same c6a.8xlarge, one region, priced across Compute Savings Plan terms and payment options (plus on-demand):

The spread is enormous: the same box runs about $1.22/hour on-demand down to ~$0.54/hour on a three-year Compute Savings Plan — a ~56% swing decided entirely by how you buy. And the deltas aren't evenly spaced: moving from a 1-year to a 3-year term nearly halves the rate, while the upfront choice (No / Partial / All) only nudges it a couple of percent. The lever that looks like fine print — term length — is the one that actually moves the money.

Every one of those choices assumes you know what your workload looks like over the entire term. On a three-year, all-upfront, EC2-Instance plan, you're not sizing a commitment — you're making a prediction about your architecture in 2028. That's the real difficulty. The number isn't hard to compute. The future it depends on is hard to know.

The five forces that keep moving the target

If your usage were a flat line, this would be a spreadsheet exercise. It never is. Five forces keep dragging the "right" number around after you've committed.

1. Usage isn't flat. Real compute spend swings week to week such as batch jobs, launches, seasonal traffic, a big customer onboarding. A commitment sized to a good week becomes over-commitment in a quiet one. Size to a busy week at $70/hour when your durable baseline is really $60/hour, and the moment things quet down the extra $10/hour is idle commitment, that's about $87,600 a year paid for capacity you're not using. The discount you were chasing is smaller than the waste you created.

2. Rightsizing and migrations shrink the baseline. This is the one that quietly strands the most money. You commit to today's usage, then your team does its job and rightsizes over-provisioned instances, moves a service to Graviton, refactors a monolith. Your usage drops, and your commitment doesn't. You commit to your $60/hour baseline, then your team migrates to Graviton and the baseline sttles at $50/hour. Overnight, that ~$10/hour of commitment has nowhere to land with about two years left on a three-year plan, roughly $175K stranded. You did the right engineering thing and got punished for it. The correct move is the opposite order: rightsize first, then commit to the leaner steady-state. Almost nobody does, because the commitment and the rightsizing live in different teams' backlogs.

3. Commitments expire and expirations arrive in clusters. A Savings Plan you bought a year ago drops off on a specific day. If you bought several in a burst, they expire in a burst, and your coverage falls off a cliff overnight. Renewing means re-running the whole sizing exercise, at exactly the moment you're least likely to be watching. Miss it and you're back on full on-demand rates for the expired slice.

4. A coverage target is not a utilization outcome. You can aim for 80% coverage and still end up with poor utilization if usage softens after you buy. Targets are set on history; utilization is realized in the future. The gap between them is pure waste, and you don't see it until the bill arrives.

5. Time itself. Every day you wait for "enough certainty" to commit is a day at on-demand rates. Teams delay commitments for months chasing confidence that never comes and the discount they postpone is gone for good. As we put it in the commitment-mistakes post: even during migrations and uncertainty, committing some portion beats committing nothing.

Notice that none of these are planning failures. They're just reality. Your infrastructure is supposed to change. The problem isn't that the target moves — it's that most commitment processes are built as if it doesn't.

Why the manual approach breaks down

Here's how sizing usually happens in practice.

Once a quarter, someone opens AWS's Savings Plans purchase recommendation. AWS looks back over a window - you can choose 7, 30, or up to 60 days — and hands you a single suggested hourly commitment optimized for maximum savings. Someone eyeballs it, maybe discounts it "to be safe," gets an approval, and buys.

There are three problems baked into that flow.

First, it's a single number from a single lookback. Max-savings recommendations assume your recent past is your future and push coverage high. Great when usage is stable; expensive the moment it isn't.

Second, it's a big-bang purchase. You take your whole quarter's commitment decision and execute it in one transaction, on one day. If that day happens to sit at the top of a usage spike, you've just anchored a year of commitment to a peak.

Third, it's already stale. By the time the recommendation is reviewed, approved, and purchased, days or weeks have passed and usage has moved. You're not committing to your current reality, you're committing to a snapshot of a reality that's already gone.

The deeper issue is cadence. Usage changes continuously; the manual process fires quarterly. You're sampling a moving signal four times a year and acting on each sample weeks late. No amount of spreadsheet rigor fixes a sampling-rate problem.

A better mental model: size to the baseline, then ladder to it

The fix is really two separate jobs, and it helps to name them: sizing (picking the right number) and laddering (getting there safely). Two changes in how you think about each.

Change one — sizing: anchor on the durable baseline. This is the job of choosing the number. Instead of "what's the right dollar amount," decide how much of your eligible spend you want covered — anchored on the durable baseline, the part that runs around the clock — and let the dollar amount fall out of that. It turns an unbounded guess into a policy you can reason about:

• Conservative (~65% coverage). You protect utilization and keep flexibility. You leave some savings on the table on purpose. Good for volatile or fast-changing usage.
• Balanced (~80% coverage). The default for most steady production workloads, meaningful savings with a comfortable buffer against dips.
• Aggressive (~90% coverage). Maximum savings, minimal buffer. Only appropriate when your baseline is genuinely stable and predictable.

Why not just always pick aggressive? Because coverage has diminishing returns, and the last slice is the dangerous one. The bottom of your usage — the part that's on 24/7/365 — is the safest to cover and where the discount is basically free money. As you push coverage higher, you start committing against the variable top of your usage: the hours that only exist during spikes. That marginal spend is exactly the spend most likely to disappear, which means the coverage you add above ~80% carries most of the over-commitment risk while adding the least reliable savings. The right posture isn't "cover everything." It's "cover the stable base aggressively and the volatile top cautiously."

Change two — laddering: get there in small steps. This is a different job: not what to commit, but how to reach it. Instead of one large purchase, break the distance to your target into a series of small, staggered commitments over time. Laddering solves several of the five forces at once:

• Small, frequent steps mean no single purchase anchors to a peak. You're averaging into your commitment the way you'd dollar-cost-average into a position.
• Staggered start dates mean staggered expirations, no renewal cliff, because your plans roll off a few at a time instead of all at once.
• Committing gradually means you can stop or slow down the moment usage softens, instead of discovering the over-commitment a year into a locked contract.

But keep the two jobs separate. Laddering manages timing — purchase concentration and expiration cliffs — not sizing. It can't rescue a target that's too aggressive: ladder slowly toward the wrong number and you still end up over-committed, just a few weeks later. Get the baseline right first; ladder to it second.

The catch: sizing to a moving baseline, re-checking coverage every week, adjusting for expirations, and pausing on downturns is a genuinely continuous job. Done by hand, it's a part-time role nobody has. That's exactly the gap automation is built to fill.