Home  ›  Blog  ›  AWS Savings Plans Strategy 2026
AWS · Savings Plans

AWS Savings Plans — the most under-deployed lever on the invoice.

AWS Savings Plans deliver up to 72% off on-demand compute. The typical enterprise hits 41–58% coverage when the empirically correct number sits between 72% and 88% of stable production compute. The decision is governance, not finance — and the layering structure determines whether the savings actually compound across the term.

Updated: May 2026 Reading time: 14 min Audience: CIO, CFO, FinOps, Cloud Procurement
AWS Savings Plans
The Savings Plans decision

Savings Plans are the most under-deployed lever on the AWS invoice.

AWS Savings Plans (SPs) deliver up to 72% off on-demand compute pricing in exchange for a 1-year or 3-year hourly spend commitment. Across our 340+ engagement portfolio, the typical enterprise AWS account hits 41–58% coverage when the empirically correct number sits between 72% and 88% of stable production compute. The gap is rarely a financial decision — it is a governance failure. Nobody owns the coverage number, the commitment math is opaque to procurement, and the engineers who actually choose instance types have no incentive to optimise for the financial layer.

The Savings Plans decision sits across three dimensions: term (1-year or 3-year), payment model (no upfront, partial, all upfront), and type (Compute Savings Plans, EC2 Instance Savings Plans, SageMaker Savings Plans). Each combination produces a different effective discount and a different risk profile. The default recommendation from AWS account teams is 3-year all-upfront Compute SPs, because it maximises commitment dollars and account team comp. The right answer for most enterprises is a layered mix, dominated by 1-year no-upfront with a thin 3-year base.

Compute SPs vs EC2 Instance SPs — the trade-off that matters

Compute Savings Plans apply to any EC2 family, region, OS, tenancy and Fargate/Lambda. EC2 Instance Savings Plans are scoped to a specific instance family in a specific region, and discount 6–9 percentage points deeper. The general rule: use Compute SPs for the variable layer of the production estate where instance family decisions are still being optimised. Use EC2 Instance SPs for the truly stable workloads where you know the family will not change for the duration of the term — typically the database tier, the steady-state web tier and the legacy lift-and-shifts that nobody is touching.

Below 70% SP coverage on your AWS account?

Every percentage point of uncovered baseline compute typically represents 0.5–0.8% of total cloud spend in the wrong direction.

Contact Us →
The math behind the layering

A layered Savings Plans portfolio compounds discount without locking in risk.

The simplest portfolio mistake is the all-or-nothing decision: either no SPs at all (the worst possible economics) or a single large 3-year all-upfront commitment (lowest unit cost but maximum lock-in). The optimal portfolio for most enterprises has four layers. A 3-year base of 30–45% of stable compute, sized so that even worst-case shrinkage does not produce shortfall. A 1-year mid-layer of 25–35%, refreshed annually as the baseline becomes clearer. A small partial-upfront slice if the cost of capital math supports it. And an uncommitted on-demand buffer of 12–28% absorbing growth and variance.

The blended discount this portfolio produces sits between 38% and 51% on the committed layer, with the optionality to true-down at each annual refresh without writing off any sunk commitment. Compare to a single 3-year all-upfront Compute SP at the same coverage ratio: 4–6 points deeper discount, but zero flexibility for 36 months and a cash flow impact that procurement rarely fully understands.

Payment options — the cost of capital comparison

All-upfront SPs discount 2.5–4 points deeper than no-upfront for the same term. The decision is a straight cost of capital comparison: if your effective cost of capital is below ~7–9%, all-upfront wins. If your business runs working capital tight or you are in a high-rate environment, no-upfront preserves cash and the discount delta is small. We have advised enterprises that automatically defaulted to all-upfront because the spreadsheet showed it as the lowest unit cost — without modelling the foregone return on the capital. The right answer is usually closer to partial-upfront for the long-base layer, no-upfront for the flexible layer.

Download the Cloud Contract Negotiation Framework.

Commitment sizing model, SP layering patterns, true-down rights and the negotiation timeline.

Get the playbook →
SPs and the EDP commitment

Stacking SPs against the AWS EDP — the leverage every enterprise misses.

AWS Savings Plans count toward an EDP commitment at their discounted rate, not their on-demand equivalent. This creates a structural tension that AWS account teams rarely volunteer: aggressive SP coverage reduces the dollar value of consumption applied against the EDP commit, which can push a customer into shortfall on the EDP even while saving real dollars on the bill. The practical implication is that SP strategy and EDP commitment sizing have to be modelled together, not in sequence. We have seen enterprises sign EDP commits that assumed 50% SP coverage, then optimise SP coverage to 80% and end up financially short against their own commitment.

The negotiated answer is to either size the EDP commitment with explicit assumption of high SP coverage, or to negotiate language that counts SPs at their on-demand equivalent rate for commit purposes. The second option is rare but precedented at very large commit tiers. Either way, the math has to be done before the commit number is locked, not after. Modelling those two commitments together is exactly what a structured AWS EDP negotiation forces before the number is signed.

Frequently asked questions

Questions we hear most often.

How much can Savings Plans save off the AWS bill?

Up to 72% off on-demand pricing for 3-year all-upfront Compute SPs, with typical blended portfolio discounts between 38–51% on the committed layer. Most enterprises are leaving 15–25% of total cloud spend on the table because coverage sits well below the optimal 72–88% range.

Compute Savings Plans or EC2 Instance Savings Plans?

Compute SPs for the flexible layer where instance family decisions are still optimising. EC2 Instance SPs (6–9 points deeper discount) for the truly stable workloads with predictable family requirements for the term.

Should we go all-upfront or no-upfront?

Cost of capital decides. Below 7–9% effective cost of capital, all-upfront wins. Above that, no-upfront preserves cash for a modest unit-cost trade-off. Partial-upfront is often the right middle answer for the long-base layer.

How do Savings Plans interact with an AWS EDP commitment?

SPs count toward EDP at discounted rates, not on-demand. Aggressive SP optimisation can produce EDP shortfall even while saving dollars on the bill. The two decisions have to be modelled together, not sequentially.

What coverage ratio is correct for our environment?

Empirically 72–88% of stable production compute for most enterprises. Below 70% leaves significant savings unrealised. Above 88% creates shortfall risk from normal forecasting variance.

Cloud contract on the horizon?
The commitment is the negotiation.

We have advised on cloud contracts from $2M to $120M annually across AWS, Azure and GCP. The leverage is in the structure, not the rate card.

The Compliance Brief

Weekly compliance intelligence for IT leaders.