Reserved Instances vs. Savings Plans in AWS
Committed pricing is one of the most straightforward cost levers available in AWS. Agree to use a certain amount of compute over one or three years, and AWS gives you a significant discount compared to on-demand rates. In practice, though, the choice between Reserved Instances and Savings Plans trips up a lot of teams, and getting it wrong means either leaving savings on the table or locking into commitments that no longer fit when the architecture changes.
At Absolute Ops, we evaluate these tradeoffs regularly as part of our cloud operations and cloud audit work. This post lays out how each model works, where each one fits, and how to think about combining them.
How both models work
Both Reserved Instances and Savings Plans offer discounts in exchange for a one- or three-year commitment, with options for no upfront, partial upfront, or full upfront payment. The longer the term and the more you pay upfront, the deeper the discount.
The fundamental difference is what you're committing to.
With a Reserved Instance, you're committing to a specific configuration: an instance family, an operating system, a tenancy type, and a region. You're saying "I will use this type of instance, in this region, for this duration." The specificity is what enables the highest discount rates, and it's also what creates the management overhead.
With a Savings Plan, you're committing to a spend amount per hour across eligible compute. You're saying "I will spend at least $20 per hour on compute for three years." AWS then applies the discount automatically to whatever eligible usage you're running. The commitment is financial rather than technical, which is what makes Savings Plans significantly more flexible.
Reserved Instances in detail
There are two flavors of Reserved Instances worth understanding: Standard and Convertible.
Standard RIs offer the highest discounts, up to around 72% compared to on-demand pricing. The tradeoff is that they're locked to a specific instance family, operating system, tenancy, and region. You can modify the size within the same instance family, but you can't exchange an m5 RI for a c6g. If your architecture moves away from what you've reserved, the discount stops applying and you're still paying for the commitment.
Convertible RIs reduce the discount somewhat (typically 45 to 55%) in exchange for the ability to exchange them for different instance families, sizes, operating systems, or tenancies. The exchange has to be for equal or greater value, which adds a management step, but it does give you an exit from a commitment that no longer fits your workload.
One practical advantage of Standard RIs that Savings Plans don't offer: capacity reservation. If you need a guarantee that specific EC2 capacity will be available in a specific AZ (relevant for regulated workloads or applications with strict availability requirements), Standard RIs with capacity reservation are the mechanism for that.
Reserved Instances also cover services that Savings Plans don't: RDS, Aurora, ElastiCache, OpenSearch, and Redshift all have their own RI models. If your spend on any of these services is significant and your usage patterns are predictable, those RIs are worth evaluating independently from your EC2 commitment strategy.
Savings Plans in detail
AWS introduced Savings Plans specifically to address the inflexibility problem with RIs. There are two types.
Compute Savings Plans are the most flexible commitment model AWS offers. They apply to EC2 across any instance family, any region, any operating system, and any tenancy. They also cover Fargate and Lambda, which RIs don't touch at all. If your workload runs on a mix of EC2 instances, containers on Fargate, and Lambda functions, Compute Savings Plans are the only commitment model that applies discounts across all three. The discount ceiling is slightly lower than Standard RIs, but the flexibility means the discount is far more likely to actually apply to your usage.
EC2 Instance Savings Plans sit between Compute SPs and Standard RIs. You commit to a specific instance family and region, but you retain flexibility across operating system, size, and tenancy within that family. The discount is higher than Compute SPs because of the reduced flexibility. For organizations with a stable EC2 fleet concentrated in a particular instance family and region, EC2 Instance SPs deliver meaningful savings with less management overhead than Standard RIs.
Choosing between them
The right model depends heavily on how stable your workloads are and how much architectural change you expect over the commitment period.
For stable, long-lived production workloads where the instance family and region are unlikely to change over two to three years, Standard RIs or EC2 Instance Savings Plans offer the highest return. The specificity that creates flexibility risk also enables the deepest discounts when the commitment actually matches your usage.
For environments that are evolving, whether that means migrating to newer instance generations, shifting from EC2 to Fargate or Lambda, adopting Graviton processors, or consolidating across regions, Compute Savings Plans are the safer choice. The discount applies to whatever you're running rather than requiring you to predict what you'll be running. If you move from m5 to m7i instances or shift workloads from EC2 to Fargate, the Savings Plan discount follows automatically.
For database-heavy applications, this is worth stating clearly: Savings Plans do not apply to RDS, Aurora, ElastiCache, OpenSearch, or Redshift. These services require their own Reserved Instances, evaluated separately from your EC2 commitment strategy. If those services represent significant spend and your usage is predictable, their RIs are worth prioritizing.
For multi-account AWS Organizations, the practical approach is usually a combination: Compute Savings Plans for broad EC2, Fargate, and Lambda coverage with minimal management overhead, RDS and Redshift RIs for stateful services, and targeted EC2 Instance SPs or Standard RIs for specific production workloads with stable configurations. Organizations running twenty or more accounts benefit most from this layered approach because the Compute SP discount applies automatically across accounts through the management account.
The commitment sizing question
How much to commit is at least as important as what to commit to. Overcommitting means paying for discounts on usage that doesn't materialize. Undercommitting means leaving savings on the table.
The standard guidance is to commit to 60 to 70 percent of your steady-state baseline usage, leaving the remainder on on-demand pricing for flexibility. Pull your usage data over the past 90 days, identify the consistent floor of compute usage that has been present every hour, and size your commitment to that level. AWS Compute Optimizer and Cost Explorer both provide commitment recommendations based on your historical usage that are worth reviewing before committing.
Starting more conservatively and expanding coverage as you build confidence in your utilization patterns is the lower-risk approach, particularly for teams making their first significant commitment purchase. You can always add more coverage; you can't easily exit a three-year commitment that no longer fits.
Common mistakes worth avoiding
Buying Standard RIs for workloads that change. Teams commit to m5 instances, migrate to m7i or Graviton a year later, and the RI discount stops applying while the commitment continues. If there's meaningful architectural change expected in the next 12 to 18 months, Convertible RIs or Compute SPs are the safer choice.
Managing RIs at the individual instance level rather than treating them as portfolio coverage. At scale, trying to match specific RIs to specific instances becomes an operational burden that consumes more time than the incremental savings justify. Compute SPs eliminate most of that overhead.
Neglecting database service commitments. RDS and Redshift costs are substantial in many environments, and the RI discounts for those services are significant. Teams that focus exclusively on EC2 commitment often miss meaningful savings sitting in their database tier.
Treating commitment as a one-time decision. Your usage patterns change, new services get introduced, and commitment terms expire. A quarterly review of commitment coverage and utilization keeps your strategy aligned with your actual environment rather than the one you had when you bought the commitments.
Getting the analysis right
The inputs to a good commitment strategy are your actual utilization data over a representative period, a realistic assessment of how much architectural change you expect, and a clear picture of which services represent your most stable spend. If you want help working through this analysis for your specific environment, get in touch. We run this evaluation regularly and can give you a concrete recommendation based on your actual AWS cost and usage data.
