Public cloud spend waste is now estimated at more than $60B annually! This seriously motivates us since our mission is to automate away the removal of inefficient cloud spend. Our platform feature set has grown over the years to expand the breadth and depth of ways we help customers achieve this – with the ultimate goal of maximizing Effective Savings Rate (ESR). After launching Autonomous Discount Management (ADM) for AWS Compute, we added sophisticated features like Advanced Cyclical Optimization Support, expanded to other AWS services with ADM for RDS, ElastiCache, OpenSearch, Redshift, and MemoryDB, and added support for other clouds with ADM for Google Cloud Compute Engine.
Today, I’m excited to announce the latest feature addition to our platform – Savings Plan Adaptive Laddering for AWS Compute (which includes EC2, Lambda, and Fargate).
Our platform is like an automated personal investing platform for public cloud. Personal investing robo-advisors (e.g., Betterment, who happens to be one of our customers) use algorithms and real-time execution to automate an optimal portfolio of investment instruments (e.g., equities, bonds), implementing advanced strategies like tax loss harvesting, bond laddering, etc. that are difficult to achieve manually. In the same way, our platform automates management of an optimal blend of various commit discount instruments (RIs and SPs on AWS, resource- and spend-based CUDs on Google Cloud), also implementing advanced techniques and strategies that are challenging to achieve without automation. Savings Plan laddering is one such example.
Financial ladders aren’t a new concept and may be familiar to those in the personal investing space. For example, Certificate of Deposit (CD) ladders involve creating a portfolio of CDs with staggered maturity dates that provide continual access to liquidity. At each CD maturity event, that portion of investment can be reinvested back into the CD ladder or withdrawn if needed. The alternative is to batch invest large amounts into a single or several CDs, which locks up your money.
This is not unlike how Savings Plans are traditionally purchased – in large batches. But in the same way as with batch purchasing CDs, this locks you in and doesn’t create frequent events where you have “commitment liquidity”. Savings Plans are simple and powerful, but the downside is they are inherently immutable. Once you make a $x/hr commitment to AWS, you have no recourse to adapt or reduce that commitment if your future usage declines. Adaptive Laddering introduces additional flexibility by purchasing small “rungs” of Savings Plan commitment over time, creating a staggered expiration pattern that allows commitment to be continually repurchased, increased, or expired off as usage changes. Our algorithms watch dynamically changing compute usage patterns in real-time and intelligently adjust type, size, and purchase frequencies to create an optimal, ongoing ladder of Savings Plan commitment that is adaptive.
We’ve had support for Savings Plans in our platform since their launch in 2019, but we’ve seen a few recent changes which have led us to introduce a more sophisticated management strategy:
- The number of customers with heavy serverless compute (i.e., Fargate and Lambda) and smaller amounts of EC2 is increasing. Serverless compute is only discountable with Compute Savings Plans so a blended strategy of RIs and SPs isn’t as effective here. Our own infrastructure falls into this category, so with this new feature release we can now “drink our own champagne” and autonomously optimize our own compute costs. 🎉
- At scale AWS customers sometimes receive private discount rates on RIs and SPs, and those rates can differ. We’ve seen customers with higher private discount rates on SPs than RIs (and vice versa), applied across varying scopes. When SPs provide a superior net savings outcome, it makes sense for an optimal portfolio to be weighted more towards or fully comprised of SPs. This new feature release allows us to better optimize commit discount portfolios when customers have more SP favorable private pricing agreements.
- We’ve historically discouraged the use of EC2 Instance Savings Plans in favor of Standard RIs since the latter delivers identical discounts with the additional ability to be disposed of on the RI Marketplace should EC2 usage of that type unexpectedly decline. AWS has recently made changes which prevent at scale customers who are receiving private/volume Standard RI discounts from using the RI Marketplace. For those customers, EC2 Instance Savings Plans have become a better option. In general, we aren’t beholden to any specific approach and will take advantage of whatever cloud providers make available to maximize Effective Savings Rate.
We originally built our adaptive laddering technology for ADM for RDS, ElastiCache, OpenSearch, Redshift, and MemoryDB, expanded and adapted it for ADM for Google Cloud Compute Engine, and have now ported it to ADM for AWS Compute. As we continue building out a comprehensive multi-service and multi-cloud FinOps automation platform, we are able to reuse algorithms and strategies to expand, deepen, and accelerate our optimization capability set.
To see how this works, let’s look at a simple example:
In both charts that follow, the compute usage over a 12 month period is identical and is shown in purple.
At the beginning of the time period, a 1-year Compute Savings Plan (CSP), shown in green, is batch purchased to cover ~83% of usage. This type of hedging is quite common and creates a buffer in case usage drops. After 4 months of steady usage, an unanticipated activity occurs (due to optimization or reduced consumption), and usage drops below the CSP commitment amount. Because CSP commitment is immutable and was batch purchased, there is no recourse except to let a portion of the commitment go unutilized until it expires at the end of the 12-month period.
Rather than batch purchase a single 1 year CSP, small “rungs” of CSPs (shown in varying colors) have been purchased over time such that a rung is expiring every month. Because we now have a commitment pattern that is adaptive vs. rigid, the first thing we can do is be more aggressive and cover at 100%. Another important difference is that as usage drops and increases over the period, each rung expiration is an opportunity to let the commit fall off or recommit to the ladder. As such, we are able to closely (albeit not perfectly) follow the dynamic compute usage pattern both up and down.
To quantify the savings impact of these different approaches, we can use Effective Savings Rate. If we assume the 1 year CSP delivers a 30% discount, comparative ESRs for this 12 month time period are as follows:
| Effective Savings Rate | |
| Traditional Batch Purchase Approach | 18.6% |
| Adaptive Ladder Approach | 26.0% |
Effective Savings Rate and savings increased by 40% with Adaptive Laddering than with a traditional batch purchase approach!
This is a simple example but the real world is much more complex with multiple changing instance types, compute products, volatility, regions, discount rates, etc. Creating and maintaining an optimal Savings Plan ladder in a dynamic environment is incredibly challenging, but with ProsperOps, Savings Plan laddering is automated and simple to implement with just a few settings!
Bottom line… Our platform now offers another advanced capability which can be used to maximize your savings and help you prosper in the cloud.
Savings Plan Adaptive Laddering for AWS Compute is now available in Early Access. This means we are looking for additional customers with use cases that match what is described above or in general are a good fit for a more Savings Plan heavy commit discount portfolio. Our Early Access program is an opportunity for you to optimize your AWS spend and help us refine our service to better meet your needs. If you are interested in participating, you can express your interest here.
Prosper On! 🖖
Erik
