AWS Reserved Instances VS Savings Plans

Amazon Web Service offers two cost-saving pricing models for its customers: AWS Reserved Instance (RI) and AWS Savings Plan. Broadly, both options enable AWS customers to save a significant amount of money from on-demand rates in exchange for long-term usage commitment. 

AWS first introduced Reserved Instances in 2009. Since then, it has gone through several changes in response to customer feedback. AWS customers have widely embraced RIs to optimize their cloud spendings. On the other hand, AWS Savings Plan was introduced in late 2019. As of 2020, most companies are yet to embrace this and often under the impression that one can replace the other. This is seldom the case and comes from a lack of understanding of what each pricing model offers, their limitations, and what use cases each is best suited for.

In this article, we will talk about both AWS Reserved Instances and Savings Plans. We will provide a high-level comparison between the two, and talk about use cases where one solution may perform better than the other. Hopefully, the concepts discussed here will help you build a cost optimization model for your organization’s AWS workload.

Price Discount Attributes

Like any business, AWS offers discounts to customers who make a long term spending commitment or pay upfront value. These discounts are typically applicable for computing or database resources like Amazon EC2, AWS Fargate, AWS Lambda, Amazon RDS, Amazon Redshift, or Amazon ElastiCache.

Discounts on these resources depend on a few properties. Some of the attributes apply to all resource types, while others are resource-specific.

The first attribute is the instance family (e.g., c5) and the instance size (e.g., 4xlarge) – together known as the instance type. AWS offers different discount levels for different instance types. Some discount options allow changing the instance size within an instance family; others allow changing the instance family itself.

The second attribute is the payment term. This is the period of time an AWS customer commits to keep paying for its cloud resource. Payment terms are usually 1-year or 3-years, although it’s now possible to purchase Reserved Instances with terms as low as 1-month. Naturally, the longer the payment term, the higher the discount.

The third attribute is the payment option. When selecting a payment term, AWS customers can make:

  • An upfront payment of the total applicable amount for the entire term and enjoy a $0 hourly rate. 
  • A partial upfront payment, in which case they still enjoy a further reduction in the discounted hourly rate.
  • No upfront payment, and pay the discounted hourly rate during the term.

The fourth attribute is the geographical scope. Sometimes a discount applies to a resource even if it’s moved between different regions. Sometimes this discount applies to any availability zone within a specific region. And sometimes, the discount may apply to a particular AZ only. The more the geographical flexibility, the less will be the discount.

The fifth attribute is tenancy. When purchasing a discounted pricing model, customers can specify whether their instance runs on a shared or a dedicated hardware host.

The sixth and final attribute is the platform running on the resource (e.g., Amazon Linux, RHEL, SuSe, Windows, etc.). Some platforms have fewer discounts than others.

Each of these attributes controls the discount applied to a resource. Some attributes are changeable after purchasing the payment plan, while others are not. However, the more restrictive and specific an attribute is, the higher the discount.

AWS Reserved Instances

With AWS Reserved Instances, customers can commit to using a specific instance type for a period of time in exchange for a discount on the hourly on-demand rate. Customers can purchase Reserved Instances for resources like EC2, RDS, Redshift, or ElastiCache. 

There are two types of Reserved Instances:

  • Standard RI
  • Convertible RI

A Standard Reserved Instance is more restrictive as it lets modify only a few attributes. For example, it’s possible to change the instance size within the same instance family as long as the platform is a supported version of bare metal Linux or Unix; however, it’s not possible to change the instance family itself. Similarly, customers can change the availability zone of regional RIs, but not zonal RIs. 

A Convertible RI is more flexible. It allows exchanging the current RI for another convertible RI with different configurations. With Convertible RIs, AWS customers can have a new RI with a different instance family, instance size, platform, tenancy, and payment option – as long as the new RI’s value is equal to or greater than the original one and runs in the same region. Convertible RIs offer slightly less discount (66%) than Standard RIs (72%) in exchange for this additional flexibility.

AWS Savings Plans 

With Savings Plans, AWS customers commit to spending a certain amount of money per hour for computing resources over a 1-year or 3-year term. In exchange, AWS charges a significantly reduced hourly rate during that time. Savings Plans apply to resources like EC2, Fargate, and Lambda.

With Savings Plan, AWS customers will benefit from a discounted hourly rate as long as the compute charges are within and up to the committed value. AWS will charge an on-demand rate for any usage beyond that commitment. 

Like Reserved Instances, Savings Plan also comes in two flavors:

  • EC2 Instance Savings Plan
  • Compute Savings Plan

And just like Standard RIs, EC2 Savings Plans are more restrictive but offer a higher discount (72%). With this model, a customer commits to spending an hourly dollar figure for a specific instance family in a particular region regardless of the instance size, operating system, tenancy, or availability zone.

Similar to Convertible RIs, Compute Savings Plans are more flexible. With this option, savings will be slightly lower (up to 66%), but users can apply it to EC2 instances, Fargate, or Lambda services for any instance family, instance size, AWS region, operating system, or tenancy. 

To give an example,  an EC2 Savings Plan purchased for c4 instance class in the AWS Frankfurt region can be applied to any instance size between c4.large (2 vCPUs, 3 GB RAM) and c4.8xlarge (36 vCPUs, 60 GB RAM) within that region, for any OS and tenancy.

Similarly, an AWS customer with a Compute Savings Plan can switch the Plan from a t3.medium instance running RHEL in the us-east-1 region to a c4.2xlarge Windows instance running in the Sydney region.

With FinOps, accountability is redefined, and it empowers product teams to manage their own usage with cloud against their own budget

Michael Fuller, Founding member of The FinOps Foundation

Some are often mistaken that FinOps is all about saving money, but it’s way more than that.

A well-architected cloud budget drives more revenue, enables product enhancements, performance, and feature release speed.

FinOps is the foundation of cross-functional collaboration between financial and technology teams, tying their business’s success hand in hand with continuously optimizing cloud infrastructure.

FinOps is still an emerging practice, but as we’ve seen the DevOps practice reach almost every niche of the Ecosystem, it is inevitable having a FinOps practitioner in every organization, as they scale and as more cloud services are consumed.

Comparing Reserved Instances and Savings Plans

Although it may seem like Compute Savings Plan is a logical next step for cost optimization, in reality, it needs more careful consideration.

For example, except EC2, each pricing model covers specific AWS resources not covered by the other. Reserved Instances do not cover AWS Fargate or Lambda, and Savings Plans do not apply to RDS, Redshift, or ElastiCache.

Another area of difference is the user’s ability to exit a pricing contract. For example, even though Standard Reserved Instances are more restrictive, customers can sell and purchase those in the AWS Reserved Instance Marketplace. Companies don’t have to be bound by a Standard RI’s contract term if it does not fit their computing needs. They can list the RI for sale, and if sold, recoup some of the original cost. Companies can also purchase Standard RIs with terms as low as one month. Without the 1-year or 3-year lock-in, the smaller terms can help reduce the costs of seasonal spikes in computing usage. Compared to this, Savings Plans cannot be sold or purchased in a marketplace.

Where Savings Plans do shine is in their automatic coverage. With RIs, AWS administrators and FinOps personnel always have to keep track of the usage. For example, let’s consider an RI that was initially purchased for a high-end system. If the system is downgraded to a smaller size, the RI will become ineffective unless exchanged for a new RI or converted to two or smaller RIs. If this does not happen, the customer will be paying for something that’s not used. To remediate this, AWS clients often use automated monitoring and governance tools.

Savings Plans don’t have this problem. When an instance’s class, size, tenancy, region, or platform is changed, existing Savings Plans will automatically adjust to provide cost-saving coverage.

The table below shows a high-level comparison between RIs and Savings Plans:

 

Compute Savings Plan EC2 Instance Savings Plan Convertible RI Standard RI
Savings over on-demand Up to 66% Up to 72% Up to 66% Up to 72%
1-year or 3-year term Yes Yes Yes Yes
Automatically apply pricing to any instance family? Yes No No No
Automatically apply pricing to any instance size? Yes Yes (within the same region) No No
Automatically apply pricing to any AWS region? Yes No No No
Automatically apply pricing to any OS or tenancy? Yes Yes No No
Automatically apply to Fargate usage? Yes No No No
Can be shared across accounts in AWS Organization? Yes Yes Yes Yes
Can be sold and purchased in a Marketplace? No No Yes No
Can benefit from EC2 instance type price reduction? Yes Yes Yes No
Available for RDS, EMR, Redshift? No No Yes Yes

Final thoughts 

As evident from the table, there is no one-size-fits-all solution here. It all depends on the current workload and the projected future workload. Here are a few points to consider:

  • It’s best to use Standard RIs for EC2 workloads that are steady, predictable, and running for a relatively long period. These workloads are usually not considered for immediate change.
  • Standard RIs will also be ideal for workloads that may be impacted by seasonal peaks, short-term projects, or planned infrastructure changes.
  • Compute Savings Plans are best suitable for workloads involving heavy use of Fargate or Lambda. This is usually the case for applications that are heavily reliant on microservices.
  • Compute Savings Plans should be considered if there is a near-future possibility of changing an existing workload’s region, operating system, or instance family.
  • For some low usage workloads, it may be worthwhile to consider scheduling for cost-saving. Such workloads are usually hosted on non-production instances that don’t need to run during off-peak hours or weekends.