AWS Savings Plans Vs. Reserved Instances: When To Use Each

AWS introduced Savings Plans about a decade after launching Reserved Instances (RIs). AWS designed Savings Plans to be more flexible than RIs, resulting in less risk of vendor lock-in, over-provisioning, or underutilizing AWS services.

Savings Plans did not replace Reserved Instances. Because each billing model is tailored to specific use cases within AWS, you can use both simultaneously. How?

This guide will explain their similarities and differences and how best to use each. Ultimately, AWS Savings Plans and Reserved Instances alone may not deliver the full savings benefits you need.

Unless, of course, they are automated, rightsized, and you can accurately pinpoint who or what's driving your AWS costs, so you can make trade-offs without sacrificing customer experience. So, we will also recommend three ways to optimize your AWS Savings Plans and Reserved Instances.

Table Of Contents

• What Are AWS Savings Plans?
• What Are AWS Reserved Instances?
• Reserved Instances Vs. Savings Plans: Similarities And Differences
• When To Use Savings Plans
• When To Use Reserved Instances

What Are AWS Savings Plans?

With AWS Savings Plans, you do not purchase actual instances but ‌commit to one or three years of On-Demand Instances at a discounted price. This discount can amount to 72% off the regular On-Demand price.

Here's a screenshot from AWS illustrating how Savings Plans work:

AWS offers three types of Savings Plans: EC2 Instance Savings Plans, Compute Savings Plans, and Amazon SageMaker Savings Plans. Each plan applies to the kind of usage they named it for. For example, Compute Savings Plans apply to AWS Lambda, Amazon EC2, and AWS Fargate usage.

Our AWS Savings Plans guide explains how these plans work and their pros and cons. We also covered how Queuing AWS Savings Plans works.

What Are AWS Reserved Instances?

AWS Reserved Instances (RIs) is a discount pricing model that enables organizations to save up to 75% on On-Demand Instances when they purchase them in advance for a fixed term of one or three years.

RIs enable you to "book" a certain amount of computing power and pay in advance. The three payment options are:

• All Up-front Reserved Instances (AURI)
• Partial Up-front Reserved Instances (PURI)
• No Up-front Reserved Instances (NURI)

We have also covered AWS Reserved Instances, the differences between On-Demand and Reserved Instances, and the pros and cons of Reserved Instances in this AWS RI guide.

So, are Reserved Instances and Savings Plans the same?

Similarities Between Reserved Instances And Savings Plans: Are AWS Savings Plans The Same As Reserved Instances?

RIs and Savings Plans both offer a similar commitment period and payment options. Some similarities include:

• AWS bills both models by the hour.
• RIs and Savings Plans are available in three payment options: all up-front, partial up-front, and no up-front.
• Convertible Reserved Instances and Compute Savings Plans offer similar savings. Standard RIs provide similar discounts to EC2 Instance Saving Plans.
• When you exceed your usage commitment during your contract period, Amazon applies its regular On-Demand pricing.

Still, each billing model is unique. It's also not possible to change to the other billing model mid-contract. So, which one do you pick?

Here are some ‌differences between both options, so you can decide which one best suits your organization.

AWS Reserved Instances Vs. Savings Plans: What Is The Difference Between AWS Savings Plans And Reserved Instances?

Savings Plans and Reserved Instances differ in flexibility, where to buy, the amount of savings for specific AWS services, and where you can apply each model's discount.

To begin with, Reserved Instances are based on the commitment to use an instance at a particular price over a specific period, while Savings Plans are based on the commitment to spend a particular dollar amount per hour over a specific period.

ProsperOps, one of our partners and a service that programmatically optimizes your AWS compute RIs and Savings Plans, created the following image to help explain some quick, key differences between Reserved Instances and Savings Plans.

Credit: ProsperOps

The following are the differences between Reserved Instances and AWS Savings Plans:

Flexibility

Compute Savings Plans offer multiple locations/regions and usage types, while Convertible Reserved Instances are assigned to a specific location/region, instance type, operating system, and tenant. You cannot change these once you've purchased RIs.

When your computing needs change, you can repurpose your Compute Savings Plans or transfer workloads across instance types regardless of operating system or tenancy. In comparison, you could use Standard Reserved Instances with various instance types. But you’d need to have a Linux OS and Default Tenancy.

You can also queue AWS Savings Plans to apply automatically at a future date rather than immediately. By scheduling Savings Plans to deploy before or after your existing subscription expires, you can avoid using more expensive On-Demand instances.

Application scope

Reserved Instances apply across Amazon EC2, Elasticsearch, Relational Database Service (RDS), and RedShift; Compute Savings Plans support Amazon EC2, AWS Fargate, and AWS Lambda. Savings Plans do not cover Amazon RDS, just as RIs do not cover Fargate for serverless applications.

Automated coverage

Savings Plans continue to apply in case of changes in your instances or infrastructure, but RIs have to be monitored continuously to ensure they are applied.

As a result, Savings Plans may offer lower management overhead than RIs.

Resell or exchange

You can resell surplus RIs or purchase additional Standard RIs from the AWS Reserved Marketplace. AWS keeps a 12% service fee.

You can also exchange your Convertible RIs to enhance your commitment without resetting your contract. AWS Marketplace does not allow you to sell or buy Savings Plans.

Potential savings amount

Reserved Instances offer higher discounts, especially over three years. The key to capturing these savings is to ensure they are not underutilized or over-provisioned. More on this later.

In the meantime, when should you use Savings Plans vs. Reserved Instances or vice versa?

When Is It Best To Use AWS Savings Plans?

Savings Plans offer flexibility, making them ideal for organizations and systems prone to usage changes. They are ideal when you:

• Want to save on compute services — not on database usage.
• Expect that your usage requirements will fluctuate significantly during the contract period. Compute Savings Plans allow exchanges between instance families, operating systems, sizes, tenancies, and regions. Yet, Savings Plans aren't as suitable for short-term usage as, for example, Spot Instances. Short-term here means: dev, build, testing, etc.
• You need a setup that automatically adapts to changes in your infrastructure without constant, manual monitoring.
• Looking for discounts for serverless use cases with AWS Fargate and SageMaker applications
• Your Amazon EC2, Fargate, and Labda usage fluctuate ‌over short periods, such as from season to season.

When Is It Best To Use AWS Reserved Instances?

Reservations are non-cancelable. So, make sure you purchase RIs when you:

• Plan to use them throughout the contract period, or at least 75% of the time.
• Use applications that require constant, "always-on" power for the better part of one to three years at a time.
• Need to extend discounted instances for databases (Amazon RDS) and compute (Amazon EC2) uses.
• You have a reasonably consistent usage pattern over an extended period.

Despite this, both AWS Savings Plans and Reserved Instances require meticulous planning. You can quickly lose potential savings by over-provisioning or under-utilizing the instances.

Think Cloud Cost Intelligence Instead

To match your computing needs, you can use Auto Scaling, Spot Instances, and rightsize RIs or Savings Plans. This also requires a great deal of planning and forecasting. But most companies cannot accurately predict future utilization because their usage patterns fluctuate. Additionally, AWS Cost Explorer struggles to predict future usage beyond 7, 30, and 60 days.

Something else. Because Cost Explorer needs historical data to calculate and make reliable purchase recommendations, it cannot calculate or make accurate recommendations if your AWS Savings Plan expired recently.

However, manually selecting the most suitable AWS instances for your needs can be time-consuming. For example, there are more than 400 EC2 instances to choose from. In addition, most AWS cost management tools estimate your needs based on the instances you have now, not on what you will need in the future.

Most cost tools struggle to link the people, processes, and products that drive AWS usage and associated costs. This makes it challenging to pinpoint where you can make trade-offs or pull strings to reduce consumption and costs without sacrificing availability, performance, or engineering velocity.

All of this makes it difficult to predict usage over several months, let alone a year or three years down the road. So, what do you do?

Three things:

1. Choose an AWS Savings Plan based on your engineering needs. Track your usage and costs for one to three months with CloudZero. With CloudZero, you can see precisely who or what is driving your AWS costs down to:

• Cost per customer/tenant
• Cost per product feature
• Cost per environment
• Cost per dev team
• Cost per deployment
• Cost per project, etc.

This cost granularity can help you identify which areas to prioritize and which ones to trade-off to lower your bill without compromising service quality.

 to see how CloudZero can help you forecast and allocate AWS costs, including cost anomaly detection.

2. You can then use ProsperOps for both RIs and Savings Plans benefits. Using real-time automation, ProsperOps programmatically blends Savings Plans and Convertible RIs to extend your multi-region, Lambda, and Fargate coverage (AWS Savings Plans) with additional term control and database coverage (Reserved Instances).

3. If you use Spot Instances for short-term workloads, you can automate switching to them when the price is right with Xosphere. Xosphere automatically switches your system back to On-Demand Instances once Spot Instances become uneconomical, in time to prevent performance issues or cost surprises.