Reserved Instances vs. Savings Plans dive deep

The main difference between Reserved Instances and Savings Plans. When to use which, and how to use it properly!

As a Solutions Architect at AWS I see more and more requests from customers on cost optimization topic around AWS infrastructure. It is all related to the overall economic conditions and uncertainty, so it is clear that the same topic is crucial for many organizations.

I decided to take all my expertise and experience around this topic and put it into a series or reusable content on Cost Optimization, so more organizations can benefit from it and implement it by them-selfs in their organization.

My plan is to touch these topics, as they will be published I will updated links to each of them:

• Reserved instances and Savings plan - the easiest way to save costs with long-term use of AWS. This is the article you are reading now.

• Spot instances dive deep - how to use spare capacity in AWS regions for your own benefit.

• Managing capacity and right-sizing - also quite easy to implement change which can result in significant cost savings.

• Re-platforming for cost reduction - how to use modern cloud native technologies for overall IT cost reduction.

• Re-factoring for cost reduction - probably the most complex way, but also the one provides the biggest cost savings in a long-term.

• I will be updating the list and expanding it as there will be more posts on Cost Optimization topic.

Now, let’s dive deep into the first topic - Reserved instances and Savings Plan and how to master them.

Intro

Both, Reserved Instances (RIs) and Savings Plans are the ways of purchasing AWS capacity with discounted prices with pre-defined commitment from your side.

Reserved Instances were first announced in 2009 (Here is original blog post from Jeff Barr) and it was a simple model how you can commit you usage of EC2s for 1 or 3 years and get a discounted pricing for it. It was not only to address the discount part of it, but also to ensure that you have enough capacity for your-self of specific EC2s at any moment of time with discounted pricing. There were only On-Demand EC2s at the moment, so imagine the scenario when you are expecting a growth in EC2 usage and your business is dependent on it, but you also want to have a discounted pricing, so you don’t want to just “hope” that there will be enough instances, but make sure you can scale and you are willing to commit to it ahead of time.

Reserved Instances offering evolved over time, I will dive deep into the latest offering and how you can use it below in text.

But, in 2019, 10 year later, there were a substantial update providing more flexibility and now called Savings Plan (see original blog post from Jeff Barr). It was designed to provide the same discount rate as Reserved Instances, but to make it easier to purchase, so that you don’t have to coordinate RIs purchases to ensure that you have right mix of coverage for your compute needs. Also, it evolved to cover not only EC2 usage, but also other compute options introduced over time such as AWS Lambda or AWS Fargate.

So, how it can work for all these compute where pricing models are very different? Instead of committing to a specific EC2, you now can commit to a specific amount of USD per hour of compute over 1 or 3 years for which you will get discounted pricing, so at the end it aggregates the usage of all compute resources and applies discounted rates to per hour billing for the amount you committed to.

You can see Savings Plans as a “next generation” offering for Reserved Instances, so my default recommendation is to use Savings Plans if your specific requirements doesn’t require Reserved Instances as it provides you with more flexibility. Reserved Instances still have their place and use-cases, so I will explore them below, but I will start with Savings Plan as it is the most flexible and should be a default choice for majority of the cases.

There are similarities between them:

• Both Savings Plans and Reserved Instances can be purchased for 1 or 3 years.

• You can pay monthly (no upfront), partially upfront (the rest monthly), and all upfront.

• You get bigger discount for longer commitment.

• You get bigger discount if you pay upfront.

• When you need to scale up over your commitment, then you pay On-Demand pricing.

Now, let’s take a closer look on each of them and how do they differ one from another.

Savings Plans

First, it goes in 3 main flavours:

• Compute Savings Plans - to cover all compute running on EC2, AWS Lambda and Fargate across all supported AWS Regions with savings up to 66%.

• EC2 Instance Savings Plans - to cover specific EC2s in selected AWS Region with greater savings up to 72%.

• SageMaker Savings Plans - to cover ML instances within Amazon SageMaker across all supported AWS Regions with savings up to 64%.

As you can see, it provides different discounts and have several options within each. As before, the more specific you are with your usage and longer commitment you are willing to apply - the greater discount you are getting.

Keep in mind that this can be applied only to Compute, so you won’t be able to apply it for DB services such as RDS. For RDS and some other you still have to use Reserved Instances.

Compute Savings Plans

It applies to your EC2 usage regardless instance family, size, region, AZ, OS or tenancy and also applies to Lambda and Fargate usage.

So, it is great when you are committed to use AWS for your compute, but you are not sure where exactly it will run.

Example of use-case Compute Savings Plan is the most suitable for is - you are doing lift & shift of your application from on-prem. to AWS and running it on EC2, then you decided to switch to another EC2 family and size, then few month later you are going to put your application into container and run it on Fargate, and later you are working on splitting the application and running these pieces as Lambda functions so it can scale independently and so on…

Keep in mind that you are committing the hourly $ usage, but the final discount for the resource it-self will be calculated based on:

• EC2 - AWS Region, EC2 instance type, size, OS and tenancy.

• Fargate - AWS Region, OS, CPU Architecture.

• Lambda - AWS Region.

The greatest discount you will get for EC2 (up to 66%), then Fargate (up to 52%), and then Lambda (up to 17%).

But if you need to scale beyond what you purchased in Savings Plan? Then you will just pay on-demand prices for everything over committed hourly $ amount.

But how it really calculates? I found it the most complex and a bit confusing for customers, so let’s see on the example:

• You committed to spent $1 hourly with 3 year commitment All Upfront, so you will pay them anyway, but if you will take c5.xlarge instances in Ireland region, now instead of paying $0.192 for On-demand, so you can have 5 c5.xlarge for $1 hourly, you are going to pay only $0.096 (50% discount) for the same instance, so you will be able to run 10 same c5.xlarge for the same $1.

• Then, if you need to scale over these 10 c5.xlarge for $1, you will have to pay On-Demand pricing, so for the next $1 per hour you will get only 5 c5.xlarge.

EC2 Instance Savings Plan

It works in similar way compare to Compute Savings Plan for EC2, It provides greater discount compare to Compute Savings Plan, but more restrictive, so you should better know in advance which instance family and in which AWS Region you want to use in a long-term.

It offers up to 72% of discount, but you have to commit not only to $ amount per hour, but also AWS Region and EC2 Instance Family (e.g. c5 or m5). So, if you want a mix of AWS Regions or EC2 Instance family you will have to make several Savings Plan purchases. Then, within AWS Region and EC2 Instance family the discount will be applied to any AZ, size, OS, or tenancy up to the committed $ amount.

For comparison with Compute Savings plan price-wise you can take c5.xlarge I used in previous example, and with 3 year All Upfront commitment in Ireland it provides 63% discount ($0.072 per hour) vs. 50% for Compute Savings plan. But again, you are restricted to use only this instance type and only in Ireland region.

Ideal scenario for it is when you have a steady workload, you already optimized it in terms of Instance Family (e.g. you know that it has best price/performance ratio with C5 EC2s), you don’t plan to use Fargate or Lambda for it, so you want to get greater discount for it.

Machine Learning Savings Plan

It works in very similar manner as Compute Savings Plan, so you just define $ amount per hour spent, and then it automatically applies different discounts for different SageMaker ML instances regardless or AWS Region, Instance family, size, and OS.

It provides up to 64% discount, so maximum discount is 2% smaller compare to Compute Savings Plan 🙂 But the trick is, that Compute Savings Plan can’t be applied to SageMaker ML instances, so if you work with SageMaker a lot, e.g. using SageMaker Real-Time Inference for your ML models, then you have to purchase separate ML Savings Plan for the discount.

Following our example with C5 there is an ml.c5.xlarge-Hosting for Hosting ML models, where you will get 50% discount ($0.1152 vs. $0.23 On-demand) in Ireland with 3 year commitment All Upfront.

Ideal scenario here is quite obvious and self-explanatory - use it if you are working with SageMaker or you have dedicated team/teams, want to benefit from discounted pricing and still have some flexibility.

Reserved Instances - RI

“Legacy” option for discounting EC2s, but still used a lot, because it provides some additional options for application compare to Compute Savings Plan.

Mostly it is more restrictive compare to Compute Savings Plan, but for some cases I describe below only RIs can be used.

It also has additional feature heavily used by large enterprises called “Capacity Reservation”. Basically, when you are purchasing RI and defining specific AZ, then it reserve the capacity for you in this specific AZ, so you can be sure you won’t run out of capacity in case of scale out. If you don’t specify AZ, then RI is applied to any EC2 matching the rest of the attributes in any AZ in the AWS Region, but then you don’t have any reserved capacity for you. I saw this feature is used a lot for events such as Black Friday, Super Bowl, and during Christmas time by various e-commerce clients to ensure they can scale enough to support the demand when there is natural possibility of shortage in specific EC2 instances.

Also, great benefit of RIs is that it can be used by other services which are using EC2 behind, here is the list:

• Relational Database Service (RDS)

• ElastiCache

• Redshift

• OpenSearch

If you want to apply discount to any of these services or want capacity reservation, you basically don’t have any other choice except RIs. This is what I meant at the beginning by saying that by default I always recommend Compute Savings Plan, and only for specific cases I recommend Reserved Instances.

Also, great thing is that you can sell/buy your reserved instances on the Marketplace if you want to. I will not go deep into it, so check it out here you are interested in it.

But, as RIs evolved over time, there were some additional features added, so now RIs for EC2s are in 2 flavours:

• Standard RI - provides you need to specify Term (1y or 3y), AWS Region, AZ (optional - only for capacity reservation), EC2 specification where you can’t change Instance family (e.g. c5 or m5), OS, tenancy, payment option (upfront, partial, no upfront). You still can change AZ, Instance size (e.g. xlarge to 2xlarge), networking type (e.g. VIF or ENA).

• Convertible RI - same as Standard RI + you can change instance family (e.g. c5 or m5), OS, tenancy and payment option. Keep in mind, that you can change only to other Convertible RIs of equal or greater value in $.

So, ideal use-case where I recommend to use it is only when you need capacity reservation for some special events, or if you want to apply it to RDS, ElastiCache, Redshift, or OpenSearch services.

Conclusion

It really depends on your use-case which one is better to use, but I always recommend at least to consider using them if you know that you are going to use AWS at least the next year. I strongly believe that at least Savings Plans needs to be included into any Cost Savings strategy. Be cautious though to not overcommit, and if you are struggling to define what is the best approach for your specific use-case feel free to DM me and I can help you with that!

I prepared a cheat sheet table which summarises all options available today which you can find below.