Reduce your AWS bill with Savings Plans

Michael Wittig – 26 Nov 2019

We are getting used to consuming compute capacity on-demand. The pay-per-use model is an essential benefit of the cloud. However, the cloud provider has to build data centers and buy hardware in advance. Doing so requires capacity planning and upfront investments. Therefore, the cloud provider must add the resulting costs to the on-demand price.

Reducing costs

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

However, you might not need the flexibility of on-demand capacity. Therefore, AWS offers the following deals since 2009:

  • You commit to a monthly usage of compute capacity, AWS grants a discount on the on-demand price.
  • You pay for compute capacity upfront, AWS grants a discount on the on-demand price.

Overall, AWS offers a discount of up to 75% on the on-demand price for EC2 instances. That’s a huge opportunity to reduce your AWS bill.

What are Savings Plans?

AWS made a prominent announcement on November 6th, 2019: AWS Savings Plans. It was never easier to get a discount on compute capacity by committing to a monthly consumption and paying upfront.

Starting from Billing and Cost Management Dashboard, you can purchase a savings plan.

AWS calculates recommendations for purchasing savings plans based on historical usage. Unfortunately, that feature does not work with AWS accounts that are linked to AWS Organizations right now.

Let me explain the example illustrated in the following screenshot:

  • Commitment to pay for at least USD 10 per hour for compute usage. Not matter if you are using that much compute capacity at all.
  • Pay USD 87,600.00 upfront for a year of compute usage.

Purchase Savings Plans

Fine, but what about the discount? In our example, the discount is applied to USD 10 per hour of compute usage. The official Pricing with Savings Plans page lists the price for Amazon EC2 instances and AWS Fargate. The following table contains some pricing examples for Linux on shared tenancy in US West (N. California).

Resource Type On-Demand Rate Savings Plans Rate Discount
m5a.xlarge $0.202 $0.163 19%
m5.large $0.112 $0.09 20%
m5a.large $0.101 $0.081 20%
c5.large $0.106 $0.078 26%
r5.metal $6.72 $4.544 32%
m2.2xlarge $0.55 $0.259 53%

Interestingly, the savings plans discount in US West (N. California) varies from 19% to 53% depending on the instance type. Discounts vary between regions, as well. Keep in mind that the granted discount depends on the term of your commitment as well as on how much you are paying up front.

Overall, the savings plans discounts vary between 10% and 72%.

It is essential to mention that there are two options when purchasing a savings plan:

  • Compute Savings Plans apply to your compute usage within all regions, among all EC2 instances, as well as containers running on Fargate.
  • EC2 Instance Savings Plans apply to EC2 instances of a specific instance family (e.g., m5) in a particular region only.

I will discuss the differences in more detail later.

Why are Savings Plans a big deal for containers on AWS?

Up until now, AWS Fargate offered on-demand pricing only. The following table shows the surcharge you had to pay for running a workload with 2 vCPU and 8 GiB memory on Fargate compared to running on EC2 in US West (N. California).

EC2 (On-Demand) EC2 (Reserved)*
20% 70%

*: Standard reserved instance with a 1-year term and all upfront payment.

Therefore, running steady workloads on AWS Fargate was not competitive.

Fortunately, that changed with the announcement of AWS Savings Plans. AWS Savings Plans apply not only to EC2 but to Fargate as well.

AWS Savings Plans grant a discount of 15% to 52% for AWS Fargate, depending on the region, term length, and upfront payment.

With a savings plan on a 1-year term and all upfront payment, the surcharge for Fargate compared to AWS is now competitive especially, if you keep in mind that you typically need to overprovision a cluster of EC2 instances running your container workload.

EC2 (Reserved) *
34%

*: Standard reserved instance with a 1-year term and all upfront payment.

In short, when you are running containers on AWS Fargate, you should buy a savings plan covering your baseline capacity.

Reserved Instances vs. Savings Plans

As I mentioned at the beginning, it was possible to commit to a monthly usage of compute capacity since the early days of AWS. The pricing option was and is called Reserved Instances.

Reserved Instances (RI) are available in different versions:

⚠️ = requires modifying the reservation

Type + Scope Standard + AZ Convertible + AZ Standard + Region Convertible + Region
Discount πŸ’°πŸ’° πŸ’° πŸ’°πŸ’° πŸ’°
Region flexibility ❌ ❌ ❌ ❌
AZ flexibility ⚠️ ⚠️ βœ… βœ…
Instance type flexibility ⚠️ ⚠️ βœ… βœ…
Instance family flexibility ❌ ⚠️ ❌ ⚠️
Capacity reservation βœ… βœ… ❌ ❌

Next, have a look at the two different versions of Savings Plans.

Type Compute EC2 Instance
Discount πŸ’° πŸ’°πŸ’°
Region flexibility βœ… ❌
AZ flexibility βœ… βœ…
Instance type flexibility βœ… βœ…
Instance family flexibility βœ… ❌
Capacity reservation ❌ ❌

So, Savings Plans offer more flexibility compared to Reserved Instances. However, the discount on the on-demand price is the same. The following table compares the discounts for an EC2 instance of type m5.large with Linux operating system on shared tenancy in US West (N. California) with a 1-year term and all upfront payment.

Discount
Compute Savings Plan 20%
Reserved Instance Convertible 20%
EC2 Instance Savings Plan 30%
Reserved Instance Standard 30%

A diagram says more than a thousand words.

Comparing Savings Plans and Reserved Instance options

It does not make sense to buy Reserved Instances any more as Savings Plans offer more flexibility for the same discount on the on-demand price.

Do I need Capacity Reservations?

As mentioned in the previous section, Reserved Instances with scope AZ come with a capacity reservation. However, there is no such option with Savings Plans.

Do you need a capacity reservation? What happens in the rare case of an outage affecting an availability zone (AZ)? The pressure on the remaining AZs increases as customers replace their affected resources. Most likely, there will not be enough capacity in the remaining AZs to do so. Sooner or later, you will see Not enough capacity errors and are not able to launch any new EC2 instances anymore. Unless you have a capacity reservation.

So depending on your workload and RTO (Recovery Time Objective), you need a capacity reservation. Luckily, AWS announced standalone Capacity Reservations in October 2018. Pricing and capacity reservation are two different things since then.

How to monitor Savings Plans?

Immediately, after you have purchased a Saving Plan, you should configure monitoring as well.

  • Saving Plans Utilization is low: you are using less compute resources than you are paying for.
  • Saving Plans Coverage is low: your compute usage exceeds your Saving Plans.

Doing so is simple by creating a budget, as illustrated in the following screenshot.

Budget to monitor Savings Plans Utilization

As described next, you should also check the IAM policies in your AWS accounts.

Restrict access to Savings Plans

Purchasing Reserved Instances and Savings Plans result in bigger financial commitments. Therefore, you might want to restrict who can make such purchases in your AWS accounts.

Are you using blacklists to avoid that certain users can buy EC2 Reserved Instances? If so, your IAM policy might look something like this.

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ec2:PurchaseReservedInstancesOffering",
"Resource": "*"
}]
}

The following policy demonstrates how you can deny access to Savings Plans as well.

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ec2:PurchaseReservedInstancesOffering",
"Resource": "*"
}, {
"Effect": "Deny",
"Action": "savingsplans:CreateSavingsPlan",
"Resource": "*"
}]
}

If you use AWS Organizations, you better deny the above operations in a Service Control Policy.

What about RDS, Elasticsearch, DynamoDB, …?

Savings Plans for EC2 and Fargate are not the only options to reduce your AWS bill. Similar deals - you commit to an hourly consumption or even pay upfront - exists for other AWS services as well.

Unfortunately, managing most of these options at scale is complicated compared to Savings Plans.

Are there other options to reduce costs for EC2?

Using Savings Plans affects your billing but not your infrastructure. However, there is another pricing model for EC2: Spot Instances. A Spot Instance makes use of unused capacity in Amazon’s data centers. The spot price reflects the current demand for a particular instance type in a specific availability zone.

The following screenshot shows the spot price for an m5.large instance in US West (N. California). Roughly estimated, the spot price in recent months was 60% percent below the on-demand price.

Spot Instance Price

  1. You create a spot request and define the maximum price you want to pay.
  2. AWS launches an instance when there is unused capacity available, and the spot price is below your maximum price.
  3. AWS will terminate the instance with short notice in case the spot price exceeds your maximum price during runtime.

Spot Instances are an excellent option for stateless workloads, where terminating instances is not a big deal. It is not uncommon to reduce the EC2 costs by 60% to 80% by switching from on-demand to Spot Instances. However, you need to make sure your architecture and application are ready for Spot Instances. Also, you need to plan for service availability in times of low spare capacity in AWS data centers.

Summary

I purchased a Savings Plan for our compute consumption today. I’m quite happy to be able to reduce our AWS bill without trading in too much flexibility. Even though we plan to transition a few EC2 workloads to Fargate next year, it strikes me that Savings Plans offer more flexibility for the same discount on the on-demand price than Reserved Instances. No need to deal with Reserved Instances any more.

Michael Wittig

Michael Wittig

I’ve been building on AWS since 2012 together with my brother Andreas. We are sharing our insights into all things AWS on cloudonaut and have written the book AWS in Action. Besides that, we’re currently working on bucketAV, HyperEnv for GitHub Actions, and marbot.

Here are the contact options for feedback and questions.