AWS offers two primary commitment instruments for reducing compute costs: Reserved Instances (RIs) and Savings Plans. Both offer discounts of 30–60% compared to on-demand pricing in exchange for a one- or three-year commitment. Both are purchased upfront, partially upfront, or with no upfront payment. And both are genuinely confusing to finance teams evaluating them for the first time.
The confusion is understandable. The pricing structures are complex, the terminology is inconsistent between AWS documentation and common usage, and the right choice depends on details about your architecture that may not be visible to finance without input from engineering.
This article gives you the framework to evaluate and decide — or at least to ask the right questions.
What you’re actually buying
At the core, both RIs and Savings Plans are financial instruments. You’re making a commitment to AWS in exchange for a discount on future compute usage. The economics are simple: if you’re going to use a certain amount of compute anyway, paying for it in advance (or committing to pay for it) is cheaper than paying on-demand.
The difference is in what you’re committing to.
Reserved Instances are a commitment to a specific EC2 instance type in a specific region. When you purchase a 1-year Reserved Instance for an m5.xlarge in us-east-1, you receive a discount on any usage of that instance type in that region. If your usage pattern changes — you migrate to a different instance family, or reduce your usage below the reservation level — you’re paying for capacity you’re not using.
Savings Plans are a commitment to a dollar amount of compute spend per hour, not to a specific instance type. A Compute Savings Plan applies to any EC2, Lambda, or Fargate usage, regardless of instance family, size, region, or operating system. A more flexible instrument, but with slightly lower maximum discount rates.
The practical implication: Reserved Instances give better discounts but require more precise forecasting. Savings Plans are more forgiving of architectural changes but cap your discount potential.
The three questions to answer before buying anything
1. What is your on-demand baseline?
Commitment instruments only make sense for stable, predictable workloads. The right starting question isn’t “how much Reserved Instances should we buy” — it’s “what portion of our compute spend is reliably recurring, month over month?”
Spiky or unpredictable workloads should stay on on-demand or use Spot Instances (discussed separately). Only the stable baseline is a candidate for commitment.
Look at your EC2 spend over the past six months and identify the floor — the minimum usage that occurred every month regardless of traffic patterns. That’s your commitment candidate.
2. What is your architectural stability horizon?
Commitments are 1-year or 3-year. The question is: how confident are you that your current architecture will be stable for that period?
If your engineering team is planning significant changes — migrating to containers, switching database types, adopting serverless — those changes will affect which commitment instruments are appropriate. A 3-year reservation on an instance type you’re planning to move away from in 18 months is not a savings, it’s a liability.
The general rule: use Savings Plans if you have meaningful architectural uncertainty. Use Reserved Instances only if you have high confidence in workload stability.
3. What is your AWS billing structure?
Reserved Instances and Savings Plans apply to usage within your AWS account or organization. If you have multiple accounts under an AWS Organization, commitments purchased at the management account level can apply to usage across all member accounts. This is called “consolidating billing” and it significantly increases the pool of usage that commitments can cover.
Organizations without a consolidated billing setup may be purchasing commitments that are too narrow to be fully utilized, or missing opportunities to apply commitments across accounts.
The discount math
At current AWS pricing, the approximate discount ranges:
| Commitment type | Term | Payment | Discount vs. on-demand |
|---|---|---|---|
| Savings Plan (Compute) | 1-year | No upfront | ~20–30% |
| Savings Plan (Compute) | 1-year | All upfront | ~30–40% |
| Savings Plan (Compute) | 3-year | All upfront | ~50–60% |
| Reserved Instance (Standard) | 1-year | All upfront | ~35–40% |
| Reserved Instance (Standard) | 3-year | All upfront | ~55–65% |
These are approximate ranges that vary by instance type, region, and operating system. The point is not the exact numbers but the relationship: 3-year all-upfront commitments offer dramatically higher discounts than 1-year no-upfront.
The question for finance is: what is the right point on this spectrum given your cash flow position, your architectural confidence, and your actual utilization history?
Organizations with strong cash positions and high architectural stability should evaluate 3-year all-upfront commitments aggressively — the savings are substantial. Organizations with tighter cash flow or more architectural uncertainty should start with 1-year Savings Plans and build utilization history before making larger commitments.
The utilization trap
The most common commitment purchasing mistake is buying more than you need.
When you purchase a Reserved Instance or Savings Plan, you’re committing to pay for a certain amount of compute regardless of whether you use it. If your actual usage falls below the commitment level, you’re paying for idle capacity.
This is called “commitment underutilization,” and it’s surprisingly common. Organizations that purchase reservations based on peak usage rather than baseline usage, or that don’t account for workload migration and deprecation, often find themselves with significant underutilized commitments by year two.
AWS Cost Explorer shows your current commitment utilization rate. The target is 90%+ utilization. Anything below 80% is a signal that you have over-committed relative to your current usage and may be paying more for commitments than you’re saving.
What finance should own vs. what engineering should own
The purchase decision should be a joint exercise, but the responsibilities are distinct.
Engineering owns:
- Which instance types are in use and what their stability horizon looks like
- Planned architecture changes that would affect workload patterns
- Utilization data from CloudWatch and Cost Explorer
- Recommendations on which workloads are suitable for commitment
Finance owns:
- The commitment term and payment structure decision (1 vs. 3 year, upfront vs. monthly)
- The total commitment level relative to forecast baseline
- Ongoing monitoring of utilization rates
- The business case for any purchase above a defined threshold
In practice, many organizations treat Reserved Instance and Savings Plan purchases as purely engineering decisions. This is a mistake. These are multi-year financial commitments that need finance involvement, governance, and ongoing oversight — not just a one-time technical purchase.
A practical starting point
If your organization hasn’t systematically evaluated commitment instruments, the starting point is:
- Pull your EC2 and Fargate spend from Cost Explorer for the last 6 months
- Identify your on-demand baseline (usage that occurs every month)
- Check your current commitment utilization rate
- Have engineering identify any planned workload changes in the next 12–18 months
- Model the savings for 1-year Compute Savings Plans at 80–90% of your identified baseline
That last step is conservative by design. Better to start with a smaller commitment that is fully utilized than a larger one that isn’t. You can purchase more commitments as you build confidence in your baseline.
CostDefender analyzes your commitment coverage, identifies baseline usage eligible for commitment, and quantifies the savings opportunity — giving finance and engineering the shared data needed to make the decision together.