Using AWS Savings Plan and Reserved Instances

6 min readFeb 15, 2021

More and more workloads are shifting to the cloud. This is a good thing for customers as they can benefit from greater security, reliability, and accessibility to their systems but it all comes at a cost. Most customers understand that operating in the cloud can seem expensive but when you weigh it up against on premise infrastructure it’s very competitive. There are ways, however, to make the cloud more cost effective. These are not just offerings from AWS but they are actually recommended.

These are the main ways of saving money in AWS:

Using spot instances
Scheduled shutdown of services
Reserved instances
Savings plans

Spot instances

Instead of going into detail here I will write a separate blog on using spot instances. If you want to read more you can take a look at these links:

Scheduled shutdown of services

First and foremost, schedule your services to only run when needed. Dev environments usually only need to be on during working hours, so schedule them to start and stop accordingly. This can be a difficult to set up because of dependencies between services i.e. DB servers need to be online before the frontends etc. However the cost savings that can be achieved are worth the effort.

There are a number of ways to do this. On some projects we ran targeted terraform runs on environments on a schedule controlled in the CI/CD tool we were using. On another project we used K8s scheduler to do the same thing. AWS have some info and tools to achieve this:

On a recent project our DEV account bill was around 3 times higher than production, mainly because it had 4 permanent environments and up to 14 developer environments running in it at any one time. Clearing down the developer environments each day and shutting down the 4 permanent environments brought the cost down by 60%!

Reserved instances

AWS offers RIs for users that have a predictable workload as a way of reducing cost by up to 72%. However, before you quote that headline figure to the customer there are some caveats you should consider.

There are many different ways to enter into an RI contract and all of the options have an effect on the discount applied. The longer the contract and the more you pay upfront, the better your discount.

RIs can be purchased for EC2 instances, RDS instances, ElastiCache, Redshift and Elasticsearch.

Check out the links at the bottom of this section to see the different types of RIs available and their individual merits and restrictions.

Purchasing RIs for EC2 can be a bit of a minefield due to the different types, different durations, payment plans and subsequent discount levels. There is also convertible RIs which do allow you to change the instance type and size by changing the RI itself — providing the value is greater or equal.

So to simplify it slightly:

If your EC2 workload is completely static and the instance count will never change using RIs for EC2 is going to provide the biggest discount. However, if the workload is mostly static but it could change in the future as usage increases or new features are added then Savings Plans are a better option for EC2 instances.

For RDS, however, RIs are appropriate. This is due to

the DB server is usually sized for maximum traffic as it is not easy to scale DBs without interruption and
there is no Savings Plan option for RDS at the moment.

RDS RIs are purchased in “normalised units” per hour. When purchasing RDS RIs you select the instance type you want and it calculates the amount of normalised units this equals for example a db.m5.8xlarge deployed in multi-AZ is worth 128 units. This is the same as purchasing two db.m5.4xlarge instances. In fact the recommendation from AWS is to purchase many small instances that equal the unit number required as this gives flexibility as to where these are applied. These recommendations are all available in the cost explorer in AWS console — more on that later. But the upshot is that because of this the DB server can be migrated, if needed, to a larger DB instance within the same family — db.C5.2xl can mover to a db.C5.8xl etc.

Realistically it’s going to be difficult to get customers to sign up to a rigid plan for three years paying all the capital upfront. Using the “No upfront” option and a shorter plan is more appealing. In my recent project example we purchased RIs for our production DB servers based on a 1 year commitment and no upfront payment which reduced our RDS bill from $21,164.02 to $16,157.45 (monthly) — a 23% reduction in cost.

Links:

EC2 RIs: https://aws.amazon.com/ec2/pricing/reserved-instances/
RDS RIs: https://aws.amazon.com/rds/reserved-instances/

Savings Plans

A relatively new offering from AWS are savings plans. The headline figure from AWS, up to 72% saving, again is fantastic but difficult to achieve. There are two types of savings plan:

Compute savings plans — you commit to purchase an amount of compute per hour which can be spread over EC2, Lambda and Fargate regardless of instances size, family, OS or even AWS region.
EC2 savings plans — you commit to purchase an amount of compute per hour for a family of instances in AWS (C5, M5, C5n etc). The instance size can be changed within the family C5.xl → C5.2xl but the main family must stay the same.

More than one savings plan can be purchased at the same time so you could agree to commit to $2.50 per hour of C5 instances and $1.23 per hour of M5 instances. It is possible to purchase more plans on top of others so if you were regularly spending another $1.10 on C5 instances you could enter into another plan on top of the existing one. However the two plans would have different end dates depending on when they were first deployed.

Savings plans, just like RIs, can be applied at the top level of an account org structure. They can be shared to the other accounts in the org or configured not to share if thats required. They cannot however be modified after purchase.

For maximum savings there are three year plans paid all up front. Again, getting a customer to commit to a long term agreement with a high initial investment might not be realistic. Citing my example project again we entered into a one year, no upfront plan EC2 instance plan for

$2.030/hour for C5 instances and
$0.204/hour for M5 instances

It’s very important to note that this cost is a per hour commitment. So you will be charged the amount per hour regardless of whether there are any instances online to make use of it or not.

Links:

https://aws.amazon.com/savingsplans/

Cost explorer

Within AWS’ “My Billing Dashboard” is the cost explorer. There are two separate sections in it for SPs and RIs. This is the best way to get started with the cost savings because each section has a recommendations section where you can select the duration and payment options you require and the cost explorer will recommend what to purchase based on the last 7, 30 or 60 days usage. So when you get to a point in the project where things are relatively stable you can look at these recommendations to see just what savings are available.

Two things to note here —

The savings plan recommendations are based on a very cautious algorithm as it does not want to recommend something is bought that will not be used. It’s highly likely that, if revisited after a month, there will be more savings plans that can be purchased.
If you have accounts linked that have instances that are on a schedule they will still show up in the savings plan recommendation. Only purchase the amount that will run 24 hours a day. If you dip below your commitment you will still be charged full price for the hour.

Conclusion and TLDR

Savings plans and Reserved instances are a great way of saving money but the headline percentage savings quoted by AWS are only achievable on certain instance types and over long term deals paying up front. They also only apply to certain items within AWS, its not a blanket x% off the total bill — Load balancers, EIPs, Storage, Other DB types, etc all are still charged as before.

RIs should be used for RDS and very static workloads on EC2. SPs should be used for EC2 otherwise as there is greater flexibility.

Using the cost explorer recommendations is the best place to start here once there is a stable usage pattern. In my example we were able to reduce the overall bill by around 10% by implementing the SPs and RIs as discussed above.