AWS Savings Plans — Easier Than RIs But Still Not as Good as Scheduling!

AWS recently announced the release of AWS Savings Plans — a new system for getting a discount on committed usage for EC2 and Fargate. The previous systems of Reserved Instances (RIs) are still around, and in some cases may still be the right way to go. That said, based on our research, if your virtual machines do not need to be running 24/7, they are still not as effective at cost savings as scheduling your systems to be shut down when not in use.

I am not keen on the “Savings Plan” name, as it sounds to me like you are building up money in the bank, but really it is a capacity purchase plan to save you money.

The key feature of the Savings Plans is that you are committing to spend a certain amount of money per hour for EC2 and/or Fargate use. The hourly commitment must be greater than or equal to $0.001. If you make the commitment, AWS will give you a discount on whatever virtual machine to which they apply the expense.

There are two kinds of Savings Plan:

  • Compute Savings Plan — Apply to EC2 or Fargate usage regardless of instance family, size, AZ, region, OS, or tenancy. For any given instance configuration, pricing is similar (if not identical) to an equivalent Convertible RI, giving up to a 66% discount.
  • EC2 Instance Savings Plan — Specific to EC2 instances within a family in a specific region, but regardless of size, OS, or tenancy. For any given instance configuration, pricing is similar to an equivalent Standard RI, giving up to a 72% discount in exchange for the reduced flexibility.

Common attributes:

  • Both types require a commitment for either 1 year or 3 years.
  • They cannot be canceled, refunded, or exchanged
  • You can buy as many as you like for as much of a commitment as you like. Ten plans at $1/hour each, or one plan at $10/hour, or any other combination for as little or as much as you like.

Savings Plans vs RIs

So obviously there are feature differences. The key thing here is that the Savings Plans give the same amount of savings as a somewhat equivalent RI, but with a LOT more flexibility in terms of what instances can get the discount.

The customers get in, but they can’t get out…

Why might you want to get rid of an RI?

  • Maybe you bought a non-flexible RI, switched your needed instance size/family, and the RI is no longer useful.
  • Maybe…you just cannot afford it anymore.

For the first issue, Savings Plans are a lot more flexible, allowing exchanges across sizes, families, and regions, depending on what kind of Savings Plan you buy.

For the second issue…Savings Plans provide no flexibility. Do you have any workloads elsewhere you can bring in to use the commitment — maybe some containers that can be moved to an EC2, or maybe an RDS that you can turn in to a self-managed database? Or maybe you can just use the unused capacity to mine a couple pennies-worth of Bitcoin…

At the end of the day, you need to weigh the discount vs. your confidence in the stability of your workloads and your funding.

(I personally just picked up a $0.001 per hour plan for $8.76 for the year and feel confident that I can meet that obligation.)

Savings Plans vs Scheduling

To demonstrate this, here is a comparison for a t2.medium in us-east-1 running Linux in shared tenancy. The t2.medium, while a small and slightly older instance type, is the most commonly used instance type we see across all of our ParkMyCloud customers, with 3x the number of deployments than the next most common type.

In the graphs below, the slanting green line represents the monthly cost of an instance based on the number of hours it is running per day on weekdays only (so it already accounts for pulling out the cost of weekends). For example, if this virtual machine was running 12 hours per day on weekdays (not a very aggressive schedule) it will cost $144.77 per year. Compared to the baseline pay-as-you-go price of $406.46 per year, this is a savings of 64%.

The following graph shows a comparison of the annual cost of this t2.medium instance when bought with:

  • Either a Compute Savings Plan or an EC2 Instance Savings plan
  • For a 1-year vs 3-year term
  • With no upfront cost (so you are charged monthly)

This graph is telling us that compared to the most aggressive EC2 Instance Savings Plan bought at a 3-year commitment, scheduling is still less expensive. In fact, we need to get up to about 14 hours per weekday before the Savings Plan saves any money.

At the top end, the instance could run all day on weekdays, 5/24, and just match the 1-year Compute Savings Plan savings. (That number matches so closely I truly wonder if this is how they came up with the base savings for the RIs and Savings Plan.)

In this next graph, we change the Savings Plans to be purchased all upfront, which gives a bit more savings but still cannot match the savings of the 5-day/12-hour schedule.

Note that if this WERE a system we want to keep up 7/24, we would have to create a savings plan that covers the hourly cost of the instance. For example, the base price of the t2.medium in our example is $0.0464 per hour. Under the savings plans, we get a discount on this, and if we wanted to be sure at least this instance was covered, we would need to buy a savings plans (with no upfront cost) with one of the following rates

Again note that none of these reach the 64% savings of a basic 5-day/12-hour schedule.

How are Savings Plan Applied to my Bill?

  • First, any RIs are applied to your bill — they are less flexible, so you want them “used up” before Savings Plans are applied
  • Then, EC2 Instance Savings Plans are applied next
  • And lastly, Compute Savings Plans are applied

Within either of the Savings Plan types:

  • The plan is first applied to the AWS Account in which the Plan was purchased
  • And the plan is applied to the resource type/region/etc with the highest potential discount compared to On-Demand
  • After that is shared with the rest of the accounts in your AWS Organization

Why did AWS do this?

What do I do now?

Originally published at www.parkmycloud.com on November 26, 2019.

CEO of ParkMyCloud