#04: How does Commitments Utilisation and Coverage contribute to Cloud Savings?

I often see companies boasting about their cloud commitment-based discounts. They frequently claim that their rate coverage is high, or alternatively, that their utilization of purchased cloud commitments is high. But is this really a good thing?

TL;DR

• Reservation utilization: The percentage of your discount commitments being “used” to reduce the cost of your cloud resources, and Reservation coverage: The percentage of cloud resources “covered” with a discount instrument in your environment.
• To maximize your savings, don't rely on either metric individually. The right balance between the two will yield the highest saving rates.

Defining Commitment Coverage and Utilization

Coverage is the percentage of resources "covered" with a Commitment-Based Discount. For example, if you have 5 EC2 instances running on demand and you purchase a Reserved Instance Commitment for 4 of them, your coverage is 80% (4 out of 5).

Utilization, on the other hand, is the percentage of usage of that commitment. RI commitments are paid for every hour of the year, at minimum. If you use an instance that utilizes this commitment continuously, your utilization is 100%. However, for every hour the instance isn't running, the utilization drops. For example, if you use an EC2 instance covered by an RI commitment for only 10 hours per day, your utilization is 41.67% (i.e., 10/24 hours a day).

So the question remains: Are high coverage or high utilization good indicators? Not necessarily. Let's explore why.

Does High Coverage Mean High Saving Rates?

While it may seem logical that high coverage equates to greater discounts, companies often overcommit in pursuit of high coverage. This overcommitment can actually result in losses, as higher commitments don't always translate to increased savings.

In the examples above, we have the same number of EC2 instances running with RI commitment coverage of 75%, and 100% respectively, but obviously over committing (example 2) cost higher despite the full coverage.

Does High Utilization Mean High Saving Rates?

Ok, so do not over commit, but utilize to 100%, is that the answer?

Again, high utilization does not mean high saving margin as the example above demonstrates, and that is not the only case.

Does High Utilization + High Coverage Mean High Saving Rates?

This is becoming tricky! From the examples above, you can see that the sweet spot involves increasing both utilization and coverage. However, a crucial question remains: What is the optimal ratio of utilization to coverage?

If your compute usage is constant (24/7), maximizing coverage would be ideal. However, most organizations experience variable EC2 usage throughout the day. In such cases, both coverage and utilization become dynamic variables with different savings outcomes.

Now, imagine trying to create a graph that finds the ideal commitment for 1 to 3 years with various savings outcomes. It's a nightmare!

Final Verdict: How Utilization and Coverage Contribute to your Cloud Savings?

It's premature to assume that either coverage or utilization alone can serve as a metric for savings. The answer isn't straightforward. In fact, Standard RIs might even be the wrong choice in some cases. Both coverage and utilization contribute to savings when used in the right ratio and applied using a different Commitment-Based Discounts strategy.

There is a very nice article here showing you the right metric to be used in this case. But I let you enjoy it without any spoilers.

TIP: Do you have a similar problem? Reach out to me privately, I would be more than happy to assist you to find the sweet spot in between 🙂

Summary

Neither utilization nor coverage metrics can be used individually as success metrics for cloud saving rates. A FinOps practitioner should carefully calculate the right balance between both to maximize savings rates in the cloud.

Thanks for reading! Share if you found it helpful. Have questions or suggestions for future topics? We'd love to hear from you!

‍