There was a huge announcement about a new service, or rather a feature, with the bit monstrous name “Savings Plans for AWS Compute Services“. Let’s just call it as Savings Plans for short for now, OK?
There is a AWS blog post and a very recent Last Week in AWS post about the launch, so I am going to cover the basic here really short and then make some additional points, which I think should be noted.
So what is Savings Plans
In short, you commit to a baseline cost with either On Demand model of with fixed timeframe. More you commit, more you get discounted.
So that is it, plain and simple. No more fiddling around with long term strategies for RI purchases, if you don’t want to.
Flexibility beyond instances
One huge different, and arguably a benefit, is the possibility to apply Savings Plans to other type of compute than the traditional instance driven services. That list previously was limited to EC2, RDS, Redshift and ElastiCache.
Now it really does not matter, where you run your capacity. In addition to the list above, capacity inside for example ECS and EKS clusters is eligible for savings as well. And it covers Fargate as well.
Flexibility beyond Operating Systems
One huge limitation in RIs had to do with the kind of instances, where you had paid, commercially licensed operating system on your instance. For Windows instances, you were stuck with the exact size you selected. With Open Source OS’s you had the possibility to scale up and down (with limitations) inside the instance family, but not with commercial ones.
So now, if you want to make your Windows instance larger (or smaller), you can do that any time without taking a hit in the cost department.
Flexibility beyond lifecycle
One huge advantage of moving on to Savings Plans is that you do not need to plan for instance generation lifecycles.
Usually this time of year, you are anticipating for new instance generations to be launched and price cuts announced at AWS reInvent. So you would not do three year commitments at this time of year, would you? (Personally I fell that three years in IT is so long time, that making any kind of commitment to that long of a timeframe need special circumstances to warrant the risk). So using Savings Plans effectively gives you the possibility to move to newer and cheaper instance types, when they become available.
And that brings me to my other point on the lifecycle planning: this gives you the ability to migrate to whole another technology stack. Want to move on EKS or Fargate? No problem, you do not need to write down the RI cost any more.
Capacity reservations caveat
If you are after ensuring that you have always the type of capacity (instance types) you need, then the Cost Savings is not the right tool to do that.
As laid out here, you only had the reservations before, only if you selected Zonal scope in your reservation anyway. Most of the people I work with, waived that reservation in any case in favour of regional flexibility and the ability to change instance type inside the instance family.
So for most, this is not a dealbreaker for using Cost Savings, but if this is something that matters to you, make a note of that.
Multi-account setup caveat
There is not yet much information, that if Savings Plan can be used for commitments from child accounts, as was the case with RIs and if there is similar inheritance model as with RIs. But I will update the post when I have more information.
For now, let’s assume that the Savings Plan is activated at master account level and that’s it.
Edit: from the FAQ: By default, the benefit provided by Savings Plans is applicable to usage across linked accounts within a consolidated billing family. However you can also choose to restrict the benefit of Savings Plans to only the account that purchased them.
So it seems it shares the logic with RI inheritance after all.
Flexibility for all
If you were doing something in a really small scale or had some other specific circumstances, it might have been that optimizing cost with Ris was not for you. But with this approach, you are able to save some cost, no matter how small your environment is.
Doing it is easy, just select your comfort level for the commitment and take the benefit.
Finally – saving cost does not make you efficient
I feel that this is a very good addition to how AWS sells services. It simplifies a lot of things for a lot of customers.
But you should understand that saving cost does not in any way ensure that you are using correctly sized resources at correct times and using even the correct solutions to correct problems. Using Savings Plans gives you the ability to pay less for the capacity you are committed to using. But it does not in any way make sure that you are paying for the things you should be using.
Taking the Well-Architected cost optimization route will be beneficial in the long term, when you actually want to optimize your usage and not your cost – and I feel that they are greatly different things.
Conclusion
My motto in the cost optimization has always been “Big wins instead of quick things” and I still stand by it.
But if you want something achieved quickly or complete replatforming is not a viable option – this will be a great tool to simply just cut down of the cost of the exact same thing you have been running for years.