How to build a chargeback/showback model for Savings Plans using the CUR
This blog is contributed by Shankar Ramachandran, Solutions Architect, Optimization
Enterprise customers who leverage consolidated billing on AWS often have the need to do internal cost allocation. This can be challenging, particularly when using pricing models such as Savings Plans. In this blog post, we will provide prescriptive guidance on how to build an equitable cost allocation model for Savings Plans (SP) using the data in the Cost and Usage Report (CUR).
Before diving into the details, a quick primer on Savings Plans, CUR and Cost Allocation. AWS introduced Savings Plans in Nov 2019. It is a flexible pricing model that allows customers to save up to 72% on Amazon EC2 and AWS Fargate in exchange for making a commitment to a consistent amount of compute usage (e.g. $10/hour) for a 1 or 3 year term. The CUR contains the most comprehensive set of cost and usage data available. It tracks your AWS usage and provides estimated charges associated with your account. Each report contains line items for each unique combination of AWS products, usage type, and operation (for e.g. RunInstances) that you use in your AWS account. In an AWS context, cost allocation refers to the practice of charging or showing the costs of AWS resource usage back to the different cost centers, lines of business (LOB)/departments/cost centers/products, who consumed those resources.
We will illustrate how to build a cost allocation model through chargeback, and specifically equitable chargebacks, using data in the CUR. The specific fields and the steps described here are applicable to other cost allocation models as well. In the equitable chargeback model, benefits (from SPs) are equitably distributed throughout your cost centers. We will take a concrete example where you are trying to build an equitable chargeback model for your AWS usage between two LOBs. Let’s assume you have a single payer and 2 linked accounts (1 per LOB). There is independent EC2 usage in those linked accounts and in order to reduce costs, you purchased compute SPs at the payer account level. SPs first applies to the account that purchased it and in favor of highest discounts. Hence, based on the type of usage, the benefit of the SP will be applied to where the highest discount is available in either one of two linked accounts. This can result in one LOB receiving a bigger portion of the SP benefit (compared to the other). In the equitable chargeback model, the benefit is equally distributed, irrespective of actual benefit the LOB might have received.
Building an equitable chargeback model for Savings Plans using the CUR
The steps are written in psuedo code style, so that you may be able to adapt them to SQL, R or any other mechanism you are using to process and analyze the CUR. The approach is to answer the questions associated with equitable chargeback models. Also, once you obtain an answer, insert that back in the CUR as new fields, so that the CUR remains the source of truth for AWS cost and usage data. The following flowchart describes the steps to build an equitable chargeback model:
Since this blog is specific to SPs, an important point to note is that SPs can be bought at the linked account level too. If a particular LOB went through the exercise of estimating/forecasting their EC2 usage and purchased SPs to reduce cost for that planned usage, then in the equitable chargeback model, they should see this specific benefit (discount) in their cost and usage data directly applied. In contrast, if the SP is bought at the payer account level, then in the equitable chargeback model, the linked accounts will see the overall benefit (discount) in their cost and usage data applied. The following flowchart describes the steps, taking into account the above scenario:
The CUR can be used to get deep visibility and insights into your cost and usage on AWS, beyond the topic of this blog (chargebacks for SPs). The typical customer journey towards better Cloud Financial Management starts with organizing your AWS environment in terms of your cost allocation and governance foundation with your own tagging strategy. The next step is reporting using resources such as the CUR to raise awareness and accountability of your cloud spend with the detailed, allocable cost data. You can learn more about Cloud Financial Management on AWS here.