Skip to content
Savings Plans provide a flexible pricing model offering lower prices than On Demand pricing in exchange for a specific usage commitment (measured in $/hour) for a one- or three-year period.
However, forecasting Saving Plans commitments is an art. In the dynamic world of cloud infrastructure, systems are constantly evolving — your team is constantly modernizing and rightsizing, so the overall cloud cost fluctuates.
Any time you buy Saving Plans, you are committed to the usage for every hour. Because you pay for the commitment regardless of usage, for every hour you don’t hit that usage level, you lose money. This is known as “unused commit.” And if you approach it too carefully and end up under-committing, you’ll wind up paying for the resources your team needs at the highest AWS price tier.
In this blog post, we’ll go over the different types of Saving Plans, and how to optimize them; we’ll also go over the nOps risk-free Savings Plan solution, where nOps guarantees against any underutilization. Let’s start by going over different types of saving plans.
Types of Saving Plans
AWS offers three types of Savings Plans: Compute, EC2, and SageMaker. Let’s compare.
Compute Savings Plans
Compute Savings Plans are the most flexible option. They apply to usage across Amazon EC2, (regardless of instance family, size, AZ, region, OS, or tenancy), AWS Lambda, and AWS Fargate.
For example, you could change a c4.large instance in Ireland to an t4g.16xl instance in London and still receive the AWS Savings Plan discount.
EC2 Instance Savings Plans
EC2 Savings Plans provides the lowest Savings Plan prices, with savings up to 72% (compared to 66% for Compute SP) to help you reduce your monthly On Demand spend.
However, you need to commit to a specified region and instance family, though you can change instance size, OS, and tenancy.
Amazon SageMaker Savings Plans
SageMaker SP will apply to any ML instance or size, across any region, without manual modifications required.
If you have a consistent amount of Amazon SageMaker eligible usage (measured in $/hour), and use multiple SageMaker components or expect your technology configuration (e.g. instance family, region) to change over time, SageMaker Savings Plans make it simpler to maximize your savings while providing flexibility to change underlying technology configuration based on application needs or new innovation.
How is an AWS Savings Plan applied?
Savings Plans apply to your usage after any Amazon EC2 Reserved Instances (RI) you have are applied, because they are broader. Following the same principle, EC2 Savings Plans are applied before Compute.
Savings Plans are applied first to the usage of the purchaser’s account, then to other accounts in the Consolidated Billing Family. This is known as account affinity and is important to keep in mind.
Savings Plans prioritize covering usage with the highest discount rate(s) first, after purchasing affinity. They will be applied until all usages are accounted for, or until your commitment is met. Any remaining usage will be charged at On-Demand rates. Savings Plans will apply their discount at a lower discount for usage within the purchasing account before it will “float” to another account to cover usage. This is why it’s a best practice to either buy Savings Plans from the Root account, or an empty account specific for this purpose.
The Ultimate Guide to AWS Commitments
How to buy AWS Savings Plans
You can access Savings Plans in the AWS Billing and Cost Management console, or directly by opening the AWS Cost Management console. You can add your selection to your Savings Plans cart from the Recommendations page or from the Purchase Savings Plan page. You can also manage Savings Plans later in the AWS Cost Management Console.
Any existing Savings Plans that has an hourly commitment of $100 or less, purchased in the past 7 days and in the same calendar month can be returned.
EC2 Saving Plan Comparison: Flexible pricing model
Here is a quick comparison of different commitment options to consider. For more information, see Savings Plans vs Reserved Instances: The Ultimate Guide.
| EC2 Instances Savings Plans | Compute Savings Plans | Standard Reserved Instances |
Commitment term | 1 year, 3 years | 1 year, 3 years | 1 year, 3 years |
Best case-scenario savings | 72% | 66% | 72% |
Payment Options | All Upfront, Partial Upfront, and No Upfront payment | All Upfront, Partial Upfront, and No Upfront payment | All Upfront, Partial Upfront, and No Upfront payment |
Instance Family | Any | Fixed | Fixed |
Instance Size | Any | Any | Fixed except regional scopes that use Linux/Unix |
Instance Operating Systems | Any Operating System | Any Operating System | Fixed |
Instance AZ | Any | Any | Any (regional scope) Fixed (zonal scope) |
Instance Tenancy | Any | Any | Fixed |
Applicable to | EC2 only | EC2, Lambda, and Fargate | EC2 only |
Need to reserve capacity? | No | No | Yes (Zonal scope) |
Advantages of Savings Plans
- Compute Savings Plans can apply to any instance, maximizing the value and flexibility of the plan you purchase.
- Savings Plans offer the flexibility to make infrastructure modifications while still receiving discounts.
- A Savings Plan automatically applies to eligible compute usage, regardless of changes to your infrastructure.
- You purchase Savings Plans on a dollar-per-hour basis, not per instance. As a result, SP allows you to purchase compute capacity for as little as a fraction of a cent per hour – one tenth of a cent per hour, to be exact ($0.001/hr).
- SPs offer multiple purchase plans, meaning you have the flexibility to pay upfront or monthly. And, you can schedule them to apply automatically at a later date (called “queuing”).
Maximizing coverage with Saving Plans
Here are some principles you need to keep in mind when determining how to optimize your Savings Plan usage.
1. Isolate the services to be covered by Savings Plans
Savings Plans don’t cover everything — they cover EC2, Fargate, and Lambda. They do not cover non-compute elements such as EBS volumes or data transfer. Many companies look at total EC2 spend when determining the commit level, leading to a lot of unused commit over the term.
When considering how much SP to purchase, you’ll also need to consider your existing commitments. Discounts do not stack — for example, if you’ve already purchased RIs, Savings Plans will apply only to compute not covered by these commitments.
And because discounts don’t stack, Spot is also not eligible for discounting with a Savings Plan.
2. Analyze your On-Demand Compute Costs on an hourly basis
Savings plans apply on an hourly basis, meaning that you’ll need to get fairly granular in your breakdown. Consider using AWS Cost and Usage Reports (free), AWS Cost Explorer (paid), or a free third-party tool such as nOps Business Contexts to track the relevant data and determine estimated monthly savings.
To make things easier, we advise viewing your cloud costs in amortized view. Amortizing is when you distribute one-time reservation costs across the billing period that is affected by that cost. Amortizing enables you to see your costs in accrual-based accounting as opposed to cash-based accounting. For example, if you pay $365 for an All Upfront RI for one year and you have a matching instance that uses that RI, that instance costs you $1 a day, amortized.
3. Recognize that an AWS Savings Plan doesn’t normally cover spikes.
The plans are ideal for a steady and predictable compute spend level. You’ll commit to using the agreed capacity per hour. If you exceed this usage, AWS will use On-Demand billing for extra charges.
Let’s look at an example of a typical usage pattern for illustration.
As you can see, spikes aren’t normally covered by Saving plans. However, the spiky nature of these workloads makes Spot a great option. Once you cover these spikes with Spot, you are essentially “pushing up” your Savings Plan coverage and getting the maximum discount on your usage.
However, you need to ensure you’re moving the right amount of your workload onto Spot. Moving too much usage onto Spot may mean you’re left with unused commitments — meaning wasteful spending. Monitoring usage closely and continually to find the right balance can be difficult.
4. Savings Plans are retroactively applied
One of the technical complexities of AWS cost optimization is that an AWS Savings Plan is retroactively applied 12 hours after the usage already occurs.
To make the best decisions balancing RI, SP and Spot to achieve truly optimal savings, it’s necessary to be aware of all of your usage and commitments across your entire AWS ecosystem at all times.
The challenge is that truly optimizing the placement of your AWS workloads to maximize savings can be complex and time-consuming — requiring dedicated resources and operational expenses to do correctly.
The freeable savings plan
nOps takes the complexity of juggling RI, SP, and Spot off your hands to maximize cost savings with zero engineering effort. You achieve next-level savings with what we call Freeable Savings Plan.
As explained, AWS automatically applies Savings Plans to (1) the account where the RI was purchased first and (2) by the order of highest discount.
In many cases, it would be better to move a workload onto Spot and apply some of the Savings Plan not to the highest discounted usage, but to other, harder-to-cover resources. By “freeing up” Savings Plans to cover these resources, you get a discount on all of your compute for greater overall savings.
And because Savings Plans can apply across your organization, resources even outside of your workload can be covered by freed savings plans.
nOps fully automates this process. It continually monitors Spot market pricing, your dynamic usage, and your existing commitments, to move workloads covered by Savings Plan commitments to Spot when doing so will result in overall cost savings. Simultaneously, it ensures Reserved Instances and Savings Plans don’t go underutilized.
nOps works across your entire AWS organization to eliminate underutilization, squeeze more out of your commitments, and make all your services organization- and Spot market-aware.
Why nOps?
If you commit too heavily, every hour your teams use less than the committed level wastes some of the value you’ve paid for. If you under-commit to a Savings Plan and constantly go over it, you’ll end up paying for extra resources in the highest pricing tier, On-Demand.
nOps was created to solve this problem. Let’s return to the previous graph of typical usage.
nOps is a complete package that delivers you significant cost savings, while freeing up your time from resource management so you can focus on innovation. With nOps, you get:
Cost-optimized compute management. Our AI has real-time awareness of the Spot market, your existing commitments, and your changing usage. It automatically schedules the optimal instance types for your workloads, balancing between Compute SP and Spot to save you the most money.
Utilization guarantee. nOps guarantees that your Savings Plans don’t go unused (illustrated by the red areas on the graph). Or, we’ll fully refund any unused commitments to you for the commitments we manage.
On-demand reliability for Spot. nOps uses ML to predict Spot termination 60 minutes in advance. It selects diverse instances with minimal risk of interruption for the highest standards of reliability. As a result, you can effortlessly run many production and critical workloads on Spot with complete confidence.
No out-of-pocket cost. You pay only a percentage of your realized savings, making adoption risk-free.
No budgeting required. Because we are paid out of the savings, after they are realized, there’s nothing to budget!
The unique thing about nOps is that it lives on the true promise of the cloud. By optimizing all of your usage in real-time and backing you with a credit for any unused commitments we manage, you are freed from the risk of paying for more than you use.
nOps is entrusted with over a billion dollars of AWS spend, and the platform was recently ranked #1 in G2’s cloud cost management category. Join our customers saving up to 50% by booking a demo today!
