How To Cut Your AWS Bill With Savings Plans (and avoid some common mistakes)

* Price calculations using AWS Price List API

Savings Plans are a very effective way for AWS customers to reduce costs (more than 60% savings in some cases). Similar to Reserved Instances, Savings Plans deliver cost reductions in exchange for a long-term commitment. However, when comparing Savings Plans and Reserved Instances, there are many different dynamics to consider. These are often not clear or easy to navigate.

When does it make sense to buy Savings Plans vs. Reserved Instances? What are the trade-offs? How can you identify situations where Savings Plans are not the best option? After working with Savings Plans in many real-life situations, I’ve written this article to cover all of these important areas as well as a straightforward process I’ve used to find the best fit for specific workloads and requirements.

What are AWS Savings Plans?

AWS Savings Plans are a discount model where customers commit to spending a specific hourly amount of money for a period of time. In exchange, AWS delivers a discount on supported usage types. For example, a customer can commit to spending $1/hour for a 1-year period. AWS then identifies applicable usage every hour, throughout the commitment period, and applies a discount based on the type of usage and Savings Plan.

If you purchase Savings Plans, you have to pay for the committed dollar amount, whether your applications consume the amount of purchased AWS usage or not.

Types of Savings Plans

Compute Savings Plans are the most flexible offering, applying to EC2 Compute usage as well as Lambda Duration and Fargate Compute. They cover all EC2 instance types, tenancies and EC2 Operating Systems. For Lambda usage, Duration (GB-seconds calculated based on consumed duration and function memory allocation), Provisioned Concurrency and Duration (GBs) of Provisioned Concurrency are covered. For Fargate, Memory and vCPU usage are covered. Compute Savings Plans cover all AWS regions.
EC2 Instance Savings Plans apply only to a specific EC2 instance family (e.g. r5, c5, c5d, etc.) and applicable sizes within that family (e.g. xlarge, 2xlarge, etc.) as well as all operating systems and tenancies within a single region. This option offers better discounts compared to Compute Savings Plans. Keep in mind that EC2 Instance Savings Plans discounts are applied before Compute Savings Plans, in case you purchase both types.
SageMaker Savings Plans apply to compute usage related to Amazon SageMaker Machine Learning model development, training, deployment and inference.

Key differences (and similarities) between Savings Plans

Compute Savings Plans cover not only EC2, but also compute usage in services such as Lambda and ECS Fargate.
EC2 Instance Savings Plans only cover EC2 Compute usage for a particular instance family.
Compute Savings Plans cover usage in all regions, while EC2 Instance Savings Plans are limited to a specific region.
EC2 Instance Savings Plans offer a better discount compared to Compute Savings Plans, in exchange for less flexibility.
Both Savings Plans options for EC2 instances cover all operating systems (e.g. Windows, Linux, RHEL, etc.) and tenancy (Host, Default, Dedicated). In the case of Dedicated tenancy, Savings Plans don’t cover the $2/hr fee AWS charges per region where at least 1 Dedicated instance is deployed.

Payment Options

When you purchase any type of Savings Plans, you have to specify:

An hourly dollar amount commitment. When you specify this hourly commitment, you have to know how much this number will amount to in your monthly AWS bill or your 1-time upfront payment. Thankfully, the AWS console calculates this number for you during the purchase flow.
A commitment period (Term), which is set to either 1-year or 3-years.
Payment option: All Upfront, Partial Upfront (50% of total fee), No Upfront

The longer the commitment period, the more savings you’ll get. The same is true of the higher upfront fee option.

EC2: Comparing Savings Plans, Reserved Instances and On Demand

As you probably know, AWS offers the option to purchase EC2 Reserved Instances (here’s an article I wrote about EC2 Reserved, with price calculations and useful tips). Similar to Savings Plans, EC2 Reserved Instances offer a discount in exchange for a long-term commitment.

The following chart compares the different options related to EC2 instances for Savings Plans vs. Reserved Instances vs. On Demand.

In most cases the following is true:

EC2 Reserved Convertible costs virtually the same as Compute Savings Plans.
EC2 Reserved Standard costs virtually the same as EC2 Instance Savings Plans.

Key differences between Savings Plans and Reserved Instances

Unlike Reserved Instances, there’s no marketplace where you can sell unused Savings Plans. This means it’s particularly important to purchase the right amount of Savings Plans.
AWS applies Savings Plans pricing after Reserved Instances discounts are applied. This is a good thing, as there are many cases where RI discounts are greater.
Reserved Instance discounts are applied based on monthly usage. This means AWS will aggregate usage throughout the whole month and apply RI discounts based on the consumed compute hours throughout the month. Savings Plans apply discounts on an hourly basis, up to the purchased hourly commitment. For spikey applications, RI can often deliver better discounts throughout the whole month compared to Savings Plans (more on that below).
Savings Plans offer more flexibility compared to Reserved Instances. Prices for Compute Savings Plans are comparable to EC2 Convertible RIs, and EC2 Savings Plans are comparable to EC2 Standard RIs.

ECS Fargate: Differences between Savings Plans and On Demand

Lambda: Differences between Savings Plans and On Demand

Provisioned Concurrency Units:

Please note that Savings Plans don’t cover costs based on the number of Lambda executions, they only cover Compute costs. The results in the chart above include pricing for all dimensions, including number of requests and Compute.

SageMaker: Differences between Savings Plans and On Demand

Make sure you calculate the right hourly Savings Plans commitment

Remember that Savings Plans apply discounts based on an hourly commitment. If you have hourly usage periods that exceed your Savings Plan commitment, you will only get discounts up to your hourly Savings Plans commitment.
- AWS will not compensate for those hours with lower usage. Therefore, any hours outside that spike, with a usage lower than the hourly commitment, will result in under-utilized Savings Plans.
Calculate the appropriate amount of Savings Plans based on your hourly usage, not your monthly usage. This means getting to the right amount of Savings Plans commitment is NOT as straightforward as simply dividing the monthly spend on a particular usage type by the number of hours in a given month.

The chart below shows a situation where hourly usage fluctuates above and below the hourly Savings Plans commitment and how discounts are applied:

As you can see, any hourly usage above the commitment amount is charged at On-Demand rates (no savings) and periods of usage below the hourly commitment result in unused Savings Plans. This is why simply dividing the monthly usage by the number of hours doesn’t necessarily result in an optimal use of Savings Plans.

I’ve faced situations where applications with steep spikes in usage can result in unused Savings Plans if the hourly commitment is calculated simply as an average throughout the month.

5 Steps to choose the appropriate amount of Savings Plans commitment

Step 1 - Get All Relevant Usage Data

Getting all relevant compute usage data is the first step. The following tools will help you find it:

AWS Cost and Usage Reports. AWS generates Cost and Usage Reports approximately every 8-12 hours and puts them in an S3 bucket in your account. Reports should be configured with hourly granularity, which will result in many thousands of records. I wrote this article, which describes a solution to analyze Cost and Usage Reports using AWS Athena.
AWS Cost Explorer. AWS Cost Explorer provides a user interface to analyze your cost. In order to find usage relevant to Savings Plans first you need to enable “Hourly and Resource Level Data” from the Cost Management Settings page. Keep in mind this feature has a cost of $0.01 per 1,000 UsageRecords-month, which would result in $10 for 1 million usage records, which is a common range in many AWS accounts at the end of the month.
Savings Plans Recommendations. The AWS console has a Savings Plans Recommendations page, which displays recommendations based on historic usage. Even though this is a good starting point, I wouldn’t use it as the only source of data before making a decision.
Savings Plans Utilization. If you have already purchased an amount of Savings Plans, the Savings Plans Utilization page will give you a useful view of how they’re being utilized. If you find that Savings Plans are being under-utilized, then my recommendation would be to reconsider purchasing any Savings Plans until under-utilization is analyzed and resolved.

Identify which Usage Types are supported by Savings Plans

Once you get a list of your top compute usage types, it’s important to identify which ones can get Savings Plans discounts:

EC2 Compute: Any EC2 On Demand cost is eligible for either Compute Savings Plans or EC2 Instance Savings Plans.
Lambda: GB per second of On-Demand, Provisioned Concurrency and Provisioned Concurrency ARM executions. GB per second of Provisioned Concurrency and Provisioned Concurrency ARM.
Fargate Compute: GB/hour of Memory, vCPU/hour of Compute usage.

It’s very important to identify any steep spikes in these usage types, given that Savings Plans cover usage on an hourly basis. Given that steep usage spikes can have an impact on the monthly average usage numbers, it’s important to make sure the hourly Savings Plans commitment will not end up under-utilized.

Step 2 - Optimize your infrastructure and Applications

Before making any long term commitments, you have to make sure your applications are running optimally. Optimizing AWS infrastructure is a complex topic that requires several articles, but below are some basic and high-level steps:

Review relevant CloudWatch metrics (EC2 CPU, EC2 collectd Memory, Lambda Memory, Fargate CPU/Memory utilization, etc.) and make sure all resources are utilized properly (no over-provisioning is taking place).
Configure EC2 and ECS Auto Scaling as needed and make sure they don’t result in over-provisioned compute resources.
Enable X-Ray traces in Lambda functions and evaluate transactions that consume the most Lambda execution time (i.e. external API calls, database operations, specific code components, etc.)
Right-size based on evaluated metrics and application-level optimizations.

If achieving some optimizations would take a long time and considerable engineering resources, you can start by applying a moderate amount of Savings Plans (see next steps).

Step 3 - Compare Compute Savings Plans, EC2 Instance Savings Plans vs. Reserved Instances

For EC2 Compute usage, it’s important to have a clear picture of the different savings amounts delivered by EC2 Reserved Instances, Compute Savings Plans and EC2 Savings Plans. Even though EC2 Reserved Instances can offer better savings, the trade-off is reduced flexibility.

You can use the charts in this article to have a clear view of the savings offered by each option, including payment options and commitment term.

For Lambda and ECS usage, you can also refer to the charts in this article in order to calculate the expected amount of savings based on your usage.

Step 4 - Identify the right amount and commitment period

Identify your minimum usage for the foreseeable future - start small

You have to be careful not to buy more Savings Plans than what your applications will need in the long term. That being said, even though it would be ideal to have an infrastructure running optimally before buying Savings Plans, this is not always possible. In most cases, it’s better to start with a moderate amount of Savings Plans - preferably the minimum amount you know your applications will need in the foreseeable future, regardless of future optimizations.

Calculate the right hourly commitment

Savings Plans are measured in an hourly dollar commitment. Make sure that you commit to an amount that will cover compute costs AFTER discounts are applied. For example, if your compute costs are $1,000/month and your expected Savings Plans discounts are 20%, then an appropriate commitment would be $1.11/hour:

$1,000 x 80% (20% discount) = $800 expected monthly cost after discounts.
$800 / 720 hours (hours in a 30-day month) = $1.11 hourly commitment.

It’s relatively common to see situations where application owners mistakenly calculate the hourly commitment based on their current cost before discounts. In the example above, this would be calculating an hourly commitment using $1,000 as a starting point, which would result in a $1.39 hourly commitment (approximately $0.28/hour of over-provisioning).

Step 5 - Iterate

Optimizing cost is an ongoing process that requires iterations and constant monitoring:

Start small (don’t overcommit).
Keep monitoring Savings Plans coverage and CloudWatch metrics for applicable resources.
Optimize your compute resources.
Determine if additional Savings Plans are required.
Repeat.

To Summarize

For EC2 usage, Compute Savings Plans offer the same discounts as EC2 Reserved Instances (Convertible), in exchange for higher flexibility. In many cases, this trade-off is acceptable and recommended. EC2 Savings Plans offer similar discounts as Standard EC2 Reserved Instances, in exchange for less flexibility.
For Lambda and Fargate usage, Compute Savings Plans are the only alternative to reduce compute costs.
Savings Plans apply discounts based on an hourly commitment. Applications with usage spikes can often end up with unused Savings Plans if the hourly commitment is calculated based on average usage throughout the month.
It is recommended to start with a low hourly commitment amount compared to your compute costs, iterate, optimize and then gradually increase your Savings Plans hourly commitment. Each iteration should be based on the Savings Plans utilization data available in AWS.

Do you need help lowering your AWS cost?

Don’t overspend on AWS. If you need help lowering your AWS bill, I can save you thousands of dollars (I’ve done it time and again). Click on the button below to schedule a free consultation or use the contact form.