.png)
Most AWS billing optimization conversations eventually reach the same inflection point: the team knows it is overpaying, the CFO has flagged the cloud bill, and someone needs to build a coherent argument for why committing to Savings Plans is the right move, how much it will save, and what happens if things go wrong. This is that document.
This guide covers the financial mechanics of Savings Plans, the specific ROI calculation for moving from on-demand and from expiring Reserved Instances, the scenarios where RIs still make sense, the risk framework for sizing commitments conservatively, and how to structure the business case for leadership approval. All rates: US East (N. Virginia), June 2026. Source: AWS official Savings Plans pricing (aws.amazon.com/savingsplans/pricing/).
See exactly what your Savings Plans ROI looks like in under 60 seconds. Try the Calculator for free →
The On-Demand Penalty: The Cost of Doing Nothing
On-demand pricing is AWS’s highest published rate. Every EC2 instance, Fargate task, and Lambda function running on on-demand is paying a premium for the ability to cancel at any time. For workloads that have been running continuously for months, that optionality premium is pure overpayment.
The on-demand premium versus a 1-year No Upfront Compute Savings Plan is approximately 31-66% depending on instance type and region. Source: AWS official Savings Plans pricing page. For a team spending $50,000/month on EC2 on-demand: if that spend has been stable for 60+ days with minimal fluctuation, the team is leaving $15,500-$33,000/month on the table relative to a Savings Plan covering the same compute.
The question is not whether Savings Plans save money. They do, by a verified, documented percentage, with zero infrastructure changes required. The question is: how much of your on-demand spend is stable enough to commit?
Savings Plans vs Reserved Instances: The Key Differences
Both Savings Plans and Reserved Instances are commitment-based discounts on AWS compute. The structural difference determines when each is appropriate.
| Factor | Compute Savings Plan | EC2 Instance Savings Plan | Standard Reserved Instance |
| Commitment unit | $/hr spend — no instance lock | $/hr spend, locked to instance family + region | Specific instance type, family, region, OS, tenancy |
| Max 1-yr discount | Up to 66% | Up to 72% | Up to 72% (1-yr All Upfront varies by type) |
| Max 3-yr discount | Up to 66% | Up to 72% | Up to 72% (3-yr All Upfront) |
| Services covered | EC2, Fargate, Lambda | EC2 only (specific family) | EC2 only |
| Flexibility | Highest — any region, family, OS, size | Medium — family and region locked, size flexible | Lowest — any attribute change breaks coverage |
| Capacity reservation | None | None | Zonal RIs only (not Regional) |
| Post-purchase changes | Cannot modify. 7-day refund window only. | Cannot modify. 7-day refund window only. | Standard: limited modification. Convertible: exchangeable upward. |
| Resale on Marketplace | No | No | Yes — Standard RIs can be listed for sale |
| Payment options | No Upfront / Partial / All Upfront | No Upfront / Partial / All Upfront | No Upfront / Partial / All Upfront (not all combos for 3-yr) |
| Best for | Variable compute mix, Graviton migration, EC2+Fargate+Lambda fleets | Stable instance families where extra 6pp discount is worth the family lock | Ultra-stable database-tier instances, capacity reservation needs |
Source: AWS official Savings Plans documentation (aws.amazon.com/savingsplans/), holori.com (March 2026), hyperglance.com (May 2026). Discount ranges approximate — verify at aws.amazon.com/savingsplans/pricing/ — rates change.
The ROI Calculation: On-Demand to Savings Plans
The formula
Monthly savings = (on-demand hourly spend covered by SP) x (SP discount %) x 730 hours.
Annual savings = monthly savings x 12.
Break-even: for a 1-year No Upfront Compute SP, there is no upfront payment. The savings start from the first billing hour. Break-even is instantaneous.
For a 1-year Partial Upfront: break-even is typically 3-6 months into the term, after which the combined upfront + monthly savings exceed the on-demand cost. For a 1-year All Upfront: immediate effective discount — the full year is paid upfront at the deepest discount.
Worked ROI example: engineering org at $50,000/month EC2 on-demand
Profile: 30-person engineering team, mixed EC2 fleet (m6i, c6g, r6g instances), Fargate for ECS workloads, consistent baseline spend with 30-40% fluctuation from deployments and scheduled jobs. Average stable baseline: approximately $35,000/month (70% of total on-demand spend).
Commitment: 1-year No Upfront Compute Savings Plan at $47.95/hr (= $35,000/month / 730 hrs). This covers the $35,000/month baseline. The remaining $15,000/month of variable compute runs on-demand as before.
Savings on the committed portion (31% 1-yr No Upfront Compute SP discount): $35,000 x 0.31 = $10,850/month = $130,200/year.
Upfront cost: $0 (No Upfront).
Risk: if EC2 spend drops below $35,000/month consistently, the commitment covers spend that does not exist. At 70% of a stable baseline with 30-40% fluctuation, this scenario requires the team’s EC2 spend to drop more than 30% below its 60-day average — an intentional scale-down or major infrastructure change.
Net savings year 1: $130,200 for a decision that took under an hour to execute. Source: 31% discount rate from AWS official 1-year No Upfront Compute SP pricing.
Conservative sizing rule: commit at 70-80% of your stable baseline hourly spend. The baseline is the level your EC2/Fargate/Lambda spend never drops below over the past 60 days — including overnight, weekends, and seasonal low periods. Over-committing the variable portion wastes the commitment. Under-committing leaves savings uncaptured. Source: holori.com (March 2026): ‘The practical starting point for most teams is a Compute Savings Plan covering 60 to 70 percent of your minimum baseline hourly spend, set at No Upfront on a one-year term.’
Sensitivity analysis: what if the spend drops?
The risk of a Savings Plan is paying the committed hourly rate even when actual compute usage falls below the commitment. Since Savings Plans have No Upfront options, the worst case is paying the committed monthly amount without receiving full compute value.
For the $47.95/hr commitment ($35,000/month equivalent) at a 31% discount: the effective monthly cost of the commitment in a month where the team uses only 50% of committed compute is $35,000 x (1 – 0.31) = $24,150 in committed charges + the forgone discount on the unutilized portion. In effect, the team pays the full committed amount regardless of utilization.
The correct framing: the commitment is a floor guarantee of compute cost, not a usage guarantee. If the team intends to run the compute, the commitment saves 31% on that spend. If the team’s compute disappears entirely, the commitment costs the same as on-demand on zero compute. The actual risk is stranded commitment on infrastructure that is intentionally decommissioned or migrated off EC2.
The Business Case for Migrating Away from Expiring Reserved Instances
Every Standard Reserved Instance that expires is a decision point. The natural instinct is to renew: buy another 1-year or 3-year RI for the same instance type. But for workloads that have changed — or are likely to change — RI renewal is the wrong decision.
The stranded commitment problem with Standard RIs
A Standard Reserved Instance covers one specific configuration: instance type (e.g., c5.2xlarge), region (e.g., us-east-1), operating system (Linux), and tenancy (shared). If any of these change, the RI no longer covers the running instance and you are paying both the RI commitment and on-demand rates for the new configuration.
Three infrastructure changes that commonly strand Standard RIs: (1) Graviton migration — moving from c5 or m5 to c6g or m7g voids the RI; (2) Instance family upgrade — moving from r5 to r6i or r7g for a performance improvement voids the RI; (3) Regional expansion — moving a workload from us-east-1 to us-west-2 voids the region-specific RI. Each of these is a normal part of infrastructure evolution. Each one leaves a RI commitment paying for a configuration that is no longer running. Source: holori.com (March 2026): ‘Locking into Standard RIs before a container migration or instance family transition is a common source of stranded commitment spend, and Savings Plans eliminate that risk.’
The RI-to-SP migration ROI
The migration path: when Standard RIs expire, replace them with an equivalent Compute Savings Plan commitment sized to the baseline hourly spend that the RIs were covering.
Example: a team with 10x c5.2xlarge Standard RIs in us-east-1. On-demand rate for c5.2xlarge: approximately $0.340/hr. The 10 RIs cover 10 x $0.340 = $3.40/hr of compute. With a 1-year No Upfront RI, the discount was approximately 30%.
Switching to a Compute Savings Plan at $3.40/hr commitment: the Compute SP delivers approximately 31% discount (1-yr No Upfront) versus the RI’s 30%. The savings are nearly identical — but the Compute SP also covers: any Graviton replacement (c7g, m7g) the team deploys in future, any Fargate capacity for ECS workloads, any Lambda for event-driven processing. The RI only covered c5.2xlarge in us-east-1.
For a team planning a Graviton migration in Q3 of the commitment year: the Compute SP continues covering the new c7g instances automatically. The Standard RI would have been stranded the moment the first c5 instance was replaced by a c7g.
Migration ROI: for most teams not running extremely stable, never-changing instance configurations, the Compute Savings Plan delivers equivalent or marginally better savings (31% vs 30% 1-yr No Upfront) with dramatically more flexibility. The business case is: same savings, lower risk of stranded commitment. Source: akshayghalme.com (April 2026) citing AWS official rates.
Also read: AWS Savings Plans: complete guide to types, pricing, and buying strategyÂ
Three Scenarios Where Reserved Instances Still Win
The Savings Plans argument is compelling for most compute workloads. But there are specific cases where Standard Reserved Instances remain the better choice.
Scenario 1: Capacity reservation requirements
Savings Plans guarantee a discount rate but do not reserve capacity. If your workload requires a guarantee that specific EC2 instance types will be available in a specific Availability Zone during a scale-out or disaster recovery event, only Zonal Reserved Instances provide that guarantee. Compute Savings Plans and EC2 Instance Savings Plans apply to whatever EC2 capacity is available — but during capacity-constrained events, you may not get the instance you need regardless of your commitment. Source: AWS official Savings Plans FAQ.
For teams with genuine capacity reservation requirements: purchase Zonal RIs for those specific instances. Cover the remainder of flexible compute with Compute Savings Plans. This hybrid approach captures the best of both mechanisms.
Scenario 2: Maximum discount on ultra-stable workloads
EC2 Instance Savings Plans deliver approximately 6 percentage points more discount than Compute Savings Plans for the same family-locked commitment (up to 72% vs 66%). For a workload where the instance family, OS, and region are confirmed stable for 3 years — a core database server, a legacy application with no migration plans, a production API server that has been running the same configuration for 18 months — the EC2 Instance SP’s 6pp extra discount is worth the family-level lock.
Dollar impact of the 6pp gap: at $20,000/month covered spend, 6% = $1,200/month = $14,400/year additional savings from choosing EC2 Instance SP over Compute SP. If the instance family is genuinely stable, that is a meaningful additional saving. If there is any chance of a Graviton migration, region change, or container shift, that $14,400/year is at risk of being lost entirely as stranded commitment.
Scenario 3: Database and managed service tier commitments
For RDS, ElastiCache, Aurora, DynamoDB, and other managed database services, neither Compute Savings Plans nor EC2 Instance Savings Plans apply. These services require their own commitment mechanisms: RDS Reserved Instances (specific engine, instance family, region), ElastiCache Reserved Nodes, or Database Savings Plans (for Gen 7+ managed services, 1-year No Upfront only). Source: AWS official.
The compute commitment strategy is separate from the database commitment strategy. A Compute Savings Plan covers EC2/Fargate/Lambda. The database tier requires its own analysis.
Also read: RDS Reserved Instances: engine-by-engine pricing and commitment guide
The Layered Commitment Strategy
The most efficient AWS commitment structure combines Savings Plans and Reserved Instances based on workload stability. This is the approach used by mature FinOps teams running large AWS footprints. Source: hyperglance.com (May 2026): ‘The most mature FinOps teams leverage both. Utilize AWS Reserved Instances to cover 100% of your known, fixed baseline, thereby maximizing the discount. Use AWS Savings Plans to cover the remaining flexible, floating compute usage.’
| Layer | Instrument | Coverage | Rationale |
| 1 | Compute Savings Plan | 60-80% of minimum stable compute baseline (EC2 + Fargate + Lambda combined) | Maximum flexibility. Covers the floor spend regardless of instance family changes, Graviton migration, or EC2-to-Fargate shifts. |
| 2 | EC2 Instance Savings Plan | Confirmed stable instance families (15-25% of baseline spend where family is certain) | Extra ~6pp discount for family-confirmed workloads. Applied on top of Layer 1. |
| 3 | Standard or Zonal RIs | Database-tier instances, ultra-stable workloads with capacity reservation needs | Maximum discount for guaranteed-stable configurations. Capacity reservation for Zonal RIs. |
| 4 | Database Savings Plans | RDS/Aurora/DynamoDB/ElastiCache Gen 7+ spend floor | Covers managed database services not covered by Compute or EC2 Instance SPs. |
| 5 | On-Demand / Spot | Variable peak compute, fault-tolerant batch workloads | No commitment risk. Spot for fault-tolerant batch at up to 90% discount. |
Source: layered approach from hyperglance.com (May 2026) and doit.com (June 2026). Database Savings Plans Gen 7+ requirement from AWS official. Spot discount from AWS official EC2 Spot pricing.
Also read: Multi-Cloud Savings Plan Strategy: applying this framework to AWS, Azure, and GCP simultaneously
Building the Business Case for Leadership Approval
The internal business case for Savings Plans adoption typically needs to address three questions from finance and engineering leadership: how much does it save, what is the risk, and why now.
How much does it save: the three-number executive summary
Present three numbers: (1) Current monthly on-demand spend on eligible compute. (2) Baseline hourly spend (the stable floor from 60-day CloudWatch data). (3) Annual savings at the 1-year No Upfront rate on the baseline commitment.
Example executive summary: ‘We currently spend $60,000/month on EC2, Fargate, and Lambda on-demand. Our 60-day stable baseline is $42,000/month. Committing 70% of that baseline ($29,400/month) to a 1-year No Upfront Compute Savings Plan saves 31% on that portion: $9,114/month = $109,368/year. Zero upfront cost. Implementation time: under one hour. No infrastructure changes required.’
For the remaining 30% of the baseline ($12,600/month), a conservative recommendation is to leave it on-demand for the first 6 months to validate the baseline before expanding the commitment.
What is the risk: the three failure modes
Three specific scenarios where Savings Plans do not deliver the expected savings, and the response to each:
Risk 1 — Compute spend drops below commitment. Response: size the commitment at 70% of the minimum observed 60-day baseline, not the average. This ensures the commitment is below the floor of what you have historically spent. If spend genuinely drops more than 30% below your historical minimum, that is an intentional infrastructure reduction — and the Savings Plan commitment is the smallest part of your cost concern at that point.
Risk 2 — Savings Plan becomes stranded on a service migration (EC2 to GKE, EC2 to on-premises). Response: use 1-year No Upfront terms only. The maximum exposure is 12 months of committed spend. At 31% savings, the committed rate is 69% of on-demand — still below on-demand for any EC2 you continue running. Only a total exit from EC2, Fargate, and Lambda simultaneously would make a Compute Savings Plan fully stranded.
Risk 3 — Architectural shift changes compute profile (Graviton migration, Fargate migration, Lambda migration). Response: Compute Savings Plans cover all of EC2, Fargate, and Lambda simultaneously, regardless of instance family, region, or OS. Graviton migrations are fully covered. EC2-to-Fargate migrations are fully covered. Lambda adoption is fully covered. The Compute Savings Plan is specifically designed to accommodate architecture evolution. Standard RIs are not. Source: AWS official Savings Plans concepts documentation.
Why now: the on-demand penalty clock
Every month spent on on-demand compute that meets the stability criteria for a Savings Plan is a month of paying 45-66% more than necessary. For a $42,000/month baseline, the monthly cost of inaction is $13,020-$27,720 in avoidable overpayment. Over a typical procurement and approval cycle of 60-90 days, that is $26,040-$83,160 in avoidable spend at the leadership approval table.
The urgency framing for leadership: ‘Every additional month on on-demand costs us $9,114 that a Savings Plan commitment would recover. Approving this in Q1 versus Q2 is a $27,342 difference in recovered savings before Q3 starts.’
See exactly what your Savings Plans ROI looks like in under 60 seconds. Try the Calculator for free →
The Commitment Sizing Process: Step by Step
Step 1: Pull 60 days of hourly compute spend from AWS Cost Explorer
Navigate to: AWS Cost Explorer, Usage Type Group: EC2: Running Hours + Fargate + Lambda, daily granularity, filter to the past 60 days. Export to CSV. Identify the minimum hourly spend across all days and all hours. This is your baseline floor.
Step 2: Calculate the commitment amount
Commitment = minimum 60-day hourly spend x 0.70 (conservative safety margin). This leaves 30% above the floor as uncommitted on-demand headroom.
Example: minimum hourly spend over 60 days = $42.00/hr. Commitment = $42.00 x 0.70 = $29.40/hr.
Step 3: Validate against known upcoming changes
Before purchasing, review Q2-Q4 roadmap for infrastructure changes that would materially reduce EC2/Fargate/Lambda spend: planned container migrations off EC2, major service decommissions, architectural shifts. If any planned change would reduce compute spend by more than 20%, factor that into the commitment amount.
Step 4: Purchase in AWS console
Navigate to: AWS Cost Management, Savings Plans, Purchase Savings Plan, Compute Savings Plan, 1-year term, No Upfront. Enter your calculated commitment amount ($29.40/hr in the example). The Savings Plan activates within the current billing hour and applies to all eligible compute retroactively to the start of that hour. Source: AWS official Savings Plans purchase documentation.
Step 5: Review at 6 months and expand
At the 6-month mark, pull updated CloudWatch utilization data. If spend has been consistently above the committed level, expand the Savings Plan with an additional commitment covering a higher portion of the stable baseline. The original 1-year No Upfront plan continues through its term; the new plan layers on top.
How Usage.ai Eliminates the Commitment Risk
The business case above describes the manual process for Savings Plans adoption. Usage.ai automates every step and removes the primary risk: over-commitment.
Usage.ai analyzes your historical compute spend, identifies the correct commitment level at your 60-day stable floor, and purchases Savings Plans on your behalf through billing-layer access. The platform’s Insured Flex Commitments add a buyback guarantee on every commitment purchased: if the committed spend exceeds actual compute usage because of an infrastructure change — EC2 instances decommissioned, workloads migrated to Kubernetes, or architecture shifted to Fargate — Usage.ai buys back the underutilized commitment and returns the value as cashback in real money.
This fundamentally changes the commitment decision calculus. The standard conservative advice — ‘commit at 70% of floor to hedge over-commitment risk’ — exists because over-commitment without a buyback guarantee means paying for unused discount. With a buyback guarantee, the correct commitment level is the accurate one, not the conservative one. You commit to what the data says, and if the data changes, the commitment adjusts.
The 24-hour refresh cycle ensures commitment recommendations stay current. AWS Cost Explorer refreshes coverage data every 72+ hours — a 3-day lag. At $9,000-$28,000/month in recoverable savings, a 3-day recommendation lag means $900-$2,800 of avoidable spend before the tool catches up. Usage.ai refreshes every 24 hours.
Named customers: Motive, EVGo (NASDAQ: EVGO), Blank Street Coffee, Secureframe. $91M+ in savings delivered across 300+ enterprise customers. Fee: percentage of realized savings only. $0 if Usage.ai saves nothing.
See how Usage.ai builds and executes your Savings Plans business case
Frequently Asked Questions
1. What is the business case for AWS Savings Plans?
AWS Savings Plans deliver 31-66% savings on EC2, Fargate, and Lambda compute versus on-demand with zero infrastructure changes, zero configuration lock, and zero upfront payment on 1-year No Upfront terms. For any EC2/Fargate/Lambda spend that has been stable for 60+ days, the business case is direct: commit to a consistent minimum hourly spend level, AWS reduces the effective per-unit rate automatically. The business case becomes negative only if the committed spend disappears entirely — which requires intentional infrastructure decommission, not normal usage fluctuation. Source: AWS official Savings Plans pricing.
2. What is the difference between Savings Plans and Reserved Instances?
Savings Plans commit to a $/hr spend level and apply automatically across any instance family, region, OS, or size within the covered services (Compute SP: EC2, Fargate, Lambda). Reserved Instances commit to a specific instance configuration — any change to instance type, family, region, OS, or tenancy breaks RI coverage. Savings Plans cannot be resold; Standard RIs can be listed on the AWS Marketplace. Savings Plans are better for most evolving infrastructure environments. RIs remain better for capacity reservation (Zonal RIs only), ultra-stable database-tier instances, and 3-year maximum-discount commitments on genuinely unchanging configurations. Source: AWS official, holori.com (March 2026).
3. How much can Savings Plans save?
Compute Savings Plans: up to 66% versus on-demand on a 3-year basis (1-year No Upfront: approximately 31-40% depending on instance type). EC2 Instance Savings Plans: up to 72% (family-locked). For a $50,000/month on-demand EC2 bill with $35,000/month stable baseline: a 1-year No Upfront Compute SP at 31% saves $10,850/month = $130,200/year for a commitment that takes under an hour to execute and requires $0 upfront. Source: discount ranges from AWS official Savings Plans pricing page.
4. When should I use Savings Plans vs Reserved Instances?
Use Compute Savings Plans for: variable EC2 instance mix, Graviton migrations in progress, EC2 + Fargate + Lambda combined coverage, any infrastructure where instance type or region may change in the next 12 months. Use EC2 Instance Savings Plans for: confirmed stable instance families where the extra ~6pp discount justifies family-level lock. Use Standard/Zonal RIs for: capacity reservation requirements, ultra-stable database-tier instances running the same configuration for 2+ years, 3-year maximum-discount scenarios where 3-year SP is not available. Source: hyperglance.com (May 2026), holori.com (March 2026), doit.com (June 2026).
5. What happens if I over-commit on a Savings Plan?
If your actual compute spend falls below the committed hourly level, you pay the committed amount regardless. The committed rate is the Savings Plan rate (69% of on-demand at 31% discount), not the on-demand rate. So even in an over-committed month, you are paying below on-demand for whatever compute you do run. The maximum financial exposure of over-commitment is paying the committed monthly charge for 12 months (1-year term) regardless of actual usage. Mitigation: size commitments at 70% of the minimum 60-day baseline, use 1-year No Upfront terms to minimize exposure, and use a platform with buyback guarantees for underutilized commitments. Source: derived from AWS official Savings Plans mechanics.
6. Is there a 7-day refund window for Savings Plans?
Yes. AWS provides a 7-day return window for Savings Plans purchased after November 1, 2023. Within 7 days of purchase, you can return the plan and receive a full refund of any upfront charges. After 7 days, Savings Plans cannot be modified, cancelled, or refunded. This makes the first 7 days after purchase the window to validate that the commitment was correctly sized. Source: AWS official Savings Plans documentation.
