An AWS Savings Plan commits you to a steady hourly dollar amount of compute spend for a one or three year term, and in return AWS discounts usage up to that commitment by roughly up to 72 percent against on demand, while usage above the commitment bills at the on demand rate. Because the commitment is a spend rate rather than a specific instance, the discount follows your fleet as it changes, which is the whole appeal. Compute Savings Plans apply across families, sizes, regions, and across EC2, Fargate, and Lambda for maximum flexibility; EC2 Instance Savings Plans lock to a family in a region for a deeper discount. The buyer's job is to cover only the steady floor that runs every hour, sized to a defensible forecast, and to right size the fleet first so the commitment is not made against waste.
Here is the mechanism, the two plan types, and how to size coverage so the commitment stays highly utilized.
How does a Savings Plan actually work?
You commit to spend a set number of dollars per hour on compute, for a one or three year term, paid all upfront, partial upfront, or no upfront. AWS then applies the discounted rate to your compute usage hour by hour until that usage reaches your committed dollar amount; anything beyond it that hour bills at on demand. The key consequence is that the commitment is utilized only when you actually run enough compute to fill it. If you commit to more per hour than you reliably use, the unused portion is still owed, which is how an oversized commitment strands spend. Conversely, undercommitting leaves steady demand paying full on demand. The target is a commitment that your steady floor keeps almost fully utilized every hour.
Compute or EC2 Instance Savings Plan?
| Dimension | Compute Savings Plan | EC2 Instance Savings Plan |
|---|---|---|
| Flexibility | Across families, sizes, regions, OS, and EC2, Fargate, Lambda | Locked to one instance family in one region |
| Discount depth | Slightly smaller | Deeper, closer to a Reserved Instance |
| Best for | An evolving fleet whose mix and regions shift | A stable, known workload that will not move |
| Risk | Lower, the discount follows changes | Higher, value falls if the workload changes family or region |
The common pattern is a base of Compute Savings Plans for the flexible floor, with EC2 Instance Savings Plans or Reserved Instances added only where a workload is genuinely fixed. Discount figures are indicative and depend on term, payment option, family, and region; verify against current AWS pricing.
How do you size coverage without stranding spend?
Coverage is a risk decision, not a discount maximising one. Look at the hourly compute spend over a representative period and find the floor, the level that runs reliably every hour through weekends, troughs, and quiet seasons. Commit to that floor, not to the average and not to the peak, because only the floor is guaranteed to keep the commitment utilized. Leave the variable demand above the floor on demand, where you pay full rate but only when you actually use it. Critically, right size the fleet before committing: a Savings Plan bought against an oversized fleet locks the waste in for the full term. Then layer terms, using shorter one year commitments where the forecast is less certain and three year commitments only on demand you are confident will persist. Aim for high utilization, in the high nineties, rather than the highest possible coverage percentage.
A worked example
A scaling fintech wanted to maximise its Savings Plan discount and was about to commit to its average hourly compute spend. The problem: average included a daytime peak that did not run overnight, so a commitment at the average would have sat underutilized for hours every night, stranding spend. Sizing instead to the genuine overnight floor, after first right sizing the fleet, produced a Compute Savings Plan that ran close to fully utilized every hour, with the variable peak left on demand and a stable database on a deeper EC2 Instance plan. The result was a high effective savings rate with no stranded commitment, part of the program that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
How do AWS Savings Plans work?
What is the difference between Compute and EC2 Instance Savings Plans?
How do you size Savings Plan coverage?
Size your Savings Plans the right way
We help enterprises size and manage Savings Plan portfolios to a forecast they can defend, with high utilization and no stranded spend, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the AWS Savings Plan kit, read the deeper AWS cost optimization guide, and compare the models in Reserved Instances versus Savings Plans.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.