AWS Savings Plans, coverage by stability, not by slogan
A Savings Plan commits a fixed hourly dollar spend for one or three years and discounts usage up to it: above the commitment bills on demand, below it the commitment bills anyway. The whole skill is matching the commitment to the steady baseline, and the blanket coverage target most estates run gets both halves wrong at once.
Prepared by Redress Compliance · August 6, 2026 · AWS advisory. Based on 30 to 40 Savings Plans reviews led 2024 to 2025.
Executive summary
The blanket target optimizes nothing. The standard advice, one high coverage number across the whole estate, failed in more than half the estates we reviewed: stable always on workloads ran 20 to 40 percent uncovered, paying on demand rates needlessly, while volatile workloads were over committed with 10 to 20 percent of commitment sitting idle. No estate has a single usage pattern, so no single number can cover it well.
The plan family is a flexibility trade. Compute Savings Plans flex across instance families, sizes, regions, and services including Fargate and Lambda; EC2 Instance Savings Plans pay a deeper rate for locking a family in a region. Stable, well understood workloads earn the deeper EC2 Instance rate; migrating and changing estates need the Compute plan's flexibility to avoid stranding commitment mid move.
Term and payment set the rate, and estates default too short. Three years discounts more than one, all upfront beats partial beats no upfront, and the recurring term mismatch was one year plans on baseline stable enough to justify the three year rate. The correction across our reviews was worth a 16 percent average net rate improvement, from re-terming and re-covering the same workloads.
Savings Plans are a layer, not the deal. The plan discount stacks under an Enterprise Discount Program: the EDP private rate applies first and the plan rate applies to it, while committed plan spend counts toward the EDP commit. Sequencing matters, the EDP negotiated on the full forecast, the plans committed to the floor, because the EDP discounts ambition safely and the hourly commitment punishes it.
The pricing variables, and what each one trades
| Variable | Options | Deeper discount when | The trade |
|---|---|---|---|
| Term | One or three years | Three years | Longer lock on a moving estate |
| Payment | All, partial, or no upfront | All upfront | Cash outlay now against rate |
| Plan type | Compute or EC2 Instance | EC2 Instance | Family and region locked for the term |
| Coverage | Percent of eligible usage | Higher on stable baseline | Idle commitment if set on volatile load |
Compute versus EC2 Instance, flexibility against rate
The choice resolves by workload, not by estate. The EC2 Instance rate wins where a workload is stable, in a fixed region, on a known family for the term: the deeper discount is free money on a floor that will not move. The Compute plan wins everywhere change is plausible, migrating estates absorbing instance and region moves without stranding commitment, mixed estates extending coverage to Fargate and Lambda, and uncertain roadmaps avoiding a family lock they may exit. The same discipline applies one platform over on the ML estate, where SageMaker carries its own separate plan family that Compute commitments never cover, and where replatforming strands value fastest.
The Savings Plans negotiation recommendations
Ten moves before committing: the term and coverage math, the tranche construction, the exit arithmetic, and the EDP stacking order.
Get the white paper →Coverage by stability, the split that stops the idling
The working method replaces the blanket target with a two speed split. The always on floor, identified from trailing quarter hourly usage, gets covered heavily on three year terms, because it will run for the term and every uncovered hour is a needless on demand premium. Volatile and bursty usage stays on demand, because idle commitment costs more than the discount saves. Between the two sits the tranche discipline: commitment added in steps as baseline confidence grows, never all at once, and the whole position rebalanced quarterly as workloads migrate and retire. The estates that idled 10 to 20 percent of their commitment all shared the same origin story, a coverage percentage set once, by policy, and never revisited against the workload mix.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Savings Plans reviews, 2024 to 2025
Across roughly 30 to 40 AWS Savings Plans reviews Fredrik Filipsson led between 2024 and 2025, coverage was set by a blanket target rather than workload stability in the majority of estates:
Stable always on workloads paying on demand rates a three year plan should have covered.
Net rate improvement from re-terming and re-covering the same workloads by stability.
The two failure modes are mirror images and usually coexist: the stable floor undercovered because the blanket percentage was calibrated to the whole estate's volatility, and the volatile tail overcovered because the same percentage ignored its burstiness. For estates negotiating the broader commercial stack, the EDP benchmark data prices what the private rate should concede at each commit tier, and the plan layer then works underneath whatever rate that negotiation lands.
Your first five moves
- Pull the trailing quarter's hourly usage from Cost Management and separate the always on floor from the volatile tail, because the split is the whole method.
- Cover the floor on three year terms, EC2 Instance plans where the family is fixed, Compute plans where change is plausible.
- Leave bursty workloads on demand, because idle commitment costs more than the discount saves.
- Layer commitment in tranches as baseline confidence grows, and rebalance the position quarterly as workloads migrate and retire.
- Sequence against the EDP: the private rate on the full forecast first, the plans on the floor after. The cost optimization practice runs the sizing with you.
Frequently asked questions
How does AWS Savings Plans pricing work in 2026?
A Savings Plan commits a fixed hourly dollar spend over one or three years, and AWS applies a discounted rate to usage up to the commitment. Usage above it bills on demand; usage below it still costs the full commitment. The rate deepens with longer terms and more upfront payment, and the skill is sizing the commitment to the steady baseline.
What is the difference between Compute and EC2 Instance Savings Plans?
Compute Savings Plans apply across instance families, sizes, regions, and services including Fargate and Lambda; EC2 Instance Savings Plans pay a deeper rate for locking a specific family in a specific region. Stable fixed workloads earn the deeper rate, and migrating or uncertain estates need the Compute plan's flexibility.
What coverage level should Savings Plans target?
There is no single right number, which is the point: coverage should match each workload's stability, the always on floor covered heavily on three year terms and volatile usage left on demand. Blanket targets undercovered stable baseline by 20 to 40 percent while idling 10 to 20 percent of commitment in the estates we reviewed.
Should we choose one year or three year Savings Plans?
Three year plans discount more, so baseline you are confident will run for the term belongs on them, and the recurring mistake was one year defaults on workloads stable enough for the deeper rate. One year plans fit usage you are genuinely less sure about, and tranching lets confidence build before the term extends.
How do Savings Plans interact with an AWS EDP?
They stack: the EDP private rate applies first and the plan discount applies to the discounted rate, while committed plan spend counts toward the EDP commit. Negotiate the EDP on the full forecast, then commit plans to the pessimistic floor, because the EDP discounts ambition safely and the hourly commitment punishes it.
How much can Savings Plans optimization save?
Re-terming and re-covering the same workloads by stability produced a 16 percent average net rate improvement across our 34 reviews, without any workload change: covering the 20 to 40 percent of uncovered baseline, releasing idle commitment on the volatile tail, and moving stable one year plans to the three year rate.
