Most people understand that a Compute Savings Plan saves money on cloud compute. Far fewer understand the precise mechanism. And that detail matters, because getting the commitment amount wrong in either direction costs real money: too high means paying for committed hours you do not use; too low means missing available savings.
The Mechanism in One Sentence
You commit to spending a minimum hourly amount on compute. In return, AWS automatically applies discounts (up to 66% vs on-demand) to your eligible usage. The commitment is measured in dollars per hour, not specific instances.
This abstraction distinguishes Compute Savings Plans from classic Reserved Instances. You are not buying "3 m5.xlarge instances for one year." You are buying "$12/hour of AWS compute for one year, usable on any combination of EC2, Fargate, or Lambda."
How the Calculation Works Concretely
Let's take an example. Your current workload:
- 4x m5.xlarge EC2 ($0.192/h on-demand each = $0.768/h total)
- 2x c5.2xlarge EC2 ($0.34/h on-demand each = $0.68/h total)
- Fargate usage equivalent to $0.25/h
Total on-demand: $1.698/h, roughly $1,230/month (730 hours).
With a Compute Savings Plan of $1/h for 1 year, you pay:
- Commitment: $1/h × 730h = $730/month (guaranteed, whether you use it or not)
- Covered usage: $1/h of compute gets approximately 40% discount
- Excess usage: $0.698/h remains at on-demand rates
The calculation becomes: $730 (commitment) + $0.698 × 730 × 1.0 (on-demand) = $730 + $509 = $1,239/month.
Savings vs full on-demand: approximately $0 in this poorly calibrated case.
The problem here: the $1/h commitment is too low to cover most of the workload, but still consumes budget.
The Under-Commitment Trap
Many teams, out of caution, commit too low. "We don't know if we'll scale, let's commit to 50% of our current usage."
The problem: you still pay the minimum commitment even if your usage drops. If you commit to $1/h and only use $0.5/h of compute during a month, you still pay $730 in commitment.
But the real hidden cost is the missed savings. On the $0.698/h not covered, you pay full price when a higher commitment would have applied the discount.
The Over-Commitment Trap
Conversely, committing too high through optimism creates direct waste.
Imagine a $2/h commitment for the same $1.698/h workload:
- Commitment: $2/h × 730h = $1,460/month
- Actual usage covered: $1.698/h (all your compute gets the discount)
- Waste: $0.302/h × 730h = $220/month of commitment paid but unused
You save on the compute used, but lose $220/month on excess commitment. The net can be negative vs a correctly sized commitment.
The Sizing Method
In our work with engineering teams, particularly during our cloud infrastructure audits, we use this three-step approach:
Step 1: Establish the Baseline
Analyze 3-6 months of compute history. Identify:
- The hourly minimum (your incompressible baseline)
- The hourly average
- The 90th percentile hourly
AWS Cost Explorer provides this data in the "Savings Plans recommendations" view.
Step 2: Choose the Commitment Percentile
The rule of thumb: commit at your stable minimum level, not your average.
If your minimum is $0.8/h, your average $1.2/h, and your peak $2/h, a $0.8/h commitment is conservative but safe. You cover 100% of your baseline; the rest goes on-demand.
For very predictable workloads (daily batch processing, internal applications), you can commit closer to the average. For variable workloads (SaaS with unpredictable customer usage), stay close to the minimum.
Step 3: Validate with Business Projections
The commitment is for 1 or 3 years. Do your business plans change this equation?
- Cloud migration in progress? Usage will increase; commit based on post-migration projection
- Consolidation planned? Usage may drop; stay conservative
- New product launch? Wait for real data before adjusting
Compute Savings Plans vs Reserved Instances
Reserved Instances (RI) offer slightly higher discounts (up to 72% vs 66%), but with constraints:
| Aspect | Compute Savings Plan | Reserved Instance | |--------|---------------------|-------------------| | Instance flexibility | All EC2/Fargate/Lambda instances | Specific instance type and AZ | | Max discount | 66% | 72% | | Management ease | One decision: hourly amount | Per-instance-type management | | Resale | No | Yes (RI marketplace) |
For the majority of modern workloads (containerized, serverless-first), Compute Savings Plans are the better choice. The flexibility more than compensates for the 6% lower discount.
RIs remain relevant for very stable workloads on specific instance types (on-premise databases, non-containerized legacy applications).
The AI/ML Special Case
Training and inference AI workloads have specific patterns:
Training (bursty, GPU-intensive)
Model training is often sporadic: 2 intensive weeks per month, then maintenance. Savings Plans are poorly suited to this pattern. Prefer Spot Instances for training (up to 90% discount, with interruption risk).
Inference (continuous, predictable)
If you serve models in production 24/7, inference is a stable baseline. Ideal for Savings Plans. Commit at your minimum inference usage level.
Mixed Pattern
Many teams have both. Separate workloads logically:
- Inference: Savings Plan
- Training: Spot Instances + on-demand for critical jobs
Recommended Monitoring Tools
Sizing is not a one-time decision. Review quarterly.
AWS Cost Explorer
Free, integrated. The "Savings Plans recommendations" section analyzes your history and suggests commitments. Take these recommendations as a starting point, not absolute truth.
CloudHealth / Spot.io
Third-party tools with finer analysis: coverage prediction, under/over-utilization alerts, cross-cloud recommendations.
Kubecost (for Kubernetes)
If your workloads run on EKS, Kubecost attributes costs by namespace/deployment. You see which services consume your Savings Plan commitment.
Common Mistakes to Avoid
Mistake 1: Ignoring Existing Commitments
Before buying a new Savings Plan, check your current commitments (RI, old Savings Plans). AWS does not prevent over-commitment.
Mistake 2: Defaulting to 3-Year Commitment
The 3-year commitment offers a higher discount (roughly 10% more than 1-year). But 3 years is an eternity in cloud. If your roadmap includes migrations (to another cloud, to serverless), the 1-year commitment is more prudent.
Mistake 3: Forgetting Regions
Compute Savings Plans are global (all regions), but EC2 Savings Plans are regional. Verify which type you are buying.
Mistake 4: Not Reviewing
A correct commitment in January may be inadequate in July. Integrate Savings Plans review into your quarterly FinOps cycle. If you don't have an established FinOps cycle, a digital maturity audit can help you implement best practices.
Special Case: Startups and Scale-ups
The recommendations above assume relatively stable workloads. Fast-growing startups face a different challenge: their usage evolves too quickly for reliable projections.
For companies in scaling phase, we recommend:
- Commit only on the incompressible baseline (core production instances)
- Keep burst capacity on on-demand or Spot
- Review monthly, not quarterly
- Prefer No Upfront to maximize flexibility
The additional cost of this caution (roughly 10% vs an optimized commitment) is insurance against over-commitment if growth slows.
The key insight is that commitment flexibility has real value. A company that commits too aggressively and then faces a slowdown pays both the commitment overage and the opportunity cost of capital locked into unused capacity.
The FinOps Maturity Connection
Savings Plans optimization is not an isolated decision. It fits within a broader FinOps practice that includes:
Cost Allocation
Knowing which teams, products, or features consume which resources. Without proper tagging and allocation, you cannot make informed commitment decisions. If 60% of your compute comes from a product line being evaluated for sunset, a 3-year commitment would be reckless.
Forecasting
Projecting future usage based on product roadmaps, customer growth, and infrastructure plans. The better your forecasting, the more aggressive (and thus cost-effective) your commitments can be.
Optimization Feedback Loops
Regular reviews where finance and engineering jointly examine spend patterns, identify waste, and adjust commitments. Companies with mature FinOps practices save 20-30% more than those treating cloud cost as a purely finance function.
The organizations that extract maximum value from Savings Plans are those that treat cloud cost optimization as a continuous engineering discipline, not an annual budget exercise.
Pre-Commitment Checklist
Before validating a Savings Plan purchase, check these points:
- [ ] I have analyzed at least 3 months of compute history
- [ ] I have identified my stable hourly minimum
- [ ] I have verified my existing commitments (RI, old SP)
- [ ] I have consulted the product/infra roadmap for the next 12 months
- [ ] I have configured coverage alerts in Cost Explorer
- [ ] I have scheduled a review in 3 months
For a complete analysis of your cloud costs and optimization recommendations tailored to your context, explore our Discovery Sprint or review our Hermes methodology for structuring your FinOps approach.
FAQ
Can I cancel a Compute Savings Plan after purchase?
No. The commitment is firm for the chosen duration (1 or 3 years). This is why correct sizing is crucial. AWS occasionally offers adjustments for exceptional cases, but do not count on it.
Do Savings Plans apply to all AWS services?
Compute Savings Plans cover EC2, Fargate, and Lambda. EC2 Savings Plans only cover EC2. Other services (RDS, Redshift) have their own Reserved Instance programs.
How do Savings Plans interact with Spot Instances?
Spot Instances are not eligible for Savings Plans. You pay the Spot price (typically 60-90% cheaper than on-demand) without consuming your commitment. Your commitment applies first to on-demand instances.
What is the difference between "All Upfront", "Partial Upfront", and "No Upfront"?
These are payment options. All Upfront: you pay everything at the start, maximum discount. Partial: 50% at start, 50% monthly, intermediate discount. No Upfront: all monthly, minimum discount. For most companies, No Upfront offers the best balance between flexibility and savings.
Is it possible to combine multiple Savings Plans?
Yes. You can have multiple active plans simultaneously. AWS automatically applies discounts in the most advantageous order. This can be useful for gradually adjusting your commitment as your usage evolves.