Disclaimer: In case anyone is confused, I have no special inside knowledge of AWS’s plans for Reserved Instances. Maybe this marks the start of their demise, maybe it doesn’t. I’m inclined to believe the former, though.
AWS Reserved Instances have gone through many iterations over the years (e.g., RI Marketplace, Regional RIs, Convertible RIs, and Instance Flexibility), much of them focused on providing more flexibility and simplicity.
While RI purchase planning isn’t too bad when you have 100 instances running Twitter For Pets, it becomes an utter nightmare when the answer to “How many instances do you have?” is “Who the hell knows?”
In between all of these improvements to RIs, AWS continued to launch new instance families and sizes to the point where there are over 200 distinct instance SKUs you can purchase today in us-east-1.
Thankfully AWS has heard our wailing and gnashing of teeth and realized the horrific microservices-diagram-meets-Boston-streetmap of complexity they created. Today’s announcement marks an incredible improvement in compute purchasing.
AWS Savings Plans
Today, AWS announced “Savings Plans,” which sounds like a bank’s Christmas Club account offering but is in fact something far more compelling. It amounts to nothing less than a complete overhaul of the AWS compute pricing model.
Yes, it really is that big of a deal.
At a high level, you no longer need to purchase RIs for a given instance type. Instead, you commit to a baseline level of spend per hour on compute that you’ll pay regardless of actual use. Anything at or below that usage level is included; anything above it you’ll pay at the existing on-demand rates.
The new model is available in two variants, though they have much in common.
|Compute Savings Plan
|1 Year or 3 Year
|Tenancy Flexibility (Shared vs Dedicated)
|All, except mainland China. Yes, that means GovCloud too!
|Spend above your commit is charged at on-demand rates
|No upfront, partial upfront, and all upfront
|Up to 66%
|Up to 72%
Compute Savings Plans
Compute Savings Plans come with a high level of flexibility. They aren’t tied to any specific region. You decide your spend commitment per hour across all of your accounts and that’s that. You pay that much regardless of your usage; any usage beyond that baseline commitment gets charged at normal on-demand rates.
You get up to a 66% discount for a three-year commitment–the exact discount percentage varies. Interestingly, Compute Savings Plans apply not just to EC2 instances, but also to Fargate. (Edit: Four months post launch, it also added support for Lambda.) This means you can seamlessly transition workloads between EC2 and Fargate and it applies to your spend commitment.
EC2 Instance Savings Plans
EC2 Instance Savings Plans have less flexibility but provide you with deeper discounts in exchange. They are tied to a specific region and a specific instance family (e.g., i3 or c5 instances). In return, you get a varying discount percentage that comes in as high as 72% for a three-year commitment.
How do I work with Savings Plans?
You interact with Savings Plans within Cost Explorer.
The “Savings Plans” menu option provides an overview of the program, a purchase page, and a very well-tuned recommendations engine. It looks at your historical usage for 7, 30, or 60 days and generates purchase options for you across both one- and three-year terms, as well as the usual “no upfront, partial upfront, or all upfront” payment options you’ve come to know and tolerate from Reserved Instances.
You’re absolutely going to want to use Cost Explorer to baseline what your per-hour on-demand costs have been; this isn’t a metric that most things track because until now, why would anyone have cared? Remember, if you spend the off-hours at a lower per-hour level of compute, you’re going to want to use that as a baseline for your purchase, as you’ll be committed to spending that much around the clock, every hour, regardless of whether you’re using that much capacity.
Are Reserved Instances actually going away?
Sadly, not to our knowledge. You’ll still be able to purchase RIs, because AWS never turns anything off. On the plus side, you don’t have to care about them anymore unless you want to.
This brings up a wonderful question: When should you use RIs instead of Savings Plans?
Here are some times when it may make sense to still use RIs:
- If you have internal company processes deeply tied to the RI purchasing process,
- If your company is accounting for RIs as CapEx and your auditor won’t allow you to do that with Savings Plans, or
- If you’ve taken a sudden sharp blow to the head and enjoy the stupendous complexity of RI purchasing and management.
Other than in those three exception cases, you want to migrate as soon as you can.
There’s no reason not to do this. It frees up a tremendous amount of obnoxious fiddly work to calculate exactly what your RI buy should look like (hope you like Excel!) and it grants you the freedom to experiment with Fargate without paying the challenging-by-comparison on-demand pricing for it.
I just bought a boatload of RIs. Am I screwed?
I wouldn’t think so–remember, Reserved Instances aren’t going away and offer the same discount percentages as Savings Plans. That said, if you’re unhappy with AWS, I give you the same advice I give to everyone in your position: call your AWS Account Manager. They can’t help you if they don’t know you’re unhappy.
There are some losers in this change, though
Unfortunately, the SaaS companies that built their businesses around managing RI purchasing on your behalf could not be reached for comment at press time. They were too busy sobbing into their AWS Partner Network Agreements.
To be honest, I kinda feel bad for VMware’s purchase of CloudHealth and Apptio’s purchase of Cloudability, both of which just presumptively lost massive market value with this one change.
The new AWS Savings Plans are a long-overdue and welcomed change, to the point where about all I can mock is its uninspiring name.
“Savings Plans” sound like how you’re going to cover your vacation to Hawaii. But in this context, that would just be embezzlement.