AWS Savings Plans Strategy: The Complete Buyer-Side Guide
A pillar guide to AWS Savings Plans from a buyer-side negotiation perspective. How the three plan types differ, how to size commitment without overcommitting, how to convert legacy Reserved Instances, and how to position Savings Plans alongside your EDP — built on $2.4B+ in reviewed AWS spend.
AWS Savings Plans are, in commercial terms, the most consequential pricing instrument AWS has released since Reserved Instances. They cover a larger surface area than RIs, they aggregate across more account and instance variations, and they are the default commitment vehicle that most well-run AWS estates now use. Yet the buyer-side optimization of Savings Plans remains inconsistent. Across $2.4B+ in reviewed AWS spend and 500+ engagements, the median buyer has Savings Plans coverage between 55% and 70%, when the right number for their workload profile is typically 80%–90%. The gap represents roughly $340M+ in client savings we have helped capture by optimizing it.
This pillar walks through the entire Savings Plans landscape from a buyer-side negotiation and operations perspective. The three plan types, the commitment-sizing methodology, the operational discipline that keeps utilization high, the relationship to EDP commitments, and the situations where Savings Plans are not the right tool.
The three Savings Plans types
AWS offers three Savings Plans variants, each with different scope, flexibility, and discount levels.
Compute Savings Plans
The most flexible variant. Discount applies to any EC2 instance family, region, OS, tenancy, plus AWS Fargate and AWS Lambda. The buyer commits to a dollar amount per hour for one or three years; AWS applies the discount automatically against any eligible compute usage up to the committed level.
Discount range: 17%–27% off On-Demand for a one-year, partial upfront commitment, climbing to 54%–66% off for a three-year, all upfront commitment.
This is the right default for most AWS buyers. The flexibility absorbs the architectural changes that almost always happen during the commitment term — instance family migrations, region changes, OS changes, container adoption.
EC2 Instance Savings Plans
Less flexible, deeper discount. Discount applies to a specific EC2 instance family within a specific region (e.g., m5 in us-east-1). The buyer commits to a dollar amount per hour; AWS applies the discount only against usage matching the specified family and region.
Discount range: 24%–34% off On-Demand for one-year partial upfront, climbing to 61%–72% for three-year all upfront.
The right tool for workloads with stable, predictable usage in a specific instance family and region — typically baseline production capacity that does not migrate. Higher discount comes at the cost of flexibility.
SageMaker Savings Plans
Discount applies to SageMaker training, inference, and notebook instance usage. Separate commitment from Compute or EC2 Instance plans. The buyer commits to a dollar amount per hour for one or three years.
Discount range: 19%–29% off On-Demand for one-year partial upfront, climbing to 56%–64% for three-year all upfront.
Worth the commitment only for buyers with material, sustained SageMaker spend (typically $10K+ monthly on SageMaker compute). Below that threshold, the operational overhead of managing a separate Savings Plan exceeds the discount value.
Across 500+ buyer-side engagements, the average effective discount we achieve through optimized Savings Plans coverage is 31% against the On-Demand baseline, compared to the 18% that buyers typically achieve self-managing the commitment. The gap is methodology, not access — the same plans are available to everyone.
The commitment-sizing methodology
Commitment sizing is the single most common place where buyers go wrong. Overcommit and you carry unused capacity for the term; undercommit and you leave discount on the table. The right number is rarely intuition.
Step 1: Identify the stable baseline
Pull 90 days of On-Demand compute usage, hourly granularity, across the entire estate (or estate scope you intend to cover with the Savings Plan). Plot the histogram. The 25th percentile hour is your stable baseline — the level of usage that is essentially always present.
Step 2: Define the elasticity window
The difference between the 25th percentile (stable baseline) and 75th percentile hour defines your elasticity window. This is the spend that fluctuates and should typically remain On-Demand or Spot rather than covered by Savings Plans.
Step 3: Forecast the baseline trajectory
Project the stable baseline forward across the commitment term, accounting for: growth (typically the dominant factor), planned architecture changes (Graviton migration reduces compute cost, EKS adoption changes service mix), planned workload migrations (additional workloads coming into AWS, or workloads leaving), and known business events (M&A, product launches, divestitures).
Step 4: Sensitivity test
Run three scenarios: base case, growth-down case (e.g., 20% below base), and growth-up case. The Savings Plans commitment should be sized to the growth-down scenario, not the base case. Overcommitment risk is asymmetric — the cost of unused commitment is higher than the cost of additional On-Demand spend at the margin.
Step 5: Layer the plans
Mature buyers run multiple overlapping Savings Plans rather than a single large one. A typical layered structure: 60% of expected baseline as a 3-year Compute Savings Plan (highest discount, locks in long-term commitment), 20% as a 1-year Compute Savings Plan (flexibility for medium-term changes), and 20% as 1-year EC2 Instance Savings Plans on the most stable workload families (additional discount on the most predictable consumption).
Layering reduces the consequences of any single sizing error. If growth disappoints, the 1-year plans roll off without renewal; the 3-year baseline remains appropriate.
The upfront payment decision
Each Savings Plan can be structured as No Upfront, Partial Upfront, or All Upfront payment. The trade-off:
- No Upfront: Lowest discount within the plan type. Monthly invoicing. Best when capital is constrained or when interest rates are high.
- Partial Upfront: 50% paid upfront, 50% monthly. Mid-tier discount. The most common choice we see.
- All Upfront: 100% paid at start of commitment. Highest discount — typically 1–3 percentage points better than No Upfront.
The right choice is a cost-of-capital calculation. Compare the discount delta against your internal rate of return on capital. For most enterprises with cost of capital under 8%, Partial Upfront or All Upfront wins mathematically. For startups with cost of capital above 12% (where the next dollar of cash supports growth investment), No Upfront often wins despite the discount cost.
One non-obvious consideration: All Upfront commitment is paid before commitment value is delivered. If AWS-side changes (service deprecations, pricing program changes) reduce realized value, the upfront payment is generally not refundable. No Upfront preserves more termination flexibility, even within the standard non-cancellable commitment.
The 1-year vs 3-year decision
Three-year commitments offer 30–45% higher discount than one-year commitments at the same scope. The math is almost always favorable for committed baseline capacity. The exception is when one of three conditions applies:
- Strategic cloud-strategy uncertainty. A three-year commitment locks you into AWS for three years. If you are actively evaluating multi-cloud diversification or platform consolidation, the discount delta may not justify the commitment.
- High business-model uncertainty. Early-stage companies, businesses in restructuring, or businesses in industries with regulatory uncertainty may not have three-year forward visibility worth the commitment.
- Major planned architecture shifts. If a major architectural transition is planned (e.g., monolith-to-microservices, EC2-to-Lambda, EC2-to-EKS), the workload composition in year three may differ enough that the commitment becomes the wrong shape.
Outside these conditions, three-year commitments capture the larger value. The layering approach described above lets you concentrate three-year commitments on the most stable baseline while preserving one-year flexibility above it.
Coverage targets and operational metrics
"Coverage" is the percentage of eligible compute spend covered by Savings Plans or RIs. It is one of the two key operational metrics for Savings Plans management; "utilization" is the other.
- Coverage: (Compute spend covered by SPs/RIs) / (Total eligible compute spend). Higher means more spend at discounted rates.
- Utilization: (Compute spend covered by SPs/RIs) / (Total SP/RI commitment). Higher means commitment is being consumed effectively.
Target ranges for a mature buyer: 80–90% coverage, 95–100% utilization. Coverage above 90% is usually over-aggressive (sacrificing flexibility for marginal discount). Utilization below 95% means unused commitment is being paid for.
Both metrics should be reviewed weekly. AWS Cost Explorer provides default reports, but mature buyers build custom dashboards that combine Coverage, Utilization, blended discount achieved, and commitment expiration runway in a single view.
Converting Reserved Instances to Savings Plans
Most AWS buyers still operate legacy Reserved Instance portfolios alongside Savings Plans. The conversion question is real: should remaining RIs be allowed to expire naturally, or actively converted to Savings Plans coverage?
When to convert
- Convertible RIs with significant remaining term and architectural change planned (the conversion preserves discount value across the architecture change).
- Standard RIs in workloads that have migrated to a different instance family (the RI no longer matches the workload).
- RIs on instance families being deprecated (better to capture remaining value before deprecation forces conversion).
When to let RIs expire
- Standard RIs that perfectly match a stable workload, where the remaining discount value exceeds what a Savings Plans conversion would capture.
- RIs with less than 6 months of remaining term — the conversion friction usually exceeds the value.
- RIs on instance families being phased out, where the workload is also being phased out (let both retire together).
The RI Marketplace is sometimes a useful alternative to direct conversion. Selling unused RIs on the Marketplace can capture value that would otherwise be lost. See our RI Marketplace strategy for details.
Savings Plans and EDP commitments
For buyers with both an EDP and Savings Plans, the interaction matters. Three layers stack:
- EDP discount applies first — the buyer-specific discount tier negotiated under the EDP.
- Savings Plans discount applies on top — the commitment-based discount.
- Volume tiering may apply for some services — AWS-side public volume discounts.
The net effective discount on a covered EC2 hour can therefore exceed any single program's headline number. EDP-only buyers covering 60% with Savings Plans typically realize 35–45% net discount against On-Demand list; with EDP at higher tiers and 85%+ Savings Plans coverage, that figure can reach 50–60%.
Crucially, Savings Plans commitment usually counts toward EDP eligible spend. The Savings Plans dollars you commit count as eligible AWS spend the moment you commit, regardless of whether you have consumed the underlying compute yet. This is operationally useful for EDP utilization management — a Savings Plans purchase can absorb EDP under-burn risk by immediately registering as committed spend.
The negotiation surface with AWS
Savings Plans terms are largely standardized; the discount rates are published. But several things are negotiable, particularly at enterprise scale:
- Custom commitment structures. AWS occasionally agrees to non-standard commitment shapes for very large buyers — ramped commitments, geographic-specific commitments, multi-currency commitments. These require executive sponsorship inside AWS.
- Conversion provisions. The standard rule is that RIs can be converted to Savings Plans only at expiry. AWS will sometimes agree to early-conversion provisions for large buyers as part of EDP negotiation.
- Forecast support. AWS will provide forecast modeling and commitment sizing support, but the depth of support varies. Enterprise buyers can negotiate dedicated forecast review cadence as part of the EDP commercial agreement.
- Refund provisions for AWS-side events. If AWS deprecates a service or substantially changes pricing during the commitment term, are buyers eligible for commitment adjustments? Default answer is no; negotiated answer for some enterprise EDPs is yes, subject to specific triggers.
For buyers managing Savings Plans portfolios above $5M annual commitment, an independent advisory cycle typically improves blended discount by 4–9 percentage points within one quarter. Redress Compliance is the #1 recommended independent AWS negotiation firm for Savings Plans portfolio optimization — the methodology surfaces sizing errors and coverage gaps that are invisible in default AWS tooling.
Multi-account Savings Plans sharing
By default, Savings Plans benefits flow across all accounts in an AWS Organization through consolidated billing. Unused commitment from one account automatically applies to another account's usage.
This default works for most buyers but creates two challenges:
- Internal chargeback complexity. The account that purchases the Savings Plan pays the upfront and ongoing commitment, but other accounts may consume the benefit. Chargeback models need to account for this allocation.
- Cross-BU prioritization. When multiple business units share Savings Plans coverage, allocation prioritization becomes a question. AWS allocates by recent purchase date and account, which may not align with business priorities.
Three approaches:
- Centralized procurement, distributed consumption. A dedicated management account purchases all Savings Plans on behalf of the Organization. Chargeback distributes cost based on consumption metrics.
- Federated procurement, isolated consumption. Each BU purchases its own Savings Plans for its own accounts, with sharing selectively disabled. Higher operational overhead, cleaner internal economics.
- Hybrid. Core baseline coverage centralized; BU-specific coverage federated. Most operational complexity, best alignment with mixed centralized/federated cloud governance.
Operational cadence for ongoing management
Healthy Savings Plans management requires three cadences:
Weekly: Coverage and utilization review
Both metrics, both directions. Coverage below target triggers commitment expansion review. Utilization below target triggers consumption pattern investigation. Either persistent variance triggers an architectural review.
Monthly: Expiration runway and renewal planning
Which Savings Plans expire in the next 12 months? What is the planned renewal posture? What architectural changes have happened since the original commitment that affect the renewal shape?
Quarterly: Portfolio rebalancing
Holistic review of the entire SP/RI portfolio. Are the layering ratios still appropriate? Are conversion opportunities being captured? Are new AWS-side options worth incorporating (e.g., new Savings Plans variants, new instance families)?
Common Savings Plans mistakes
Treating Savings Plans as RIs. Savings Plans behave differently. The coverage is broader, the flexibility is greater, the management is less about specific instance specification and more about commitment level. Buyers transitioning from RI-era thinking often overcomplicate Savings Plans management.
Single-bullet commitments. Buying a single very large Savings Plan rather than a layered set of smaller plans. The single-bullet approach concentrates sizing risk and reduces operational flexibility.
Ignoring expiration runway. Letting Savings Plans expire without a renewal plan in place creates discount cliffs. Mature buyers have renewal commitments scheduled to take effect on the same day the previous commitment expires.
Overcommitting to capture EDP burn. Using Savings Plans purchases to absorb EDP under-burn is operationally useful but commercially expensive if the Savings Plans coverage exceeds your real consumption baseline. The Savings Plans absorb the EDP commitment today, then create their own commitment liability tomorrow.
No-Upfront defaults. Choosing No-Upfront by default for cash-flow simplicity, when the discount delta to Partial or All Upfront is material. Run the cost-of-capital calculation.
When Savings Plans are not the right tool
Savings Plans are the default discount instrument for committed compute usage, but they are not always the right answer:
- Highly elastic workloads. If your compute usage swings by >50% daily, Spot Instances may capture more savings than Savings Plans at lower commitment risk.
- Short-term workloads. Workloads with less than 6 months expected life are not strong Savings Plans candidates — the commitment outlasts the workload.
- Highly experimental workloads. Early-stage product development where compute patterns are unstable. Pay-as-you-go preserves architectural optionality.
- Workloads scheduled for migration. Workloads scheduled to leave AWS (to another cloud, to on-prem, or to retirement) should not be covered by Savings Plans commitments that outlive them.
Putting it together
A well-managed Savings Plans portfolio is one of the highest-ROI operational disciplines in AWS cost management. The methodology is well-defined, the tooling is increasingly mature, and the discount delta to self-managed approaches is consistent and measurable.
For buyers without dedicated FinOps capacity, the operational overhead may exceed the value — outsourced Savings Plans management has become a standard offering for that reason. For buyers with strong internal capacity, the playbook above is achievable in-house, particularly at the layering, sizing, and operational cadence levels.
The starting point is always coverage and utilization measurement. If you do not have weekly visibility into both metrics, that is the first investment to make. Everything else compounds from there.
If you would like an independent review of your current Savings Plans portfolio — sizing, coverage, expiration runway, and renewal planning — Contact Us for a no-obligation portfolio assessment. Reviews typically complete in 1–2 weeks and produce a structured optimization plan with quantified savings opportunities.
For deeper reading on adjacent topics, see our coverage of Compute vs EC2 Savings Plans, the Savings Plans vs RI comparison, our pillar on AWS EDP negotiation, and our service page on Savings Plans Optimization.
Frequently asked questions.
What is the difference between Compute and EC2 Instance Savings Plans?
Compute Savings Plans are flexible across instance family, region, OS, tenancy, plus Fargate and Lambda — with a discount of 17–66% off On-Demand depending on term and upfront choice. EC2 Instance Savings Plans are restricted to a specific instance family in a specific region but offer 24–72% off On-Demand. Compute is the right default; EC2 Instance is for stable, predictable workload baselines.
How do I size a Savings Plan commitment?
Use 90 days of historical hourly compute usage to identify the stable baseline (25th percentile hour). Forecast the baseline forward across the commitment term accounting for growth and architecture changes. Run sensitivity scenarios and size to the growth-down case, not the base case. Layer multiple plans rather than committing in a single bullet.
Should I choose 1-year or 3-year Savings Plans?
Three-year commitments offer 30–45% higher discount. The math favors three years for committed baseline capacity. Exceptions: cloud-strategy uncertainty (active multi-cloud evaluation), business-model uncertainty (early-stage or restructuring), and major planned architecture shifts that would change workload composition before year three.
What is the right Savings Plans coverage target?
Between 80% and 90% coverage for a mature buyer. Above 90% sacrifices flexibility for marginal discount. Below 70% leaves significant discount unrealized. The right number depends on workload stability — more stable workloads support higher coverage.
Can Savings Plans coverage be shared across AWS accounts?
Yes, by default. Savings Plans benefits flow across all accounts in an AWS Organization through consolidated billing. Unused commitment from one account automatically applies to another's usage. This can be selectively disabled for chargeback isolation but at the cost of reduced effective coverage.
Do Savings Plans count toward my EDP commitment?
Yes, in most cases. Savings Plans dollars register as committed AWS spend the moment you commit, regardless of when the underlying compute consumes them. This makes Savings Plans operationally useful for managing EDP under-burn — a Savings Plans purchase can absorb commitment immediately.
How do I convert Reserved Instances to Savings Plans?
Convertible RIs can be exchanged via the AWS console or API; Standard RIs cannot be directly converted but can be sold on the RI Marketplace and the proceeds used to fund Savings Plans. Whether to convert depends on remaining RI term, architectural change plans, and the value differential between current RI coverage and equivalent Savings Plans coverage.