Effective Savings Rate (ESR) is Essential but Insufficient
When we started building our Autonomous Discount Management service in 2018, we needed a way to objectively measure savings outcomes. Since no such metric existed, we created Effective Savings Rate (ESR). Over the past 6 years, ESR has become the de facto standard KPI for rate optimization performance, being broadly adopted by FinOps practitioners, other FinOps tools, and recommended as a best practice KPI by the FinOps Foundation.
However, ESR only tells part of the story. Commitment-based discounts (e.g., RIs, SPs, CUDs, Flexible CUDs) offer savings in exchange for a term commitment, and that commitment has inherent risk. Measuring and quantifying the savings outcome (i.e., the ROI of your commit discount strategy) without considering the risk dimension is helpful but insufficient. ESR is foundational in expressing rate optimization efficacy, but more is required to create a complete view.
Warren Buffett’s Wisdom Applied to FinOps
While contemplating this need, I came across a short video of Warren Buffett explaining the essence of investing. In it, he considers Aesop’s famous saying “A bird in the hand is worth two in the bush,” but points out it’s incomplete. If you’re going to give up a bird in the hand and take a risk to get more birds, you also need to have confidence that more birds are in the bush and know how long it will take to get them out.
According to Buffett, investing can be boiled down to:
- How many birds are in the bush?
- How long will it take to get them out?
- How confident are you in getting them out?
ESR as a standalone metric is like Aesop’s incomplete saying — they both address ROI but leave out risk. I realized the exact two missing risk dimensions Buffett added also apply to cloud rate optimization.
Buffett Principle | Financial Investing | Rate Optimization | FinOps Metric |
How many birds are in the bush? | What is my ROI? | What is my savings rate? | Effective Savings Rate (ESR) |
How long will it take to get them out? | How long will my investment be tied up to get that return? | How long will I be locked in to generate that savings rate? | Commitment Lock-In Risk (CLR) |
How confident are you in getting them out? | What risks impact my ability to generate a return and what is the impact? | If usage unexpectedly declines, will I be overcommitted and what happens to my savings rate? | (stay tuned) |
Introducing Commitment Lock-In Risk
Today, we introduce the first ESR companion KPI, Commitment Lock-In Risk (CLR). CLR quantifies the time dimension risk of committing to a cloud provider in exchange for a discounted rate. This is the first of several blog posts where we’ll explore different aspects of CLR.
CLR is a single number measured in months; the lower the number, the lower the risk. Similar to ESR, CLR is cloud-agnostic and can be used to measure risk for any service with commitment-based discounts. It can also be tracked over time and benchmarked to help FinOps practitioners better understand their risk relative to ESR and to industry peers.
CLR is designed to be used in conjunction with ESR. For example:
Scenario 1
- You batch purchase a single 1-year AWS Compute Savings Plan to cover 70% of your usage
- ESR is 20%
- CLR is 12 months
Scenario 2
- You batch purchase a single 3-year AWS Compute Savings Plan to cover 70% of your usage
- ESR is 35%, which is 1.75x higher
- CLR is 36 months, which is 3x more risk
By taking into account both ESR and CLR, FinOps practitioners have a more balanced view of savings performance and the corresponding lock-in risk to achieve that outcome.
CLR Formula and Example Calculation
In short, CLR considers the amount and distribution of commitment currently in use and derives the maximum risk required over time to achieve the corresponding savings outcome.
To better understand how this works, let’s look at a simple example. Consider Scenario 1 above of batch purchasing a single 1-year AWS Compute Savings Plan (CSP) and assume the following details:
- Current date: 10/29/2024
- CSP expiration date: 8/29/2025
- CSP dollar value: $10/hr
There are 304 days between now and the expiration date, so the current Weighted Average Duration = (304 days x $10/hr) / $10/hr = 304 days = 10.0 months. If we project forward and measure daily Weighted Average Durations for the next 1 year (the longest duration commitment in our portfolio), we get the following 365 values in a data set:
The Commitment Lock-In Risk is the max Weighted Average Duration value in the set which is 12.0 (note, the projection assumes expiring commitment is replaced in kind, which happens on 8/29/25). Conceptually, this means that to achieve and maintain an ESR of 20%, this commitment portfolio of a single 1-year CSP carries a corresponding commitment risk of 12 months.
In future posts, we’ll dive into the rationale behind the CLR formula, more complex examples, how to reduce CLR, and more. We are also working on a third rate optimization metric related to certainty of savings and will share details in the future. Stay tuned!
Commitment Lock-In Risk and ProsperOps
While quantifying lock-in risk with CLR is new, the underlying concept of commitment lock-in isn’t. ProsperOps algorithms have always sought to minimize commitment lock-in, including our newest Adaptive LadderingTM strategies. Now, we can do that even better by optimizing against a specific metric to more effectively achieve those objectives. Our team has been incorporating CLR into our algorithms and automation for some time now, and that will continue as our platform expands.
The introduction of CLR also means ProsperOps customers can now visualize the lock-in risk minimization outcomes from our Autonomous Discount Management service. Today, CLR is available in the ProsperOps Console for the following products:
- Autonomous Discount Management for AWS Compute (EC2, Fargate, Lambda)
- Autonomous Discount Management for RDS
- Autonomous Discount Management for ElastiCache
- Autonomous Discount Management for OpenSearch
- Autonomous Discount Management for Redshift
- Autonomous Discount Management for MemoryDB
This new feature is available to all ProsperOps customers at no additional charge. The benefits of FinOps automation continue to get better and better!
As with ESR, our goal is to broadly share CLR with the FinOps community. We’re excited about CLR and believe it will be as useful to FinOps practitioners as ESR. Our mission is to help all companies prosper in the cloud, whether ProsperOps customers or not, and we are committed to providing examples, education, assets, etc. to enable everyone to be successful with CLR. All questions and feedback are welcome.
Prosper On! 🖖
Erik