Biz Tips: AWS Savings Plans – Easier Than RIs But Still Not as Good as Scheduling!

Biz Tips: AWS Savings Plans – Easier Than RIs But Still Not as Good as Scheduling!

Biz Tip:

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

AWS has a table that compares Savings Plans vs RIs here, but either they were trying to make the Savings Plans look a lot better than RIs, or someone forgot to check a few boxes. (I mean wouldn’t you say that RIs give you a “lower price in exchange for a monetary commitment”? I sure would.) Here is my take on that table:

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…

If you change your mind about buying an RI, you can sell it on the AWS RI Marketplace. You will not get back the full value of what you owe, but at least there is an option. With Savings Plans there is (so far) no way to back out. The AWS Service Terms (section 4.5) states “Savings Plans are noncancellable.”

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

Just like RIs, savings plans are intended to be applied against resources that are up 7/24/365 (or 7/24/1095 for 3-year purchases). For resources that only need to be when someone is using them, like dev, test, staging, build, and similar system, it is likely better to schedule them.

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?

The example above shows what you would pay for that t2.medium if it was the only instance in your account. If you have multiple instances or even multiple accounts within an AWS Organization, the Savings Plan is applied in a prioritized way, trying to “use” up the less flexible savings methods before getting to the most flexible:

  • 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?

AWS is philosophically all about the customer…and there is NO question that this new feature is great for the customers. Looking beyond that: anytime a vendor can lock you in to a long-term contract it makes things easier for the vendor in a lot of ways. For AWS, committed use means a more predictable balance sheet and more predictable data center utilization. RIs gave both of these, but they were about as complicated as filling out your taxes, and could be as restrictive as a tight pair of underwear. I am betting AWS is shooting for increased levels of commitment that help the long term bottom-line. The downsides for them are the potentially reduced revenue and the reduced datacenter usage predictability at the region level (since the Compute Savings Plans are cross-region). That said…those long term commitments look really good to the stock market, and a reduction in revenue volatility cannot be bad either.

What do I do now?

At this point you should run (not walk) over to the Savings Plan section of the Billing Dashboard in AWS and see what is recommended in there – it is certainly worth the look. If you were hesitant about buying an RI due to the region or size restrictions, it may be time to reconsider. Note that you do not have to have full coverage of your spend with Savings Plans, but if you have a consistent level of usage 7/24/365, you should cover at least SOME of it with a Compute Savings Plan… And if your usage is not consistent…then consider scheduling your resources with ParkMyCloud…which can also save over 65%.

Join The Rockstar Entrepreneur Community Now: Start Rockin Now

Similar Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *