AWS Savings Plans: Five Top Tips

AWS Savings Plans is a pricing model: a billing construct that helps you save up to 72 percent on compute costs in exchange for committing to a minimum level of usage.

Savings Plans vs Reserved Instances

Compute Savings Plans give greatest flexibility. They apply to EC2 instances, Fargate and Lambda; they apply across all regions. You commit to a minimum compute spend per hour (e.g. $1 per hour). This is particularly useful for businesses that innovate quickly, where the suite of applications and their resource requirements change over time. It is also excellent for large organisations who look at usage in the aggregate across 100s of applications.

EC2 Instance Savings Plans are similar to standard Reserved Instances - they apply to EC2 instances in a specific instance family and region. They have a role to play, especially for applications that are unlikely to change over the coming year(s). The discount is larger when committing to a specific instance family and region (e.g. 42% discount on a Linux m5.large for 1 year all upfront payment, compared to 31% with compute savings plans).

Traditional Reserved Instances (RIs) definitely still have a place. For example, savings plans currently do not cover Relational Database Service (RDS) instances, AWS Redshift, or ElastiCache. Also, traditional RIs can give bigger savings in some cases, so it is worth checking - for example EC2 instances with some licensed operating systems like SUSE Linux Enterprise Server (SLES).

This blog will focus on Compute Savings Plans. 

Tips

1. Purchase in an account with no usage

Savings Plans are first applied to resources in that account, then to resources in other accounts in the organisation. By purchasing the savings plans in an account with no usage, you let AWS billing figure out the specific resources to apply the savings to at any given point. This will always give the biggest savings.

This is important because the percentage saving varies for different resource types - savings vary from 2% to 72% (as a rule of thumb, the bigger and less common a resource type, the bigger the discount compared to on-demand).

Note: always turn on sharing for reserved instances and savings plans, to maximise the savings for your organisation.

2. Don’t blindly trust the “AWS Recommendations”

The AWS Cost Explorer shows recommendations for savings plans. If using AWS Organizations, do this in the master/payer account (now called management account). However, this is just a starting point - don’t blindly follow the savings plan it recommends! Always drill into the recommendations.

The reason is that the total recommendation will likely be the sum of savings at different rates. For example, half of it may give a 38% cost saving, and the other have only a 2% cost saving. The total may look good, but your finance team will likely not want to commit to the outlay where the saving is only 2%.

Also, the recommendations are based on historic usage over the analysis period. It does not take into account forecasts, or trends (such as seasonal variation or usage having dropped off).

3. Identify low-risk and high-return purchases

For how big a savings plan to purchase, you are looking for the level of (mostly) sustained, steady usage.

The AWS well-architected labs have great guides for analysing your usage, including for pricing model analysis such as savings plans. Alternatively if you are already a customer of Aptio Cloudability or VMware Cloudhealth then these products include recommendation features for savings plans.

As a rule of thumb, you are looking for the investment in the savings plan to pay off in about 9 months: longer and it increases risk (what if your usage pattern substantially changes); shorter and you are likely leaving savings on the table.

Another rule of thumb is to focus on savings that apply across many instances. If the savings apply to just one or two EC2 instances, then a small change in architecture or business strategy could invalidate those savings. If the savings apply to 10 or more EC2 instances (and ideally across multiple teams), then the savings plan purchase will be lower risk.

4. Do not have a target based on utilization or coverage

It might feel tempting to set goals, such as “savings plans should cover 80% of our usage”. However, this is not a good way to approach the problem due to the varying size of available discounts. A low coverage does not necessarily mean there are high potential savings.

A better strategy is to regularly track and monitor the potential savings available (see previous tips). For example, if the potential discount from purchasing new savings plans goes above 20% then that could be a trigger to purchase more.

5. Purchase centrally in small amounts in cycles, every 2-4 weeks

A good cloud finance strategy, including for savings plans, requires regular review and small incremental steps. It is better to purchase small amounts every two to four weeks rather than a big review once per quarter or once per year.

Purchasing savings plans should not be a “big project”. When it comes to data analysis, the best is often the enemy of the good. By purchasing small amounts at a time, the risk is low so approval is also easier.

Your company’s usage will change over time, so your savings plans need to evolve with it. Small regular purchases make that easier. Also check for anomalies, such as big changes in savings plan coverage, so you can investigate and respond quickly.

Finally, for large organisations it is much better to manage savings plans centrally (rather than decentralising decisions to individual teams). The first big benefit is expertise - a centralised team can build up expertise in the pricing models available, data analysis and quirks/edge-cases to make better decisions than would be done by most individual teams. The second big benefit is that aggregate usage across many teams, including their variability over time, means centralised savings plans are more efficient than when each team looks at just their own applications. Also, the centralised team will be able to work more closely with the finance team to get buy-in and make decisions aligned with the business. Of course, the centralised team should talk to and work closely with application teams to make near real-time cost reports available, share results of analysis, and to help with other cost optimisation.

Conclusions

The flexibility of Compute Savings Plans makes them an excellent choice in many situations.

If you haven’t already, then look at the AWS Cost Explorer recommendations, do a little analysis, and consider a small purchase now. This should not be a big project or something that people defer. By starting small, you begin to get experience with savings plans, you keep the risk low and can get approval more easily, and you get the cost reductions more quickly. Then after your next AWS bill, consider purchasing more savings plans.

For more information, read the AWS well-architected cost optimisation pillar. If you’d like advice or assistance, please reach out to Cloudsoft for a free consultation with a cloud expert.