AWS Reserved Instances vs Savings Plans for Compute Workloads

For compute workloads, Savings Plans are generally the stronger default, while Reserved Instances retain specific roles in capacity guarantees and the data tier. The choice depends on workload stability, infrastructure direction, and availability requirements.

Why the SP-vs-RI question is the wrong starting point

“Just tell me which one saves more” is the natural starting point, but it mistakes a rate comparison for an architecture decision. A lower rate tied to a configuration the workload leaves behind can produce a higher bill for unused commitments. The roadmap comes before the rate comparison. Assess what the workload will look like in one or three years and whether it needs a discount, a capacity guarantee, or both.

Both offer discounts for a commitment over those terms. Both also keep billing when the committed usage disappears, so neither substitutes for a dependable baseline. What separates them is the object of that commitment.

The structural difference between committing to a machine and committing to a spend rate

A Reserved Instance commits to a machine configuration, with matching rules based on attributes including instance family, size, region, operating system, and tenancy. It is a billing discount. AWS applies that discount to qualifying usage, with modification rights determined by the reservation’s type and scope. A zonal RI adds a separate benefit by reserving capacity in a specific Availability Zone.

A Savings Plan instead commits to a dollar-per-hour spend rate, and AWS automatically discounts eligible usage up to that commitment. Its subtype determines how broadly eligibility extends. No Savings Plan guarantees capacity. When both instruments cover compute, AWS applies RIs first, EC2 Instance Savings Plans second, and Compute Savings Plans last. Because one commitment depends on configuration matching and the other on eligible spend, they expose teams to different risks when infrastructure changes.

The three types of Savings Plans and two types of Reserved Instances, and what each actually locks you into

Compute Savings Plans have the broadest compute scope. They cover EC2, Fargate, and Lambda without restricting instance family, size, Availability Zone, region, operating system, or tenancy. EC2 Instance Savings Plans narrow that scope to one instance family in one region, while allowing size, Availability Zone, operating system, and tenancy to vary. SageMaker Savings Plans cover SageMaker training, real-time inferencing, batch transform, and processing across families and regions.

Standard RIs fix family, generation, operating system, and tenancy for the term, in return for the deepest RI discount. They can be sold through the AWS Reserved Instance Marketplace, which requires a US bank account and charges a service fee. Convertible RIs permit exchanges into a different family, operating system, or tenancy, provided the new reservation has equal or greater value. They cannot shrink the committed bill or be sold. Their flexibility also requires an operator to identify the mismatch and perform the exchange.

Scope adds another constraint to either RI comparison. Regional RIs apply across Availability Zones within a region and allow changes in size within a family for Linux with default tenancy. Zonal RIs bind the reservation to one Availability Zone and add reserved capacity, but do not permit size flexibility.

What the discount ceiling actually is, and what closes the gap between instruments

Standard RIs and EC2 Instance Savings Plans can reach the same maximum discount for EC2. Compute Savings Plans offer smaller discounts but cover more usage. For pure compute, that leaves little economic justification for choosing Standard RI rigidity over an EC2 Instance plan solely on the headline rate. Capacity reservation supplies a stronger reason.

The narrower EC2 Instance plan still needs high utilization to justify its advantage over a Compute plan. Otherwise, unused commitment can erase the rate difference. Payment and term choices also affect the comparison, with All Upfront delivering the deepest reduction and No Upfront preserving cash at a smaller discount. Three-year terms offer substantially deeper headline discounts than one-year terms, but require a longer forecast.

Exit options complicate that apparent bargain. Standard RIs have the Marketplace as a potential release route, while Convertible RIs cannot be sold. Savings Plans cannot be canceled, exchanged, or sold. A broader usage scope therefore provides flexibility within the commitment.

Why underutilization is the hidden cost that makes RI rigidity dangerous

An RI earns its advertised savings only when matching usage consumes the commitment. When that usage disappears, the committed cost remains, with no automatic refund. Each unused hour produces no discount benefit. A migration can therefore leave a team paying for its new infrastructure while an old reservation continues to run.

Savings Plans reduce configuration mismatch risk, but they do not eliminate underutilization. A Compute plan can follow eligible usage across families and services, yet a commitment above steady-state spend still leaves a paid gap. Flexibility has economic value because it broadens the usage that can absorb the commitment. It does not manufacture demand.

The sizing lesson applies to both instruments. Commitments should cover the predictable floor that runs regardless of traffic variation. The variable layer belongs on On-Demand or Spot. Once that floor is established, the remaining question is how much of its configuration is likely to change.

The workload characteristics that determine which instrument belongs where

Configuration stability is the first signal. A workload that has used the same family and region for more than a year, with no planned migration, is a candidate for an EC2 Instance plan or Standard RI. If its family, region, or compute service may change, a Compute plan is a better fit. An x86-to-arm64 migration illustrates the distinction because Standard RIs cannot follow the workload to the new family, while a Compute plan applies automatically to eligible Graviton instances.

Teams moving toward containers, serverless, or multiple regions should default to Compute plans because their coverage spans EC2, Fargate, and Lambda. An EC2 Instance plan can work when the roadmap stays with one family and has no changes planned. Teams that are changing their architecture or moving off AWS need to be more cautious. In that position, teams should remain on On-Demand until the architecture stabilizes and provides a dependable baseline for commitments.

Capacity requirements can override the pricing preference. Among these instruments, a zonal RI reserves actual capacity in a specific Availability Zone, while a Savings Plan supplies only a discount. A hard requirement for availability during capacity shortages therefore creates a structural case for the RI. Uncertainty about where a workload will be in 18 months points toward broader compute coverage rather than a rigid reservation, provided a stable spend baseline exists. Database workloads require a separate analysis because EC2 coverage does not extend directly to managed data services.

Why the data tier follows different rules and what changed for it in late 2025

Compute and EC2 Instance plans do not cover RDS, Aurora, ElastiCache, Redshift, or OpenSearch. Before December 2025, discounted database commitments depended on service-specific Reserved Instances or Reserved Nodes, each with its own configuration restrictions. The service boundary was decisive. Choosing a flexible compute commitment did nothing to loosen those database commitments.

AWS announced Database Savings Plans at AWS re:Invent on December 2, 2025, extending the hourly-spend model into the data tier. These plans offer one-year terms with No Upfront payment only. Eligible provisioned and serverless usage can receive discounts across nine services, with flexibility across engines, families, sizes, deployment options, and regions. Aurora Serverless v2 gained a way to get discounts that had not been available before.

Eligibility remains a substantial constraint for provisioned instances. Database plans require Gen 7+ families, leaving common families including db.t4g, db.t3, db.m5, db.r5, db.m6, and db.r6 outside their scope. A stable RDS cluster on db.m5 or db.r5 therefore remains a reservation candidate, and database RIs offer a materially higher maximum discount. An evolving Gen 7+ estate or Aurora Serverless v2 workload has a stronger case for the new plan. OpenSearch remains outside Database Savings Plans, so teams with a mix of services are likely to need both reservations and spend-rate commitments.

How shared commitments work across accounts and what changed in 2025 for multi-team organizations

In consolidated billing, RI and Savings Plan discounts historically flowed across accounts by default. One team’s commitment could consequently benefit another team’s usage, complicating chargeback and utilization tracking. Ownership and benefit did not necessarily align.

AWS made Group Sharing generally available in November 2025, giving organizations more control through groups defined with Cost Categories. Prioritized Group Sharing serves a designated group first before spilling benefits into the wider organization. Restricted Group Sharing isolates benefits within the designated group.

AWS also prohibited MSPs and resellers from sharing RI and Savings Plan discounts across multiple end customers in June 2025. Partner-purchased commitments are restricted to the relevant customer’s usage. Direct enterprise buyers are largely unaffected, while partner customers should verify the effect on their commitment economics. Better allocation controls reduce misattributed waste, but they do not replace a workload-mapped portfolio.

What a workload-mapped blended strategy looks like in practice

The practical recommendation is to build commitments in layers rather than select one instrument for the whole estate. Use Compute plans for the stable EC2 and serverless baseline when families, regions, or services may change. Use EC2 Instance plans where the family and region are predictable enough to keep utilization high. Reserve zonal Standard RIs for hard capacity requirements.

For the data tier, use service-specific reservations where Savings Plans do not apply, including common RDS families, OpenSearch, and Redshift. Use Database plans for eligible Gen 7+ workloads with evolving engine or region requirements and for Aurora Serverless v2. Eligibility must precede the discount comparison. Keep variable, unpredictable, or architecturally unstable usage outside commitments, using On-Demand or, where appropriate, Spot.

Size the combined portfolio conservatively against the steady-state floor. Track coverage and utilization in Cost Explorer, then increase commitments as confidence in the baseline grows. Coverage alone is not sufficient evidence of efficiency. A cloud cost management platform is an option for teams that want tooling to manage commitment coverage and utilization tracking across that portfolio.

For redundant Standard RIs, treat the Marketplace as a fallback and size initial commitments without assuming a sale. A sale requires active management and incurs AWS’s service fee. Usage AI’s Usage Flex Reserved Instances product purchases and owns RIs on the customer’s behalf while the provider absorbs that exposure. This shifts the commitment risk, which teams still need to understand.

What AWS's own signals say about where this is heading

AWS’s EC2 documentation describes Savings Plans as the easiest and most flexible way to save on compute and recommends them over RIs. The AWS Management Console also directs users toward Savings Plans for flexibility.

That direction does not imply RI deprecation. AWS has not deprecated RIs or signaled their imminent removal, Cost Explorer continues to generate RI recommendations, and the Marketplace remains operational. The sharing changes also improve the operating rules around both instruments.

The durable decision is therefore workload-first. A compute workload that needs room to migrate points toward a Savings Plan, while a capacity-bound workload or a stable database configuration can justify a reservation. As the products evolve, the governing question remains what the workload needs over the commitment term, namely flexibility, guaranteed capacity, or the deepest usable discount.