Chargeback and showback have different requirements and purposes and should therefore be treated as completely separate processes, even when some elements are common to both processes. This blog concentrates on the showback process, and explores the options available for showback within AWS cloud services. We show how Strategic Blue’s customers can construct effective cost-allocation strategies and gain the visibility they require.

Introduction

Showback is the process of identifying, allocating and showing the cost to the various cloud stakeholders. Different stakeholders are likely to have different requirements and need to view their costs in a way that makes sense to them.

 Showback can be used as a forerunner to chargeback, and we detail this approach in the chargeback documentation. It is primarily used as a way to display cloud costs to the various stakeholders so that they understand their costs, can see changes over time and can develop an action plan to manage the costs if needed.

 Cloud costs can be broken down into two components, Direct cost which is clearly identified as belonging to a single cost owner, and a Shared cost which may be distributed across multiple cost owners.

 In the showback process, the direct costs are the most important as they are directly related and controlled by the cost owner.

Showback Allocation Strategy

Principles

The following principles should be part of your allocation strategy:

1. Start simply, and allow your allocation strategies to evolve as your cloud capabilities mature. 
2. Ensure that the effort required to produce your cost allocations is a small proportion of the costs being allocated. Unfortunately, we have seen many businesses spend a disproportionate amount of time and effort to identify, categorize, fully tag and allocate a relatively small amount of cloud spend. 
3. Identify your stakeholder groups and understand how they use the data. Ensure that the frequency and granularity of data matches the requirements.

Business requirements

Potential stakeholders include:

• IT / Cloud Management team
• Product Owners
• Project Managers
• Finance 
• FinOps Practitioners
• Engineering teams
• Business Analyst

It is critical to understand your stakeholders and how they are likely to use the data, so that you can present relevant information. Each showback stakeholder group is likely to have a different use for their data, and this can affect how the costs are distributed and what is included or excluded from the data set.

We have found the following common purposes for the data provided:

If the purpose is budgeting and forecasting, each stakeholder will want complete cloud spend data to model and forecast their future spend. This may include direct and shared costs, or just direct costs. In many cases, the granularity for forecasting data is in the time period, so the hourly/daily/weekly/monthly trends can be understood and extrapolated into the future. 

Usage optimization is normally approached based on the technology being optimized, and so the data required needs a high granularity of technology service and resources used. This data is then grouped by environment, service (application group) or application for wider reporting purposes, and can feed back into the forecasting process. Some teams prefer to use the on-demand costs, rather than the invoiced costs, as this can show the impact made by usage optimization teams. This is particularly true if there are extensive instance commitments, enterprise discounts and credits in use.

Rate optimization showback requirements focus on committable services. The data is usually focused on current coverage and discount, along with potential coverage and discount. This data will inform discussions and decisions on discount vs. flexibility and lock-in to particular resources or technologies. As rate optimization is a corporate-wide process all usage (direct and shared) is normally included.

Business analytics for determining unit economics are generally in the form of cloud cost per business transaction. (e.g. cost per user hour or cost per sale). The showback data is often broken down into a per application or per system basis, where the application or system has the associated data to create the unit value.

Technical requirements

Whatever the business needs and showback charges are, we recommend using the amortized cost throughout the cost allocation process, rather than the invoiced costs, as this provides a couple of benefits:

1. It avoids the ups and downs when upfront payments are made, and avoids the large cost variations within the month due to how costs are charged at the beginning of the month. 
2. It ensures that commitment costs are more accurately attributed. Commitment benefits and commitment costs often occur in separate locations, but using the amortized view automatically attributes the commitment cost and the benefits to the appropriate account and resource.

Using the amortized on-demand equivalent costs can be useful for engineering teams looking solely at managing and controlling usage levels.

Allocating costs

There are several ways to allocate costs. Allocation by Account is the easiest approach, as this provides a natural cost boundary, and everything is automatically within a single Account. However, this needs to be considered when planning your initial deployment, and unfortunately is often an after-thought.

Allocation using Tags should be considered when using Infrastructure as code (IaC), with Tag Editor to manage the key-value pairs. Together, IaC and Tag editor help avoid errors in both the key and the value to provide a more consistent approach. Tags are case-sensitive, which can create issues when tags are manually applied. E.g. CostOwner is different from costowner or Costowner, and ABC-mgmt is different from ABC-management or abc-mgmt 

Uncontrolled and manually applied tags can require a very high effort to apply thoroughly and consistently (breaking principle 2 above). If you use Tags you will need to monitor any untagged resources. Further information is available here.

Allocation by Service, particularly for engineering teams, is straightforward. However, some services (such as EC2) are a mix of compute, storage and networking, so a finer- grained breakdown by usage type may be required to identify the critical costs.

Allocation using AWS cost categories should be considered for complex configurations. Cost Categories allow you to create hierarchical rules for cost allocation and categories using several dimensions, such as account, tag, service, region or charge type. 

Shared Costs

Shared costs are generally not included in the showback process as they are outside of the cost owners’ control and direct influence. However, for completeness, there may be costs shown as shared costs within the showback process. Shared cost allocation is discussed in more detail here.

 Within a showback process, any “shared cost” is often owned by the central IT or Cloud team, and are not distributed, as the central team will have responsibility to manage the costs, as much as possible.

Strategic Blue

As part of our rate optimization service we support four different visualization methods to help our customers understand and allocate their costs accurately, efficiently and effectively. Start your journey with Strategic Blue here.