What AWS Commitment Discounts Actually Are
AWS offers two commitment-based discount models for compute: Reserved Instances and Savings Plans. Both reduce costs by 30-65% compared to on-demand pricing in exchange for a 1-year or 3-year usage commitment. Choosing the wrong model — or defaulting to Reserved Instances out of habit because the team has used them for years — leaves money on the table and limits your ability to change instance types as workloads evolve.
This post explains the difference between the two models, when each applies, and the decision framework we use when helping mid-market teams optimize their AWS commitment strategy.
The Core Difference
Reserved Instances (RIs) commit to a specific instance type in a specific region. A Standard RI for m6i.xlarge in us-east-1 gives you a discount specifically on m6i.xlarge usage in us-east-1. If you change to m6i.2xlarge, the RI discount no longer applies. Convertible RIs allow instance type changes but at a lower discount rate.
Savings Plans commit to a dollar amount of compute usage per hour, not to a specific instance type. The two relevant types for most mid-market teams:
- Compute Savings Plans: Apply to EC2, Lambda, and Fargate usage regardless of instance family, region, or operating system. Maximum flexibility, 66% maximum discount.
- EC2 Instance Savings Plans: Apply to a specific instance family in a specific region, but allow size flexibility within the family. Higher discount rate (up to 72%) than Compute Savings Plans.
The Four-Question Decision Framework
Question 1: How stable is your instance type selection?
If your core compute workloads have been running on the same instance types for 12 or more months with no anticipated changes, EC2 Instance Savings Plans or Standard RIs provide the highest discount rate and are worth the reduced flexibility.
If you are actively migrating instance types — moving from previous-generation instances to current-generation, evaluating ARM-based Graviton instances, or running workloads on Fargate — Compute Savings Plans are the correct choice. The flexibility to change instance families without losing the discount is worth the 5-8% lower discount rate.
Question 2: Which services are you optimizing for?
If your commitment optimization covers EC2 only: all three models (Standard RI, Convertible RI, EC2 Instance Savings Plan, Compute Savings Plans) are relevant.
If your commitment strategy needs to cover EC2 plus Lambda and Fargate: only Compute Savings Plans apply. Standard and Convertible RIs and EC2 Instance Savings Plans have no effect on Lambda or Fargate costs.
For mid-market companies running significant serverless workloads alongside containers, defaulting to Compute Savings Plans simplifies the commitment strategy considerably — one commitment type covers the entire compute footprint.
Question 3: What is your coverage target?
A common mistake: committing to cover 100% of average compute usage. If your workload has any variance, 100% coverage means you will have unused commitments during low-usage periods — commitments you pay for regardless of whether you use them.
The practical target for most mid-market workloads: commit at 60-70% of your 30-day minimum compute usage. This ensures full utilization of commitments even during traffic troughs. Cover the remaining 30-40% with on-demand pricing. For workloads with predictable peaks, Scheduled Reserved Instances can cover predictable high-usage windows.
Question 4: What is your term preference?
1-year commitments provide 30-45% discounts (depending on model and payment option) with annual flexibility to adjust as your workload evolves. 3-year commitments provide 50-65% discounts but lock in your compute commitment for three years.
For 50-200 person companies with workloads that are growing or changing: 1-year commitments are almost always the right choice. The additional 15-20% discount from a 3-year term is not worth the risk of being over-committed if workload composition changes significantly.
Payment Options and Cash Flow
Each commitment model offers three payment options: All Upfront (highest discount), Partial Upfront (moderate discount), and No Upfront (lowest discount within the model). The discount difference between All Upfront and No Upfront is typically 5-8%.
For mid-market companies with positive cash flow and no immediate capital constraints, All Upfront on a 1-year term maximizes ROI. For companies where committing $50,000-$100,000 in upfront payment would create cash flow pressure, No Upfront on a 1-year term still delivers most of the discount benefit with zero cash commitment.
The Recommended Starting Point for Most Mid-Market Teams
For a company with mixed compute including EC2, Lambda, and Fargate, no specific instance type commitment needed, and 1-year planning horizon: 1-year Compute Savings Plans at No Upfront, covering 65% of your 30-day minimum hourly compute usage.
This configuration: - Delivers 50-60% discount on committed usage - Applies across EC2, Lambda, and Fargate automatically - Preserves instance type flexibility - Requires no ongoing management — Savings Plans apply automatically to eligible usage
Once you have 12 months of stable usage data and your instance type selection is stable, evaluate whether EC2 Instance Savings Plans for your core instance family would improve the discount rate meaningfully enough to justify the reduced flexibility.
Common Mistakes
Committing based on current-month peak usage. Commit at your 30-day minimum, not your average or peak. Unused commitments generate no value.
Buying instance-specific RIs before assessing Graviton migration. AWS Graviton (ARM) instances offer 20-40% better price-performance than equivalent x86 instances for many workloads. Committing to x86 instance RIs before evaluating Graviton creates a lock-in problem when the migration becomes attractive.
Treating RI/SP purchasing as an annual event. AWS usage baselines change as you grow. Review your commitment coverage quarterly — ideally through a cost explorer report that shows your on-demand spend as a percentage of total compute spend.
Frequently Asked Questions
Can we mix Savings Plans and Reserved Instances? Yes. Savings Plans and RIs stack. AWS applies RI discounts first, then Savings Plans to remaining usage. Most teams with existing RI inventory gradually transition to Savings Plans as their RIs expire.
What happens if we over-commit on Savings Plans? You pay for the committed hourly spend regardless of actual usage. There is no way to cancel or reduce a Savings Plan after purchase. This is why committing at 60-65% of minimum usage rather than average usage is important.
Do Savings Plans work for EKS workloads? Yes. EKS workers are EC2 instances, so Compute Savings Plans and EC2 Instance Savings Plans apply. Fargate-based EKS pods are covered by Compute Savings Plans only.
How do we model our Savings Plan opportunity before purchasing? AWS Cost Explorer has a built-in Savings Plan recommendation tool that models your potential savings based on your last 30 days of usage. It is reliable for steady-state workloads. For workloads with significant recent growth, model at 70% of the recommended commitment to account for usage that does not yet appear in the historical baseline.
If you want a reviewed commitment strategy before your next purchasing decision, we offer a free AWS commitment review for mid-market engineering teams.
