Choosing Your AWS Commitment Coverage — and Knowing It Still Works

Knowing that a Compute Savings Plan gives you 66% and an EC2 Instance Savings Plan gives you 72% does not tell you what to buy. The menu is not the decision. The decision comes from your workload, and the discipline comes from what you do in the eleven months after you sign.

This part is the procedure we run with clients, the specific workload scenarios where the obvious answer is wrong, and the two numbers you have to watch afterwards. If you are about to sign something, skip ahead to the pre-commitment checklist and work backwards.

The procedure, in six steps

The six axes from Part 1 map onto six questions. Answer them in this order — the order matters, because step two invalidates step one if you do them backwards.

Step 1 — Find your floor, not your average

The single most common costly error is sizing a commitment against average or peak usage. Neither is the right number.

You want the floor: the minimum hourly usage you sustained across a trailing window of at least 90 days, including weekends, holidays, and your quietest maintenance window. That is the only usage you are certain will still be there next month. Unused commitment does not carry forward — an hour where your commitment exceeds your usage is an hour you paid full price for nothing.

Step 2 — Right-size before you commit, never after

If you commit three years of spend to an over-provisioned fleet, you have not saved money. You have locked in the waste at a discount, and removed your own incentive to fix it.

Right-size first. Run for a month. Then re-measure the floor, because it will have moved down — and the commitment you now need is smaller and the savings are larger.

Step 3 — Segment by confidence, not by team

• The frozen base. Workloads that have not changed in 18 months and will not change in the next 18.
• The predictable middle. Usage you are confident exists, but not confident about the shape of.
• The volatile top. Everything else.

You buy a different instrument for each. The mistake is buying one instrument for all three.

Step 4 — Ask the capacity question early

Before you compare discounts, ask: if AWS ran short of this instance type in this Region, would that be an incident? For most workloads the answer is no. For a few it is the only question that matters, and it inverts everything else in this article.

Step 5 — Set term by roadmap horizon, not by discount

Do not ask what term gives the best rate. Ask what you know about month 19. If a Graviton migration, a Kubernetes consolidation, or a serverless rewrite is anywhere on the roadmap, a three-year instrument-specific commitment will strand. A 66% discount you keep beats a 72% discount you abandon.

Step 6 — Set payment by cash position

All Upfront buys the deepest rate. No Upfront preserves runway. Partial splits the difference. This is a finance decision, not an engineering one, and it is worth actually asking your CFO rather than defaulting.

Nine scenarios where the obvious answer is wrong

1. GPU and ML training fleets — the case that inverts everything

This is the most important scenario here, and the one where standard FinOps advice actively hurts you.

For accelerated instances, capacity is the binding constraint, not price. High-end GPU capacity is genuinely scarce. If your training run cannot get instances, the discount on those instances is worth precisely nothing.

Savings Plans do not reserve capacity. Regional RIs do not reserve capacity. Only zonal scope does. So the ordering flips: first secure the capacity — a zonal RI, or an On-Demand Capacity Reservation — then apply a discount on top. Because a zonal RI pins you to one instance size in one Availability Zone, the ODCR-plus-Savings-Plan combination is usually the better structure. You get the capacity assurance without surrendering every dimension of flexibility.

Buy a Compute Savings Plan for a GPU fleet and no capacity reservation, and you have bought a discount on instances you may not be able to launch.

2. Kubernetes node groups

EKS and ECS node groups usually run a single dominant instance family for long periods, which makes them the textbook case for an EC2 Instance Savings Plan — full 72%, and you keep size flexibility as the autoscaler moves between sizes.

The trap: EKS control plane charges are not covered by any Savings Plan. The underlying EC2 instances are. Model the control plane separately or your coverage percentage will look permanently broken.

3. Spiky, bursty, or seasonal workloads

The temptation is to size the commitment against the peak so it is "covered." Do the opposite. Commit only to the trough and let the peak run On-Demand or on Spot. The peak is the part you are least sure about, and it is the part where over-commitment costs you every quiet hour for a year.

4. Windows and SQL Server fleets

Two specific traps. First, regional Standard RI instance size flexibility does not apply to Windows — it is Amazon Linux/UNIX with default tenancy only. Second, an EC2 Instance Savings Plan does cover an OS change, Windows to Linux, while continuing to pay out. If a licence-optimization project is on the horizon, that matters: the commitment survives the migration off Windows.

5. A migration or modernization already in flight

If you are mid-journey, you do not know your own instance families twelve months out. Buy a one-year Compute Savings Plan on the floor and nothing else. This is the most common situation we walk into, and the most common place we find stranded three-year commitments from a previous vendor.

6. Serverless-heavy estates

If a meaningful share of your compute is Lambda and Fargate, note that only the Compute Savings Plan reaches them. And one subtlety worth modelling: Savings Plans discount Lambda duration, not Lambda requests. A request-heavy, short-duration workload will show a much smaller benefit than a naive percentage suggests.

7. A stable, modern database estate

If your databases are not moving, RDS Reserved Instances still win on pure dollars — up to 69% versus roughly 20% for a Database Savings Plan on provisioned instances. Do not buy the newer instrument because it is newer.

8. A database estate mid-modernization

If you are moving RDS for Oracle to Aurora PostgreSQL, or consolidating onto DynamoDB, a Database Savings Plan is the instrument that survives the journey. You will give up real discount to get that, and whether it is worth it depends entirely on how confident you are in the migration timeline.

9. Dev, test, and staging environments

Before you commit anything here, ask whether these environments should be running at all outside business hours. Scheduling non-production down nights and weekends typically removes about 65% of their runtime. That is a bigger saving than any commitment discount, it requires no commitment at all, and doing it after you commit means you have locked in spend for machines you have just turned off.

Monitoring: the two numbers, and why one is a trap

Buying is the easy part. The failure mode is what happens over the following year, and it is almost always invisible on the bill until it is large. There are two metrics and they pull in opposite directions.

• Coverage — what share of your eligible usage runs at a discounted rate. Higher looks better.
• Utilization — what share of the commitment you bought is actually consumed. This must stay near 100%.

Chasing coverage alone is the trap. You can drive coverage to 100% by buying more commitment, and every point past your true floor shows up as a utilization dip on quiet hours. Paying for nothing at a discounted rate is still paying for nothing.

What good looks like: roughly 70–85% coverage of steady-state usage, with utilization at or very near 100%. Below about 95% utilization you are over-committed — that money is already gone, and the only fix is growing into it or waiting out the term.

The four things to actually watch

Where to look, and how often

AWS Cost Explorer publishes both Savings Plans and Reserved Instance coverage and utilization reports. The Cost and Usage Report carries the same data at line-item granularity when you need to attribute it per account or per team. Set a budget alert on On-Demand spend, not just total spend — total spend can look flat while the mix quietly degrades underneath it.

• Weekly — a two-minute glance at utilization. You are looking for a cliff, not a trend.
• Monthly — coverage by account and service. Where is new usage landing?
• Quarterly — re-derive the floor and re-plan. Roadmaps change; the floor moves.
• Ninety days before any expiry — start the renewal decision. Not thirty. Ninety.

Own the calendar or nothing else matters

Every mechanism above fails the same way: no named owner. Put every commitment expiry date in a shared calendar with a person's name against it, ninety days ahead. We have walked into accounts where a $40k/month increase went unnoticed for two billing cycles because that one thing did not exist. It is the cheapest control in this entire article and the one most often missing.

What to take away

Find the floor, not the average. Right-size before you commit, never after. Layer by confidence. Ask the capacity question before the price question — and if you run GPUs, ask it first and let it override everything else. Then watch utilization, not just coverage, and put a human name against every renewal date.

Next, in Part 3, we run this procedure end to end across four company sizes, with the numbers modelled so you can find the profile closest to yours.