When you’re trying to cut costs on your AWS bill, you’re likely to come across AWS Savings Plans (“SPs”).
We’re sharing what we’ve learned about Savings Plans based on The Duckbill Group’s extensive experience fixing our clients’ horrifying AWS bills. In this article, you’ll learn what Savings Plans are, how to pay for them, and how they’re applied.
We’ve also created a guide to AWS Reserved Instances (“RIs”), another common vehicle for committed use discounts.
What are AWS Savings Plans?
Launched in 2019, Savings Plans are a mechanism AWS provides to commit to using a certain amount of compute per hour in exchange for a discount on the instance cost. Savings Plans cover EC2, Lambda, and Fargate compute. (Separately, SageMaker has its own program, also called Savings Plans, that functions much the same as Compute Savings Plans.)
One of the things many people new to AWS get confused about is that Savings Plans are not a reservation of capacity, but rather a billing construct. In fact, the best way to think about Savings Plans is actually by using Google Cloud’s nomenclature: a committed use discount. SPs are a financial construct, not a technical one.
Savings Plans are a fundamentally different model from Reserved Instances. Instead of picking specific instance types or families, you pay for a certain amount of compute per hour. Importantly, you are committing to a certain amount per hour and paying for it regardless of whether you use it. Any amount under the commit is charged at the Savings Plans rate, while any amount over the commitment is charged at the on-demand rate. As you might imagine, determining the right commit number can involve some real work. Thankfully, as we’ll go into later in the article, AWS has several great tools to help.
Savings Plans payment options
All Savings Plans have three payment terms: all upfront, partial upfront, and no upfront. Payment options cannot be modified after you’ve made the purchase, even for no-upfront purchases.
All-upfront payment terms are exactly what they sound like: You pay for the entire SP upfront. This option provides the deepest discount, but in Duckbill’s opinion, the increased discount is generally not enough to be worthwhile, with two exceptions:
- If you work in an organization that needs to spend its money within a certain budget period, paying upfront can be a great way to consume the budget.
- Paying upfront is a great way to shore up a potential shortfall in meeting your AWS contract’s Enterprise Discount Program (“EDP”) or Private Pricing Addendum (“PPA”) commitments.
Partial-upfront payment terms mean you pay just some of the total cost when you purchase your Savings Plans. There’s very little reason to use this unless you simply need to spend the cash but don’t want to spend as much now as an all-upfront payment.
No-upfront payment terms are, again, exactly as they sound. Rather than paying any amount of cash upfront for the purchase, you pay for it monthly. The no-upfront payment option provides the least discount but, in Duckbill’s opinion, should be the default choice for every organization.
Choosing no-upfront payment terms over all upfront or partial upfront comes down to how much you like cash in your bank account versus Amazon’s bank account.
Savings Plans term length
All Savings Plans have two term lengths available: one year and three years. The term length cannot be modified after you’ve made the purchase.
Three-year terms receive the best discount, but as you might imagine, planning your infrastructure for three years out can be difficult for many organizations. While the delta between one-year and three-year terms can be substantial, Duckbill recommends defaulting to one-year terms unless you are confident in your workload forecast.
How often to buy Savings Plans
Savings Plans are designed to stack on each other, so having a few automatically works out. In other words, three active Savings Plans with commitments of $10/hour, $2/hour, and $25/hour will be treated as $37/hour’s worth of coverage.
We occasionally run across organizations that try to time their Savings Plans purchases with their private pricing contracts or purchase only once a year; these are suboptimal approaches.
Instead, you should be buying Savings Plans as often as necessary to maintain coverage and utilization levels at your desired targets. We recommend evaluating on a quarterly basis whether true-ups are needed, though you might find that your growth dictates more frequent analysis. It’s not uncommon for an organization to have dozens or even hundreds of Savings Plans, all with different terms.
No Savings Plans resale market
Your unused Savings Plans can’t be resold. There’s no equivalent to the Reserved Instance Marketplace for Savings Plans.
The difference between Compute Savings Plans and EC2 Instance Savings Plans
Savings Plans come in two offer types: Compute Savings Plans and EC2 Instance Savings Plans.
Compute Savings Plans cover three services: EC2 on-demand (spot instances very much do not count!), Fargate, and Lambda. All compute for these three combined, in any region, is covered by a Savings Plans commitment, without you having to do anything. This is one of the biggest advantages of Savings Plans over Reserved Instances: extremely low cost of management.
EC2 Instance Savings Plans are far more constrained, requiring a choice of region and instance family, though you don’t need to select operating system, tenancy, availability zone, or even instance size. In exchange, you receive a deeper discount.
It is Duckbill’s recommendation to default to using Compute Savings Plans and ignore EC2 Instance Savings Plans absent a specific, good reason to simply save on the headache of managing and modeling both. However, there are advanced strategies for mixing the two.
Mixing Compute Savings Plans and EC2 Instance Savings Plans
In time, as your confidence grows with regard to your workload stability, it can make some sense to mix EC2 Instance Savings Plans with your Compute Savings Plans to cover some baseline level of compute usage that isn’t going anywhere anytime soon. If you know the instance family and region aren’t going to be changing, then purchasing EC2 Instance Savings Plans to cover that combination, then layering Compute Savings Plans on top for the remainder, can result in much deeper overall discounts.
However, be careful! If there’s a communication breakdown between Engineering and whomever is planning Savings Plans purchasing about the longer-term architectural plan, it’s easy to inadvertently lock yourself into a situation where you’re facing significant financial penalties for evolving your architecture. That’s why we suggest using this approach sparingly. Flexibility has its own value, and ossifying your architecture to chase bigger discount percentages is very often misaligned with your organization’s best interests.
How Savings Plans are applied
One area that causes confusion for people is that you can’t choose which resources compute Savings Plans apply to. Many people think about Savings Plans in terms of specific instances, then decide to buy a Savings Plans commitment to cover that instance. However, that’s not at all how it actually works — and this mental model leads to some unexpected outcomes.
The application of Savings Plans-covered workloads is automatic and follows a principle of “deepest discount first.” In other words, if you have a handful of instance types running with different post-Savings Plans discount levels, then the Savings Plans apply to workloads where the impact will be the greatest until the hourly commitment is exhausted.
This does have some implications for your purchasing approach, as some instance types receive such low savings that they would rarely be covered by SPs. For example, instances running Windows with the license-included model receive the worst discounts of all. Because maintaining 100% SP coverage is impossible in any environment with a dynamic workload without incurring significant waste, that means you will always have some amount of compute that isn’t covered by SPs — but, crucially, you don’t get to pick which compute specifically.
It’s best to adjust your mental model and think about your workload in aggregate, rather than by specific instances.
In some organizations that do chargeback to their individual teams, this situation can often lead to intense discussion from those whose compute resources aren’t being covered. On one hand, they’re being held accountable for their spend, and that spend is higher than they intended. On the other hand, the organization is better off this way (after all, money is fungible because it’s all company money). The various resolutions to this particular problem are a topic for another day.
Combining Reserved Instances and Savings Plans
You can combine RIs and SPs, and they apply sensibly in a “deepest discount first” interleaving. This is a common approach for organizations transitioning from EC2 Reserved Instances to Compute Savings Plans: Simply purchase Savings Plans as the EC2 RIs expire.
Reporting and recommendations on AWS Savings Plans
AWS provides two primary tools to stay on top of your Savings Plans: the coverage report and the utilization report.
The coverage report is a measure of how much of your compute is covered by Savings Plans. A good goal is 80%-85%.
The utilization report is a measure of how much of your Savings Plans are being used. A good goal is 100%.
There are effectively four scenarios you could find yourself in:
- Low coverage, low utilization: You have no Savings Plans.
- Low coverage, high utilization: Not enough Savings Plans. You’re under-committed. Buy more to increase coverage.
- High coverage, low utilization: Too much Savings Plans. You’re overcommitted.
- High coverage, high utilization: Everything is great!
Because Savings Plans are calculated on an hourly basis, highly elastic environments (in which the compute has wild swings hour by hour) might see large fluctuations in coverage and utilization. This is not necessarily a bad thing, but it is worthwhile to do the math.
