Effective saving rates

Spend any amount of time reading up on Cloud FinOps, and you will eventually come across ESR. (Effective Savings Rate). And yes this is another post about this new(ish), but very important metric in Cloud Cost Optimization. But before you go crazy stressing about yours - which you should at least a little - please don't hit the panic button, and like all things, ESRs should be taken with few grains of salt. Let’s discuss.

What is an ESR?

Once again in an industry full of acronyms to confuse everyone who doesn't work in your tech/development department, this is another. And it's rather simple.

Actual Spend on Compute (Yep, what's on your invoice after all the credits)

/

On-Demand Equivalent Spend (Actual Hours of runtime x cost per on demand hour)

Plugging yours in you will receive a percentage number ranging from (potentially negative) to at the very max positive 35-50% or more. If the latter is the case please promote your engineering leaders who made this happen and give them a raise immediately. If your ESR is low or negative, it deserves a decent bit of investigation and diligence.

What Should Mine Be?

The range is large but lets cover a few common & high level FinOps compute savings strategies first. As for what to expect, different strategies will affect your ESR. Like all things FinOps, it's a mixture of engineering & savings so every organization is unique in what they should expect in their ESR.

Strategy #1 -> “We purchase 1 year RIs for 70-80% of our fleet”

The Good- This is without a doubt the most common strategy. You probably will get a decent chunk of savings. 10-13% ESR is likely what you will see here. You are leaving a lot savings on the table, but at least you’re getting something.

The Bad- There is alot to hate about this strategy. The most common cost savings mistakes are in the “good enough” category and this common strategy is the star of that category. First off, 20-30% savings on machines that you might be able to toggle on/off for more then 20-30% of the month’s hours means you effectively might be spending more money then you need to. Also between the variety of vendor solutions including (shameless plug) North's Savings Plans, you can achieve month-to-month flexibility on your RIs but purchase them at much better discounts. Or if your investment in AWS is going to last more then a year.. Grab a 3 year savings plan. All of the above will yield much better savings and a healthier ESR.

Strategy #2 -> “We turn our machines off to optimize spend”

The Good- This profile won’t see any much or any ESR savings, due to no savings plan in place. On some level this is fine, but you shouldn't compromise company productivity, for pricing optimization.

The Bad- Is everyone ok with applications being unavailable on the nights and weekends?

Strategy #3 -> ”We use a large MSP that manages our savings and instances for us”

The Good- If you’re doing this, you probably are seeing a 10-15% ESR, and thats bad. Like Strategy #1 its just not enough savings. If you’re in this category & you’re seeing 20% or more in ESR you’re doing ok.

The Bad- Do you have an ESR SLA in place with this vendor? You should. If not, you should call us.  This practice is common in large/middle enterprise, and the ESR gets lost in the shuffle. No one wants to look at their electric bill each month, I get it. I suggest a quarterly ESR review, and if you’re getting less than 20% in ESR you should quickly reconsider your strategy.

Overall there are very few scenarios in which you should be viewing anything less than 30% ESR as even close to acceptable.

Pass the Salt!

Okay.. Forget everything above. No I'm just kidding (kind of). However there are only a few scenarios in which ESR is not important, but let's cover them.

First, if your compute environment is time optimized by design. Some applications & environments are sensitive to provide compute power during certain times of the week or during certain events (batch processing environments for example). These will likely show very little or zero ESR and that is ok.

Second, if a high percentage of your environment is supporting stateless K8s or other architectures that will auto scale your clusters up and down, with high variance. A common mix we see is clients using this strategy for 50% or more of the fleet with savings plans for the static workloads. If that is playing out, your ESR will be low and that is ok. ESR’s do not account for the delta of additional on-demand hours that are needed to utilize would be savings plan or RI commitments. Meaning some environments won’t show a great ESR but the “common sense” savings strategy makes sense.

If you’re catching a theme here you’re right. If your ESR is low that's not good. But... I would take extra care in understanding the “as is” usage profiles of your on-demand instances, before you reserve instances with the idea of getting a better ESR. That could in certain scenarios, lead to a better ESR but higher net spend with a bad utilization rate on your reserves. Which is not what you want! (psst, good news is that North automates this calculation for you).

Below is an example of the scenario I am talking about. This rare but possible example shows a client button smashing on new reserved instances without usage profile context. This is where "FinOps" becomes important as a middle zone to give Cloud/Tech buying decisions important context. Your procurement posture of AWS is as dynamic as the Cloud itself, meaning all variables change monthly with immediate impact.

North is a certified AWS partner focused on helping cloud-native customers better manage their cloud economics.