Cloud pricing is designed to reward predictability. If you know you'll need a server running for the next year, you can tell the cloud provider in advance and they'll give you a significant discount — anywhere from 30% to 66% depending on the commitment length and payment terms.

That discount is real money. For a team spending $20,000 per month on EC2, a well-executed Savings Plan commitment could save $7,000–$10,000 per month. Over a year, that's $84,000–$120,000. The math is compelling enough that the FinOps Foundation lists commitment-based discounts as one of the top areas of cloud cost opportunity for organizations at every stage.[1]

The risk is also real. Commitments made for the wrong instance types, at the wrong time, or at the wrong coverage level create stranded reservations — you're paying for compute you're not using, which doesn't just eliminate the savings, it adds cost above what you'd have paid on-demand for actual usage. Getting this wrong is not a theoretical concern; it's the most common failure mode in cloud cost optimization programs.

The Commitment Landscape

Each major cloud provider has its own version of commitment-based discounts. AWS's options are the most complex and most commonly used.

Product Commitment Type Flexibility Max Discount
EC2 Reserved Instances Specific instance type, OS, region Low — locked to specific configuration ~60% (3-yr, all upfront)
Compute Savings Plans Dollar amount of compute per hour High — applies to any EC2, Lambda, Fargate ~66% (3-yr, all upfront)
EC2 Instance Savings Plans Instance family + region Medium — flexible size/OS within family ~72% (3-yr, all upfront)
GCP Committed Use Discounts vCPU and memory resources per region Medium — applied to any matching VM ~57% (3-yr)
Azure Reserved Instances VM series, region, term Medium — exchange/refund available ~72% (3-yr)

For most SaaS teams on AWS, the recommendation is Compute Savings Plans over EC2 Reserved Instances. The discount difference is minor, but the flexibility difference is significant: Savings Plans apply automatically across instance types, sizes, operating systems, regions, and even Lambda functions, without requiring reservation exchanges if your workload changes.

1-Year vs. 3-Year: The Term Decision

The term decision involves a straightforward trade-off: longer terms provide deeper discounts in exchange for longer-horizon confidence about your workload mix.

36%
Typical savings with 1-yr no-upfront Compute Savings Plan vs on-demand
52%
Savings with 1-yr all-upfront Savings Plan (capital commitment required)
66%
Maximum savings: 3-yr all-upfront Compute Savings Plan

For early-stage SaaS companies (<2 years of stable production infrastructure), 1-year terms are almost always preferable. Infrastructure changes during hypergrowth phases — instance types, regions, architectural refactors — mean a 3-year commitment has a high probability of becoming a stranded reservation before term completion.

For mature SaaS companies with stable infrastructure and predictable growth trajectories, the 3-year case is stronger. The incremental savings (another ~15% on top of the 1-year discount) are real, and the workload mix is unlikely to change dramatically over three years. Even in this case, start with 1-year to establish the baseline before committing to 3-year terms on the same coverage.

Upfront Payment: The Capital vs. Discount Decision

AWS Savings Plans and Reserved Instances offer three payment options: No Upfront, Partial Upfront, and All Upfront. The discount difference between No Upfront and All Upfront is approximately 15 percentage points for the same term.

The All Upfront option is essentially a discounted purchase of future compute capacity. If your company has cash on hand and uses that cash efficiently in the business, the relevant question is whether the compute discount is a better use of capital than alternative investments. For most early-stage SaaS companies, the answer is no — capital is better deployed elsewhere. The No Upfront option maintains cash flow flexibility while still capturing the majority of the reservation discount.

Starting Point Recommendation

For most SaaS teams beginning a commitment-based discount program: 1-year, No Upfront, Compute Savings Plan, covering 70% of stable baseline compute. This captures meaningful savings with no capital commitment, maximum flexibility for workload changes, and appropriate headroom for peaks and architecture evolution.

The Decision Framework

Work through these questions before making any commitment:

1
Do you have 60–90 days of utilization data?
If no: stay on-demand and collect the data first. Commitments made on guesses or peak utilization estimates are the primary cause of stranded reservations. A month or two of on-demand cost is cheaper than 12 months of a wrong commitment.
2
Is your infrastructure architecture stable for the next 12 months?
If you're planning a major container migration, provider switch, or architectural refactor, delay commitments until after that change. Compute Savings Plans absorb some workload shifts, but major architectural changes can strand reservations even with flexible savings plan products.
3
What is your stable baseline compute (not peak)?
Identify the compute that runs 24/7 regardless of traffic. This is your commitment target. Variable peak compute — handling traffic spikes, batch jobs, marketing campaign loads — should remain on-demand. Committing to peak capacity means you're paying for reserved compute that sits idle most of the time.
4
How fast are you growing?
For companies growing >50% YoY, today's baseline compute is a fraction of next year's baseline. The commitment coverage that's right today will under-cover future usage — which is acceptable (additional usage goes on-demand) but means the effective discount is lower than projected. Model the coverage ratio at your projected end-of-term usage, not current usage.
5
Cover 70–80% of stable baseline — not 100%
Leaving 20–30% on-demand handles peaks, unexpected growth, and the inevitable infrastructure changes that occur over a 12-month period. 100% coverage looks optimal in a spreadsheet but leaves no operational headroom. Stranded reservations cost more than the on-demand premium on that 20–30% buffer.

The Stranded Reservation Trap

Stranded reservations occur when the committed usage no longer matches actual usage. The most common scenarios:

  • Instance type migration: You committed to EC2 Reserved Instances for m5.xlarge instances, then migrated to m6i.xlarge for better performance. EC2 RIs are tied to specific instance types — the old RIs don't apply to the new instances. (This is why Savings Plans are generally preferred.)
  • Architecture refactor: You committed large EC2 RIs, then migrated the workload to containers on Fargate. EC2 Instance Savings Plans don't cover Fargate; Compute Savings Plans do.
  • Workload shutdown: A product line is deprecated and its compute is decommissioned, but the RI term continues for another 18 months.
  • Over-commitment: You committed to 100% of peak capacity instead of baseline, and the workload is naturally variable — you're paying for reserved capacity that's idle during off-peak hours.
The Commitment Monitoring Requirement

Purchasing commitments without ongoing utilization monitoring creates the exact stranded reservation scenarios above. Reserved Instance coverage reports need to be reviewed monthly — not at renewal time. The FinOps Foundation's coverage and utilization metrics are the standard framework for this review.

Multi-Cloud Commitment Complexity

Organizations running on multiple cloud providers face an additional layer of commitment complexity: each provider has its own commitment products, terms, and flexibility rules, and coverage decisions must be made independently for each provider's usage.

The general multi-cloud commitment strategy:

  • Optimize each provider independently based on that provider's actual usage and product offerings
  • Don't let one provider's commitment influence decisions on another — the workloads are typically independent
  • Build a unified view of total committed vs. on-demand spend across all providers to track overall FinOps performance
  • Prioritize commitment programs at providers where your spend is most stable and where the commitment products are most flexible

Frequently Asked Questions

On-demand charges per second of actual use with no commitment. Reserved Instances and Savings Plans require a 1-year or 3-year commitment in exchange for 30–66% lower hourly rates. On-demand is ideal for variable or unpredictable workloads; committed products are ideal for stable baseline compute that will run continuously. On-demand is not "wasted" money — it's flexibility you're paying for.
EC2 Reserved Instances commit to a specific instance type, OS, and region. If you change instance type or region, the RI no longer applies. AWS Compute Savings Plans commit a dollar amount of compute spend per hour and apply automatically to any EC2 instance, Lambda, or Fargate — regardless of type, OS, region, or size. Savings Plans provide similar discounts with much greater flexibility and are generally recommended for SaaS teams.
Avoid committing when: (1) your infrastructure is still changing significantly — refactors, provider migrations, or rapid scaling all risk stranding commitments; (2) you don't have 60–90 days of utilization data; (3) you're in early growth where next year's instance mix looks materially different from today. The opportunity cost of a wrong commitment is real — you're paying for something you're not using.
The standard FinOps recommendation is 70–80% of your stable baseline compute. Committing to 100% eliminates operational flexibility and creates stranded reservations when workloads change. The 70–80% target captures most of the discount while maintaining 20–30% on-demand headroom for peaks, unexpected growth, and architecture changes.
For most SaaS companies, No Upfront is preferable unless you have substantial idle cash. The All Upfront option adds ~15% savings on top of the No Upfront discount — effectively a discounted purchase of future compute capacity. If your capital is better deployed in product, sales, or other investments (common for growth-stage SaaS), the No Upfront option captures most of the savings while preserving cash flow flexibility.

References

  1. FinOps Foundation (2024). State of FinOps 2024. Reports that "managing commitment-based discounts" is the #2 FinOps challenge, with organizations citing both under-coverage and stranded reservations as top waste sources. data.finops.org
  2. AWS (2024). AWS Compute Savings Plans. Official documentation for Savings Plan terms, discount structures, and coverage rules. aws.amazon.com/savingsplans/compute-pricing
  3. AWS (2024). AWS Reserved Instance Pricing. Official documentation for EC2 RI terms, instance flexibility, and convertible RI exchange rules. aws.amazon.com/ec2/pricing/reserved-instances