AWS Savings Plans were launched just over a month ago now. They are essentially being pitched as “Reservations, but easier”. In both cases, pre-pay for your compute capacity and unlock discounts for doing so. Here, I present my thoughts on this, coming from an Enterprise AWS background.
What Enterprise background is that exactly?
I work for StepStone. AWS is our cloud provider of choice. We have approaching 100 accounts and an expenditure level within AWS that you would expect given our €3,000+ million revenues (2018).
StepStone have many different brands, and multiple architectures powering those brands within the technological estate. This is historically due to acquisitions. There is always ongoing consolidation work, such as shared services for different brands to use, but this adds to the complexity that we are dealing with.
One of the linchpins of my role is Cost Optimisation, and working with the teams across the Group to do this right. Hey, this is one of the pillars of the AWS Well-Architected Framework after all.
Life Before Savings Plans
As is typical within Enterprises in AWS, a large portion of our spend is in EC2. That has mostly originated from numerous ‘lift and shift’ migrations.
We introduced targets for reservations across the group. This is really simple:
- The minimum target is 60% of savings being realised. I.e. 100% would be “All of my EC2 capacity is reserved”. Note: As this is talking about Savings that means Production servers (typically more powerful and therefore expensive) have greater weight than Development servers.
- “What about Spot?” — That’s OK, as they aren’t included in the calculations, so go for it.
- “What if I can’t reserve because….” – Yep, there are always valid reasons for this. One would be building something new and the capacities aren’t known yet. Another would be a site which is known to be sun-setting within a few months, and the old reservations have just expired.
This approach has worked really well for us. We’ve been regularly exceeding this target. In fact, hitting 80%+ is typical.
This relies on the individual Account Owners, and their teams, really focusing on which reservations should be made, and using the tools available to do so. CloudHealth has historically helped a lot with this, and Cost Explorer has got better at it too.
But it’s not perfect….
When Reservations Attack
The whole reservation system can cause pain.
Firstly, there is naturally a degree of manual work in implementation. The various recommendation engines make this a lot easier now, but there still has to be a manual analysis on what the future brings. What’s the future of the architecture? Is it being migrated very soon? Exactly what type of reservation should you be going for?
Okay, some amount of work like that is a given, to be fair, as reserving capacity is all about pre-planning.
The main issue is when things go wrong and you are having to work with Amazon to get things swapped around.
This is typically when we have needed Reservations refunded due to situations changing. Now, I’m not talking about where we have changed our mind — I wouldn’t expect a refund in that instance. We’ve had situations where we have made purchasing decisions based on advice from Amazon that was later shown to be wrong. The good news is that we got refunds, but it was a long and torturous process, involving far too many approval layers on the ‘other side’. So much so, in fact, that I’m wondering whether the money we got back even paid for the salaries of everyone that was involved. Frustrating.
We’ve historically been told that this is due to the EC2 capacity team relying on Reservations to accurately plan capacity. I’m now a little bit dubious on that, purely as Savings plans do not have to specify instance types any more – purely an expenditure level.
Are Reservations going to go?
Amazon are making it clear that they don’t really want customers using Reservations any more (from the FAQ):
Can I continue to purchase EC2 RIs?
Yes. You can continue purchasing RIs to maintain compatibility with your existing cost management processes, and your RIs will work along-side Savings Plans to reduce your overall bill. However as your RIs expire we encourage you to sign up for Savings Plans as they offer the same savings as RIs, but with additional flexibility.
Remember: Not only are Savings plans more straightforward for the customer, they are going to cause less drama for Amazon themselves. No longer will they have to field reservation refund requests.
I can imagine Amazon will make Reservations no longer available to purchase within a few years, and push Savings Plans very strongly before that via Account Managers and TAMs as they detect renewal windows coming up.
What are we going to do?
This is a great question. As of right now, we haven’t purchased any Savings Plans.
The reason for this is that, at an Account level, those teams can be very precise in their reservation strategy and therefore unlock the best discounts.
Executing a Savings Plan purchase at our payer account level (where we really have a great view of total spend) means being a bit more generic, and going in at the top level, rather than Instance types. There’s a balancing act here, as we would probably get better coverage but the discount level might end up being lower. Oh, and throw into the mix the fact that the human cost of analysing everything would be reduced too.
Also, if we purchase at the payer account level, we need to look at how we cross-charge our various entities their share of the upfront payment. Yes, we cross-charge our AWS bill. We’re not alone in our segment for doing this, that’s for sure.
In short, we need to do some more analysis and then take a consistent way forward, to avoid any confusion given the number of people that we have working on cost optimisation within the business.
What are YOU going to do?
Please let me know! I’d welcome your thoughts on Savings Plans and the changes that you have made, or are going to make, as a result of their introduction!