AWS Savings Plans - my personal view

I’ve spent some time over the last week mulling over the new AWS Savings Plans and after listening to some very intelligent folks debating it have reached a conclusion. Thanks to my co-writers Stephanie Gooch and Bhupendra Hirani for their fantastic input.

Just like a lot of politicians I’m sitting on the fence and my conclusion is simply that they won’t suit every requirement or use case! The reason for this view is that the value of a Savings Plan wholly depends on how you are using AWS today and the maturity of your cost management processes.

At a high level I think these are a great concept as they get rid of the major complaint that RI’s are far too restrictive and complex to manage, absorbing too much time and effort to get the value back from them. AWS attempted to resolve this with their marketplace resale capability but for some this added even more complexity, bringing tax and compliance issues.

AWS have released two types of Savings Plans (both with 1 or 3-year terms), these being Compute and EC2 Instance Savings Plans. The Compute SP can be applied automatically regardless of what family, size or region you deploy your resources into (and can be used for both EC2 and Fargate), whereas the EC2 version means you are committed to the same family in the same region. EC2 SP’s are akin to the existing RI approach, meaning you are committing to an individual instance family in a specific region. The main difference from an RI is that you can change the Instance Type within the family you have selected. Also, with SP’s there is flexibility on the operating system (OS) you choose to deploy.

So, what’s the discount model like?

My deep dive discount analysis is still work in progress, along with some peers in the fantastic finops.org community there is a lot of work being done to compare the reality of the discounts vs. RI’s and on-demand resources.

At a high level, the discounts for the Savings Plans vary based upon your level of commitment and the specific plan type. AWS offer 1 or 3-year commitment plans (just like RI’s) plus the usual options to pay nothing upfront, partially pay upfront or if you’re feeling cash rich, to pay everything upfront. The actual discount you’ll get flexes based upon the term and amount of cash you are releasing upfront but can be anything up to 72% for EC2 plans or 66% for compute plans. Here’s an example of discounts for c5.2xlarge Linux in eu-west-1 (shared tenancy).

 I’d strongly recommend that you remain cautious of the marketing discounts being thrown around like “up to 72% savings vs 67% RI” comparison that I’ve seen being marketing vs. the actual pricing for that instance you are modelling. This is slightly disingenuous just because it is trying to mis-position real world costs for common instances.

My initial review of the cost comparisons between RI’s and SP discounts for other instance types is that in some cases you are surrendering a % of your RI discount for having the flexibility that a SP provides. The discount differential really seems to vary by type with some actually being neutral from a cost perspective (as seen in the table above). This is really only an issue for organisations who already have hardened and mature cost management processes in place (i.e. strong embedded controls over RI management). If you’re at the other end of the spectrum and struggle to manage use of RI’s, then the marginal reduction in discount may be something you can live with

Should you use Savings Plans?

Absolutely yes, they have a place in nearly every AWS customer cost management strategy; but it’s critical that you make your investment decision based upon actual facts and your approach to risk management (not forgetting a reality check on your level of operational maturity).

SP’s are not the nirvana fix to spend management in AWS, it is still critical that you plan correctly so that you make the right commitment, even buying incremental SPs over time as you gain a better understanding of the predictability of your spend profile and growth within AWS. They do not fix oversizing issues, nor do they address the issue of resource wastage. If you're coming off of RIs (or even if you're not), make sure that you take full account of what an instance scheduler for EC2 can provide when you calculate savings through elasticity. You should also consider using your own tools or ISV providers like Spotinst, Cloudability, Cloud Checkr (or similar cost optimisation tooling) to drive those savings.

Will SP’s totally replace RI’s?

In truth no, probably not right away, but over time it is clear that AWS will steer customers down the savings plan path. What this does mean for new requirements is that Right-sizing urgency is now less important, just due to the new fluidity that SP’s provide. Before these new plans, engineering and development teams would have gone through the right sizing process to ensure the correct resources were being acquired. Now this can be done after the fact, but this does introduce the risk of complacency setting in!

The Con’s:

1. No capacity reservation guarantees – you could argue quite rightly that this is totally irrelevant and does not matter due to EC2 Capacity Reservations as a standalone feature
2. Although SP’s give far greater flexibility, there is no disposal strategy to sell back like there is with the RI marketplace. Note - I still think that the marketplace is a great thing, but most big companies seem to be struggling a lot with the tax implications and complexity associated with buying and selling RI’s. If this is the case for your organisation, then I suggest that you use tools like Spotinst or similar to automate the process and take this pain on your behalf
3. SP’s look potentially great but are just giving your cost management team another set of options to consider (i.e. another 12 options added into the mix when considering what to buy). When consuming AWS resources it is already relatively complex and should you continue with RI’s along with SP’s, then you are facing a new series of financial justifications when looking at core predictable services along with new outliers where consumption will inherently be more volatile/variable
4. Lack of tagging capability. Unless I’m mistaken there is no way to tag SP’s with a cost centre or resource group and the credits may be applied more randomly in your cost and usage report (CUR). It does appear that tagged spend is negated in the SP CUR line entry
5. SP’s are still a much more expensive option than a spot first strategy. Clearly this is a blindingly obvious point and is unlikely to ever change, but it does reinforce the huge value of Spot and exactly why AWS users need to get more comfortable with the perceived risk that comes with running Spot (or adopt COTS that enables Spot to be used with little risk for more workloads)
6. The risk remains of over committing when spending on a savings plan – but then again this is no different to buying RI’s. It does not address volatile workloads that are prone to large flex in consumption (both up and down) or serverless platforms. I know what I’m about to say is ridiculous because you’re getting a better discount, but there is still no ability to step back if you do over commit
7. If you are using scheduled RI’s you’ll need to consider how these would impact any SP calculation, it may be that Spot might be a better future option for this type of workload (as long as you’re flexible about when they run)
8. SP’s could be seen as a sticking plaster that fixes a bigger problem in an organisation – i.e. badly managed processes with little cost control or analysis of actual usage needs. In many environments the need for huge flexibility is somewhat of a myth with the bulk of workloads being relatively predictable and actual cost management being something that should already be being achieved

Pro’s:

1. Savings plans could be seen as ‘entry level EDP’s’. The AWS Enterprise Discount Program (or EDP) has been great for customers willing to make large financial commitments (large being hundreds of thousands per month) but haven’t really been useful for the 90% of organisations who spend much less than this. Savings plans do address this issue and enable much smaller organisations to gain benefit from their willingness to commit
2. Short lived instances (such as test & dev resources) or new outlier projects will now be able to have some discounts applied, whereas previously they might have been consuming on-demand resources (i.e. projects that might be excluded from RI commit planning sessions). It’s potentially a very good way to reduce cost on projects where Spot first and RI’s aren’t viable options
3. They could be valuable options for any organisation going through application modernisation programs. The common outcome of modernisation is tech stacks rapidly shifting under your feet, OS’s shifting from Windows to Linux, approach from VM’s to containers or similar cloud native approach. Probably worth mentioning here that for anything truly cloud native, I’d still heartily recommend a Spot first approach as the lowest commodity pricing to run a container workload)
4. They are a great option for anyone that don’t have a cloud financial management function/team in place, or if you’re an organisation that doesn’t have the time (or desire) to build a deeper understanding how to eliminate the complexity that comes with RI management (i.e. it’s a less complex decision process requiring less ongoing cost management)
5. Switching from our previous strategy of 3-yr no-upfront convertibles to the 3-yr no-upfront Compute SP gives very similar savings but increases the utilisation of the commitments and reduces the risk around OS and move to serverless (Fargate)
6. Savings plans being flexible effectively de-risk the savings being wasted compared to RI’s. In the past we’ve seen problems with stranded RI’s and wasted investment when customers change regions, families etc. This is obviously less of a benefit for mature cloud organisations with well-run RI brokerage processes in place. This does not mean that you should overcommit on either RI’s or SP’s
7. SP’s also cover use of dedicated instances and shared instances and are switchable. The implication of this is that it could potentially enable organisations to make better use of other 3rd party software licensing benefits to reduce their costs, changing their approach to calculating the application TCO model away from unit costs of compute comparison that is frequently used

My conclusion remains as I said at the start - Savings Plans are a great step towards simplifying the complex world of AWS procurement but certainly are not the nirvana big fix yet.

Thanks for reading this far and have a great week!