In the FinOps space, we often hear customers say things like “as my company grows our compute spend across our EC2 instances and Fargate, containers are becoming hard to manage; what are my options for reducing costs as we grow”?
While trying to comb through the nuances of RI’s and SP’s, you should first make a real assessment of how much you want to manage either program – regardless of the differences.
But first, let’s take a quick look at how they compare:
As you can see, each has a fairly similar savings rate. Each one is suited to a rather narrow range of use cases, but they all help reduce cloud spend.
AWS Savings Plans act like a discount gift card, automatically applying committed dollars to reduce your bill. You specify an hourly dollar commitment amount rather than committing to specific instance configurations. While Amazon’s savings plans feature simplifies capacity planning and provides savings, it is really Amazon’s superficial attempt to appeal to customers' never-ending desire to find a better way to control costs. But as a profit seeking enterprise, it's understandably not entirely in Amazon’s interest to make it foolproof or risk-free.
Let’s explore the basics of Savings Plans.
EC2 Instance Plan - Covers EC2 only with same discounts as Standard RIs (~40-60%), however it is locked to instance family and region (e.g. / R7G / us-east-1)
The Compute Plan - Covers EC2, Fargate and Lambda with roughly the same discounts as Convertible RIs (~30-50%), but spans regions globally, making it more flexible.
A Compute Savings Plan can get discounts on both EC2 and Fargate usage with the same commitment flexibility as RIs. Additionally - unlike RIs, Savings Plans can scale up easily if (or when) your usage grows.
For EC2 workloads running predictable instance types, RIs provide slightly better discounts over Savings Plans. A 3-year all upfront RI could save more than 50%. The keyword here is “predictable”. Personally, having built environments that were intended to be “predictable” didn’t play out as intended. The inevitable feature creep or growth have quickly spoiled my well-laid plans.
Additionally, I’ve been caught in long-term RI’s which have hampered my ambitions of rearchitecting my environment and the extended RI commitment works against these intentions by locking users in. Yes, the reservations, but more overhead to manage.
Another approach is to use Spot. For containerized workloads, you can maximize use of EC2 Spot Instances and Fargate Spot for scaling jobs which can be interrupted. With Spot, you can receive RI-level discounts without the commitment. The challenge here is how tolerant workloads are to disruption. If you are architected within these restrictions, Spot is fantastic. But in-memory databases and numerous other large instances are not a fit.
In general, a combination of savings strategies is a solid approach. Compute Savings Plan for primary Fargate usage, EC2 Savings Plan for EC2 capacity, and Spot for adhoc scaling of both. As usage grows, you may want to re-evaluate the split between Savings Plans and RIs. However, Spot should be a constant for workload flexibility. Monitoring spend and right-sizing commitments will also be key. The risk here is having long-term commitments when AWS releases new technology that improves cpu/hr. Graviton is a good example of this disruption.
After you have mastered the nuances of picking and choosing your savings options, you may realize that your teams’ varied projects and ongoing demands can outpace your ability to successfully position your savings strategy. Transient workloads such as from ML training are not easily covered – as such we typically see customers with only 60-70% coverage rates, despite having an internally planned AWS savings strategy.
Thankfully, we’ve created an advanced FinOps cloud management platform to help, calledOpsNow. OpsNow exists to automate and optimize your cloud spend, track and trend resource utilization, and recommend the best cost coverage strategies. Our goal is to manage much of the complexity of Savings Plan vs RI analysis.
We do this by using a combination of ML models that optimize for coverage, utilization, variability, and growth. The result is a fully managed product called AutoSavings.
AutoSavings effectively automates your spend management over and above what can be done via your own SP and RI commitments. . It provides all of this without any commitment or any cost to utilize the platform
Some other benefits:
- Enables simple workload placement across regions, operating systems and instance types
- Automates savings purchases to maximize discounts without overcommitting
- Eliminates juggling of Savings Plans and RIs.
- Seamlessly adapts to changing needs and workloads workloads
The key realization is that using OpsNow AutoSavings to achieve maximum savings and coverage rates trumps the never-ending effort of manually fine-tuning your own commitments. Our goal is to drive overall cloud savings, while freeing engineers from the challenging (and unforgiving) cost saving’s analysis effort.
While understanding the nuances between Savings Plans and RI's is useful, partnering with OpsNow can alleviate much of your analysis burden.
Connect your cloud accounts today at opsnow.io to see how much you can save.
