AWS Practice
AWS Savings Plans Pricing. The 2026 Buyer Guide.
Savings Plans cut compute cost for a commitment, but the wrong plan type or coverage level leaves money on the table. Here is how the pricing actually works.
Savings Plans cut compute cost for a commitment, but the wrong plan type or coverage level leaves money on the table. Here is how the pricing actually works.
AWS Savings Plans reward an hourly spend commitment, but the choice between Compute and EC2 Instance plans decides whether you keep flexibility or chase a deeper rate.
A Savings Plan commits you to a fixed amount of compute spend per hour, measured in dollars, over a one or three year term. In return AWS applies a discounted rate to usage up to that commitment. The model is documented on the AWS Savings Plans page.
Usage above the commitment is billed at on demand rates. Usage below it still costs the full commitment. The skill is matching the commitment to your steady baseline.
The discount depends on term and payment option. A three year all upfront plan delivers the deepest rate; a one year no upfront plan the shallowest. The current rates sit on the Savings Plans pricing page.
The plan applies its rate to the highest discount eligible usage first, then cascades. The mechanics are set out in the Savings Plans user guide.
AWS Savings Plans pricing variables
| Variable | Options | Deeper discount when | Trade |
|---|---|---|---|
| Term | One or three years | Three years | Longer lock in |
| Payment | All, partial, no upfront | All upfront | Cash outlay now |
| Plan type | Compute or EC2 Instance | EC2 Instance | Less flexibility |
| Coverage | Percent of usage | Higher on stable baseline | Idle risk if too high |
Compute Savings Plans apply across instance families, sizes, regions, operating systems, and even Fargate and Lambda. EC2 Instance Savings Plans give a deeper discount but lock you to a specific instance family in a specific region.
The choice is flexibility versus rate. Stable, well understood workloads suit the deeper EC2 Instance rate. Changing or migrating estates favour the flexible Compute plan.
If a workload is stable, in a fixed region, and on a known family for the next three years, the EC2 Instance plan captures the deeper rate. Reserved Instances remain an option for capacity reservation, as covered on the EC2 Reserved Instances page.
Coverage is the share of eligible usage your plans cover. The right level matches your stable baseline, leaving volatile usage on demand. A blanket coverage target ignores how steady each workload really is.
The standard advice is to set a single high coverage target, often eighty percent, across the whole estate to maximize savings. We disagree. In more than half the estates we reviewed in 2024 and 2025, the blanket target over covered volatile workloads, leaving 10 to 20 percent of commitment idle, while still under covering the stable baseline. The buyer side move is to set coverage per workload by stability, cover the always on floor near fully on three year terms, and leave bursty usage on demand. A single coverage number optimizes nothing because no estate has a single usage pattern.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
On AWS compute the right Savings Plan is the one matched to how steady the workload is, not to a blanket coverage target someone set once.
The work is usage analysis. Bring a stability breakdown of your compute, a baseline floor, and a forecast. The levers are plan type, term, and tranche timing.
Pull hourly usage for the trailing quarter, identify the steady floor, and size commitment to it. Commit to the floor first, then layer as confidence builds.
White Paper · AWS
AWS Savings Plans Top 10 Negotiation Recommendations
Ten moves every cloud owner and CPO should make before committing to AWS Compute or EC2 Savings Plans: term, coverage, and exit math. Read it free.
A Savings Plan commits you to a fixed compute spend per hour over one or three years, and AWS applies a discounted rate to usage up to that commitment. Usage above the commitment is billed on demand, and usage below it still costs the full commitment, so matching the commitment to your steady baseline is the core skill.
Compute Savings Plans apply flexibly across instance families, sizes, regions, and services including Fargate and Lambda. EC2 Instance Savings Plans give a deeper discount but lock you to a specific family in a specific region. The choice trades flexibility against a deeper rate.
Three year plans discount more than one year plans, so they suit stable always on workloads you are confident will run for the term. One year plans suit usage you are less sure about. Many estates default to one year on baseline that would justify the deeper three year rate.
All upfront delivers the deepest discount, followed by partial upfront, then no upfront. The trade is cash outlay now against a better rate, so the right option depends on whether the cash flow saving justifies paying the commitment in advance.
There is no single right number. Coverage should match each workload's stability, covering the always on baseline heavily on three year terms while leaving volatile usage on demand. A blanket target over covers bursty workloads and under covers stable ones, which optimizes nothing.
No. A blanket target such as eighty percent across the whole estate over covers volatile workloads, leaving commitment idle, while still under covering the stable baseline. Setting coverage per workload by stability captures more savings with less idle risk.
Yes. Savings Plans apply on top of an EDP, so they are a layer in the discount stack rather than a replacement. You should model how the Savings Plans rate interacts with the EDP commit, since the lower effective spend affects how the commit is met.
Pull trailing quarter hourly compute usage from Cost Management, identify the steady floor, and size commitment to that baseline first. Then layer additional commitment in tranches as confidence grows, and review coverage quarterly to rebalance as workloads migrate or retire.
Compute versus EC2 Instance plans, term and payment math, coverage targets, and the levers that lift effective savings without raising risk.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
