You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One metric we have found useful to track in our org is the share of On-demand EC2 spend or EC2 hours as a %age of the overall EC2 Spend or EC2 hours. Tracking this has helped us to understand how all the various levers (RI, SP, SPOT, etc) have helped to bring down the share of On-demand EC2 over time. The underlying data can be easily pulled from existing tools like AWS Cost explorer. Thoughts?
The text was updated successfully, but these errors were encountered:
The issue with this %age is it is dependant on the shape of your usage. If you have relatively flat variation in the number of EC2 hours throughout the month most of the OnDemand hours can be covered by Savings Plans/RI. However, if you have very spiky EC2 usage (short periods of large scale out) the EC2 usage during those scale out events is not coverable.
With this in mind having a stat that says 60% of all EC2 hours are covered by a rate optimisation program does not tell you if thats a good figure or not, how many of those hours could we have covered.
What we have done is the %age of coverable hours (using the waterline/utilisation target method) covered by rate optimisations.
One metric we have found useful to track in our org is the share of On-demand EC2 spend or EC2 hours as a %age of the overall EC2 Spend or EC2 hours. Tracking this has helped us to understand how all the various levers (RI, SP, SPOT, etc) have helped to bring down the share of On-demand EC2 over time. The underlying data can be easily pulled from existing tools like AWS Cost explorer. Thoughts?
The text was updated successfully, but these errors were encountered: