Savings plans generally save you more money than reserved instances for most modern cloud workloads because they offer the same discount levels with far greater flexibility. Reserved instances lock you into a specific instance type and region, while savings plans apply automatically across a broader range of compute resources. That said, the right choice depends on how predictable and stable your workloads actually are, and many organizations benefit from using both together.
The sections below walk through how each commitment type works, where each one falls short, and how to decide which fits your situation.
How do reserved instances actually work?
Reserved instances (RIs) are a billing discount mechanism where you commit to using a specific cloud resource for a one-year or three-year term in exchange for a significant reduction in the on-demand rate. With AWS reserved instances, for example, you commit to a defined instance type, operating system, and region. In return, AWS applies the discounted rate automatically whenever a matching instance runs in your account.
There are three payment options for reserved instances: all upfront, partial upfront, and no upfront. Paying all upfront delivers the deepest discount, while no upfront preserves cash flow at a slightly lower saving. The discount compared to on-demand pricing can reach around 40 to 75 percent, depending on the term length and payment option you choose.
EC2 reserved instances come in two main forms. Standard RIs are the most restrictive but offer the highest discounts. Convertible RIs allow you to change the instance family, operating system, or tenancy during the term, at the cost of a somewhat smaller discount. Standard RIs can also be sold on the AWS Reserved Instance Marketplace if your needs change, which adds a degree of exit flexibility that convertible RIs do not offer.
How do savings plans work differently from reserved instances?
Savings plans are a commitment to a minimum level of compute spend per hour, measured in dollars, rather than a commitment to a specific resource. Instead of saying “I will use this exact instance type,” you are saying “I will spend at least $X per hour on compute.” AWS then applies the discounted rate automatically to any eligible usage up to that hourly commitment, regardless of instance family, size, region, or operating system.
AWS offers two types of savings plans. Compute savings plans are the most flexible, covering EC2, Fargate, and Lambda usage across all regions and instance families. EC2 instance savings plans are scoped to a specific instance family within a region but offer a slightly deeper discount in exchange for that narrower commitment.
This flexibility is why savings plans have largely replaced reserved instances as the default commitment strategy for teams running diverse or evolving workloads. If your engineering team migrates from one instance family to another, or scales up a containerized workload on Fargate, your savings plan discount follows automatically. With a standard RI, that same migration would leave your commitment unmatched and your discount unused.
What are the limitations of each commitment type?
Both reserved instances and savings plans carry meaningful limitations that can reduce their value if you commit without adequate planning.
Limitations of reserved instances
Standard RIs are highly inflexible. If your workload changes, the instance type you committed to may no longer match what you are running, and the discount goes to waste. Even convertible RIs require active management to exchange them when needs shift. Reserved instances also require you to think in terms of specific infrastructure attributes, which creates friction in organizations where engineering teams make rapid architectural decisions independently of finance.
Limitations of savings plans
Savings plans require you to accurately forecast your minimum hourly spend. Overcommitting means you pay for compute you do not use. Undercommitting means a portion of your workload still runs at on-demand rates. Savings plans also do not cover every AWS service. RDS database instances, Redshift, and ElastiCache, for example, fall outside savings plan coverage and still require reserved instances or separate commitments if you want discounted pricing on them.
When should you choose reserved instances over savings plans?
Reserved instances are the better choice when you are running stable, predictable workloads on services that savings plans do not cover. If your organization runs large relational databases on RDS, data warehousing on Redshift, or caching layers on ElastiCache, reserved instances remain the primary way to reduce those costs through commitment discounts.
Reserved instances also make sense for workloads that are genuinely static, where the instance type, region, and operating system will not change for the duration of the commitment. In those cases, the deeper discount from a standard RI may outweigh the flexibility advantage of a savings plan. This scenario is most common in regulated industries or legacy application environments where infrastructure change is slow and deliberate.
For teams with strong FinOps practices and reliable usage data, combining standard RIs for stable database workloads with compute savings plans for dynamic application workloads is a well-established approach to maximizing discount coverage across the full cloud bill.
Can you use reserved instances and savings plans together?
Yes, you can and often should use reserved instances and savings plans together. AWS applies both discount types simultaneously, and they do not conflict with each other. Reserved instances take priority for the specific resources they cover, and savings plans cover the remaining eligible compute spend up to your hourly commitment.
A practical combined strategy looks like this:
- Use reserved instances for stable database services such as RDS, Redshift, and ElastiCache that fall outside savings plan coverage
- Use compute savings plans to cover dynamic EC2, Fargate, and Lambda workloads where instance types or regions may change
- Use EC2 instance savings plans for instance families where usage is predictable and you want a slightly deeper discount than compute savings plans provide
- Review commitment coverage quarterly to identify gaps where on-demand spend is growing without discount coverage
Managing this combination well requires reliable usage data, clear ownership of commitment decisions, and a regular review cadence. Without those foundations, organizations tend to either undercommit and leave savings on the table or overcommit and pay for unused capacity.
How we help with cloud commitment optimization
Getting the balance between reserved instances and savings plans right is one of the more technically demanding parts of FinOps cloud cost management. At It’s Value, we help organizations build the governance, data, and decision processes needed to make commitment purchases confidently rather than reactively.
Specifically, we support you with:
- Usage analysis and commitment sizing: We analyze your actual cloud consumption patterns to identify the right commitment level, avoiding both overcommitment and undercommitment
- Coverage gap identification: We map your current reserved instances and savings plans against your full cloud spend to surface on-demand usage that should be covered by a commitment
- RI and savings plan strategy design: We help you decide which commitment type fits which workload, including services outside savings plan coverage such as RDS and Redshift
- Ongoing governance and review cadence: We establish a recurring commitment review process so your discount coverage stays aligned as workloads evolve
- Cross-cloud support: We apply the same discipline to commitment optimization on Azure and GCP, not only AWS
If you want to understand where your current commitment strategy is leaving money on the table, a FinOps Maturity Assessment is a practical starting point. Get in touch with us to discuss what that looks like for your organization.