Steven O'Dwyer
ProsperOps
The Effective Savings Rate (ESR) is the Return on Investment (ROI) for cloud discount instruments and the one output metric you can measure true savings performance. This playbook describes the steps to calculating this metric in AWS. Similar, adapted instructions could be applied for calculating ESR for other Cloud Service Providers (CSPs).
ESR should be used by anyone managing commitment discounts to rate optimize on cloud usage costs.
To calculate and utilize an Effective Savings Rate (ESR), access to billing and usage data is a primary requirement. This can include CSP-native tools e.g. AWS Billing and Cost Management, third-party cloud cost management tooling, or custom-built reporting solution offering the required foundational metrics that include commitment discount information such as coverage, utilization, and discount achieved compared to the list, on-demand unit cost. Data sources vary by cloud service provider. Access to detailed billing information including raw data files, billing dashboards, or command line access to cloud billing data is required.
In order to calculate the Effective Savings Rate, data from the cloud service provider will be required, as well as accessible
Tools, Utilities & Templates
Links to tools, utilities, and templates to use during the playbook.
AWS Cost Explorer CLI: You can use the Cost Explorer API to programmatically query your cost and usage data. This offers ‘On Demand Cost Equivalent’ Spend (Pre-Discount) compared to Cost Explorer Dashboard which, at the time of publication, is not available from Cost Explorer.
This play can be run by any Persona with the proper resource access but is typically run by a FinOps Practitioner or an Engineering member.
Run the following AWS CLI commands to extract the required values used in the AWS Compute-specific ESR calculator below:
(Note: End Date is Non-Inclusive.Consider altering the date periods (highlighted) to fit your specific needs)
AWS CLI Command: get-savings-plan-utilization → Returned Values: OnDemandCostOfSPHoursUsed (Step A) & NetSPSavings (Step E):
aws ce get-savings-plans-utilization --time-period Start=2024-05-01,End=2024-06-01 --filter '{ "Dimensions": { "Key": "SAVINGS_PLANS_TYPE", "Values": [ "ComputeSavingsPlans", "EC2InstanceSavingsPlans" ] } }' --query 'Total.Savings.[{OnDemandCostOfSPHoursUsed: OnDemandCostEquivalent}, {NetSPSavings: NetSavings}]'
AWS CLI Command: get-reservation-utilization → Returned Values:OnDemandCostOfRIHoursUsed (Step B) & NetRISavings (Step F):
aws ce get-reservation-utilization --time-period Start=2024-05-01,End=2024-06-01 --filter '{ "Dimensions": { "Key": "SERVICE", "Values": [ "Amazon Elastic Compute Cloud - Compute" ] } }' --query 'Total.[{OnDemandCostOfRIHoursUsed: OnDemandCostOfRIHoursUsed}, {NetRISavings: NetRISavings}]'
AWS CLI Command: get-savings-plan-coverage → Returned Value: OnDemandCost (Step C)
aws ce get-savings-plans-coverage --time-period Start=2024-05-01,End=2024-06-01 --filter '{ "Dimensions": { "Key": "SERVICE", "Values": [ "Amazon Elastic Compute Cloud - Compute", "Amazon EC2 Container Service", "Amazon Elastic Container Service", "Amazon Elastic Container Service for Kubernetes", "AWS Lambda" ] } }' --query 'SavingsPlansCoverages[].Coverage.{OnDemandCost: OnDemandCost}'
Alternatively, using the AWS Console, you can readily get the required values for the ESR calculation from 3 standard reports:
Reservations Utilization Report (Step B and Step F):
Savings Plans Utilization Report (Step A and Step E):
Savings Plans Coverage Report (Step C)
Enter the data shows using the values returned from the CLI calculations, you will calculate the ESR as follows:
PART 1 | Enter Data: |
A. Savings Plan On-Demand Equivalent Spend (EC2, Fargate, Lambda) | |
B. Reserved Instance On-Demand Equivalent Spend (EC2) | |
C. On-Demand Spend (EC2, Fargate, Lambda) | |
PART 2 | |
D. Compute On-Demand Equivalent Spend (A + B + C from above) | |
E. Savings from Compute-related Savings Plans | |
F. Savings from compute-related Reserved Instances | |
PART 3 | |
G. Compute RI & SP Savings (E + F from above) | |
Enter the costs to achieve savings outcome, if any | |
H. Cost to Achieve Savings (CMP, service, time, tooling, etc. cost) |
Effective Savings Rate (G - H) / D (RI & SP Savings minus Costs to Achieve Savings Outcome) / On-Demand Equivalent Spend
Effective Savings Rate = Cloud Savings Generated / On Demand Equivalent (ODE) Spend
Example: $5,000 in SP Savings / $10,000 in ODE Spend = 50% Effective Savings Rate
Effective Savings Rate = Reserved Instance (RI)/Savings Plan (SP) Utilization x RI/SP Coverage x RI/SP Discount
Example: 90% SP Utilization x 100% Coverage x 50% Discount = 45% Effective Savings Rate
A metric isn’t useful unless one can use it to understand how they compare against peers and take action to improve it. Industry research is being conducted to help FinOps teams understand what a good ESR looks like for different types of organizations and across various levels of cloud spend.
Insights from ESR Benchmarking:
Based on a benchmarking analysis performed by ProsperOps, using thousands of anonymized AWS organizations’ data from AWS Cost and Usage Reports, the research found that rate optimization outcomes for AWS compute, including Ec2, Lambda, and Fargate, were generally poor and that there is significant room for improvement.
Median ESR (0%), which meant that organizations paid the on-demand rate rather than leverage discount instruments, such as AWS Savings Plans/ Reserved Instances. Even at the 75th percentile, the ESR was only at 23%, which means orgs generated a 23% discount off the on-demand rate. World-class ESR at the 98th percentile was at 46% though.
Low ESR outcomes may be due to several factors: organizations may be prioritizing engineering optimization before rate optimization, organizations may have a suboptimal rate optimization strategy but not know they can do better, and engineering choices can affect ESR (see Considerations section). Indeed, AWS Savings Plans were the most popular (38% of AWS orgs used them), whereas only 18% used Standard Reserved Instances and 14% used Convertible Reserved Instances.
Best Practices for Benchmarking:
When it comes to best practices for benchmarking ESR data, it is worthwhile to take a look at peers based on industry and usage. ESR and usage appear to be correlated. There might be a number of reasons , including the fact that companies with lower usage may have less resources and expertise in cloud cost optimization. They might also be younger companies with uncertain futures that would choose 1-year commitment terms rather than 3-year terms, which gives them a lower discount.
Taking Action based on ESR Segments:
Below we describe the segments for (1) Negative ESR, (2) Below Average ESR, (3) Low Usage but Above Average ESR, and (4) High Usage with Above Average ESR and provide some suggested actions:
Questions you may want to ask yourself include:
Exceptions and Considerations
ESR may depend on engineering choices. It is important to note that there are engineering choices teams can make that will positively or negatively impact your ESR. For example, AWS provides discounted pricing based on different criteria, including region, instance family, operating system (e.g. Linux, Microsoft), workload volatility, and type of discount instrument used. Google Cloud Platform’s Committed Use Discounts (CUDs) for Compute Engine are also based on machine series (e.g. General Purpose machines – C3, N2). All of these factors can affect your ESR, either favorably or unfavorably.
To illustrate this point, all other things being equal, an AWS instance running a Linux operating system will cost less than an instance running a Microsoft operating system. Likewise. running an instance in the Oregon region will cost less than running the same instance type in Sydney.
We’d like to thank the following people for their work on this Playbook:
We’d also like to thank our supporters, Brian D’Altilio and Jag Sodhi.