What are AWS Savings Plans?

Read More >

AWS Savings Plan is a discount pricing model from Amazon Web Services. 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 period. In exchange, AWS charges a significantly reduced hourly rate during that time. Savings Plans are applicable to computing resources like EC2, Fargate, or 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. In short, Savings Plans use the age-old business principle of a discounted price for wholesale purchases.

For example, if an organization forecasts the cost of running its EC2 instances will be $50 per hour, it can purchase a Savings Plan for a 1-year or 3-year term and commit to paying $50 per hour. In return, AWS will charge a significantly reduced hourly rate for EC2 computing up to $50. If the organization’s hourly computing usage goes beyond $50, AWS will charge the extra usage at an on-demand rate. On the other hand, if the compute usage is less than $50/hour, the customer will still have to pay the committed amount.

AWS Savings plans types

There are two types of Savings Plans.

The Compute Savings Plan is the most flexible option. 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, size, AWS region, operating system, or tenancy.

For example, 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.

The EC2 Instance Savings Plan is less flexible but offers more savings (up to 72%). Here, users commit to using a specific instance family in a particular region regardless of instance size, operating system, tenancy, or availability zone.

Using the same 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.

How AWS Savings Plans are Used

Savings Plans are applied to compute resources after Reserved Instances (RI) are used. For example, if you have a fleet of EC2 instances and have both Reserved Instances and Savings Plans, the RIs are first applied to the EC2 usage. After that, EC2 Instance Savings Plans are applied to the remaining uncovered usage, and finally, Compute Savings Plans are applied.

For a multi-account setup, Savings Plans are first applied to the resources in the account where it was purchased. Within the account, Plans are first applied to the resource types with the highest discount potential. Any remaining Savings Plans are then shared with the rest of the accounts.

How to Purchase an AWS Savings Plan

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.

AWS customers can directly access Savings Plans from the EC2 console. However, it’s best to let AWS first analyze the current EC2 usage pattern and then come up with recommendations.

The Savings Plan recommendation is accessible from the AWS Cost Management console:

The wizard is fairly simple. It allows users to choose a Savings Plan type, specify if it’s for a linked account, select a 1-year or 3-year term, pick a payment option, and select a time window for the analysis.

As choices are made, the recommendation is automatically updated in the next section (the image below isn’t currently showing any values):

The recommendation shows the current monthly on-demand spending, the estimated monthly spending after the Savings Plan purchase, and the estimated savings made per month. From here, users can proceed to purchase the Plan.

Directly purchasing a Savings Plan is also very simple. The image below shows how you can buy an EC2 Instance Savings Plan for m5 instance class in the Singapore region for a 3-year period with no upfront payment. Here, we are also stipulating an hourly compute usage of $20.

As the image below shows, these options will cost $14,600 per month for the Savings Plan:

However, spending this money will also allow spinning up Linux or Windows EC2 instances of any size between m5.large to m5.24xlarge in the Singapore region for the same Savings Plan rate – as long as the hourly usage is within and up to $20.

AWS Savings Plan Utilization and Coverage Reports

There are two reports you can use to see how your Savings Plans are working:

  1. Utilization Report
  2. Coverage Report

Both reports are accessible from the AWS Cost Management console. And like other AWS cost-related reports, they are downloadable as CSV files.

The utilization report shows what percentage of the Savings Plans commitment is being used to cover computing services for a selected time period. It also shows the on-demand spend equivalent and the savings made compared to on-demand pricing. The report comes with a utilization graph and allows adjusting various parameters like lookback period, Savings Plan type, region, or instance family. The image below shows an empty utilization report:

The coverage report shows how much spending on eligible usage was covered by the Savings Plans within a selected time period. The image below shows an empty coverage report:

Two valuable metrics in this report are potential monthly savings and on-demand spend not covered. The latter is the eligible spend that could not be covered by either Savings Plans or RIs.

AWS Savings Plans vs. Reserved Instances

AWS Savings Plans are very similar to Reserved Instances in the sense that both offer cost-saving opportunities in exchange for long-term commitments. There are some key differences though, and one is not a replacement for the other.

Reserved Instances are applicable to the number and instance types for which they have been purchased, whereas Savings Plans are based on per hour usage. Some services like Amazon RDS can be purchased with RI but not with Savings Plan. Another key difference lies in the flexibility of moving between workload sizes. Convertible Reserved Instances allow some flexibility in terms of exchanging for new instance types, OS, and tenancy within the same region. Compute Savings Plans come with all this flexibility built-in for any region.

The table below shows a comparison between Savings Plans and Reserved Instances

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

Where AWS Savings Plans Don’t Fit

As a cost-saving pricing model, AWS Savings Plan is obviously a great choice for IT teams. However, there are use cases where it may not be the best choice.

Unlike Reserved Instances, AWS Savings Plans cannot be sold in a marketplace. Once you purchase a Plan, you have to pay its full term cost – regardless of upfront or no upfront – whether you can afford it or not. That’s why it’s important to carefully consider current and possible future workloads to see which systems can benefit from Savings Plans.

For example, your IT team may have recently rolled out a production ELK stack running on six EC2 nodes. To save cost, you purchased a Compute Savings Plan for the cluster and paid everything upfront for a 3-year term. Halfway through the term, the architects decide to move part of the setup to AWS-managed Elasticsearch service.

Now IT will not only have to pay for the managed service but also bear the cost of the Savings Plan for the remaining term if it’s not used elsewhere.

To ensure the money isn’t wasted, you can bring in other workloads under this Savings Plan including those running in Fargate. If it’s an EC2 Instance Savings Plan, the choice is limited to EC2 workloads only.

Another point to be aware of is Savings Plans are not applicable to some commonly-used AWS services. There’s no option to purchase Savings Plans for RDS instances, Redshift clusters, Amazon Elasticsearch, or ElastiCache.

Thirdly, there may be cases where instance scheduling can save more than Savings Plans. Typically, non-critical instances running in DEV, TEST, or QA environments are shut down after hours and during weekends. Applying Savings Plans to these types of instances can be costlier than scheduling.

To illustrate this, let’s say we have an m5.2xlarge EC2 instance running RedHat Enterprise Linux in the AWS Sydney (ap-southeast-2) region.

At the time of writing (2020), the on-demand pricing for this instance is $0.61/hour.

If we decide to run this instance 24×7, the on-demand cost for 1 year would be $0.61 x 24 x 365 = $5,343.60.

If we consider a convertible reserved instance with a 1-year term and upfront payment, the cost is $4,266 (using the AWS pricing calculator).

If we purchase a 1-year EC2 Instance Savings Plan with full upfront payment for a commitment to spend $0.5/hour, the total upfront cost would be $4,380 (calculated by AWS Savings Plan purchase).

This figure is slightly more than the Reserved Instance pricing and gives a rough savings of 18% over 24×7 on-demand cost.

Now, let’s say we are running the instance 12 hours per day between Monday to Friday (5 days), the on-demand cost for 1 year would be:

$0.61 x 12 x 5 = $36.6 per week and,

$36.6 x 52 weeks = $1903.20 per year.

Obviously, scheduling the instance has a clear advantage here.

Final thoughts

So, should organizations start using Savings Plans aggressively? The answer is yes and no. Yes, if the workload is predictable as continuous in the long-term, and includes components like EC2 nodes, Fargate clusters, and Lambda functions. No, if the number of EC2 instances is small, workloads are fluctuating and no usage baselines exist. It’s best to use convertible RIs in such cases and perhaps also use scheduling.

Regardless of how it is now almost a year after its release – Savings Plans are bound to change in the coming months and years as AWS expands it to other services, and adds other options to it. There is no foreseeable possibility of Savings Plans replacing RIs, so AWS customers with mature workloads may as well start building new cost optimization strategies based on both options.