Split shared costs for accurate cloud cost allocation

In every company’s cloud journey, there’s a trigger event that causes them to scrutinize their cloud bill more than they were before.

It may be once you reach a certain monthly spend threshold, a large undetected cost spike occurs, when you’re negotiating a commitment contract with your cloud provider(s), or perhaps when you’re unable to explain spending when asked about it by the exec team or board.

Whatever the event is, cost allocation is your key to unlocking transparency around your cloud spend to manage these situations. Once you allocate costs against your org structure, you’ll be able to easily answer business questions around your cloud spend and nudge engineers towards owning their share of costs.

And while it’s important that you map your cloud costs to your cost centers, there are also shared costs to contend with — think support charges, shared resources (ex. storage), and more.

If you don’t take  shared costs into account when performing cost allocation:

1. You will either under or over-allocate costs to your cost centers,
2. Nobody will take responsibility for those costs, leading them to potentially spiral out of control, and/or
3. Any forecasts or budgets will be based on incomplete data, leading to ill-informed decision making

That’s why we’re excited to introduce Cost Splitting to Cloud Analytics Reports, enabling DoiT customers to easily spread shared and unallocated costs among different stakeholder groups in the DoiT Console

Before we go over how to split shared and unallocated costs in the DoiT Console, let’s quickly review two prerequisites to splitting costs: 

1. Mapping cloud costs to business-specific groupings, and 
2. Combining them together so that we know which cost centers to spread our shared costs among

Mapping cloud costs against your org structure with Attributions

DoiT customers use Attributions to relate cloud costs to their business. An Attribution is a logical grouping of cloud resources (i.e. individual VMs, tags, projects/accounts, etc.). 

With Attributions, you don’t need perfect account structure or tagging to start mapping cloud costs to org-specific categories like products, teams, and more. Or you could enhance your good account structure and thoughtful cost tagging with Attributions and prevent their limitations from stopping you to allocate costs properly.

For example, some cloud services have their own nuances about how costs can be tagged, and to what extent. Google Cloud Storage only features bucket-level labeling, and not per object. That makes it challenging to deal with buckets that are allocatable to multiple entities.

Or you could have a project/account-per-team structure with one or more shared projects that need to have their costs distributed. 

Finally, it’s not possible to retroactively tag costs. Attributions can complement your tagging strategy in all of these cases to help you achieve exhaustive cost allocation.

Example of an Attribution defining an Engineering team’s costs (any resource tagged with “team:engineering” in two accounts)

In the example below, BI Application costs are defined as any resources tagged with a “team” label or project label value corresponding to “BI Application”. 

To view other popular use cases for Attributions, read here.

Example of an attribution defining costs for a BI application

Next, we’ll also define which shared costs are using Attributions. In our case below, we grouped all charges related to AWS and GCP support but shared costs can also include shared resources like storage or Kubernetes costs.

Attribution defining shared cloud costs

Group Attributions and shared costs together

Attribution Groups help you do cost allocation between a common set of Attributions, setting the stage for splitting shared and unallocated costs (costs that aren’t connected to any Attribution in an Attribution Group).

After creating all of the Attributions you’d like to map costs to — in our case all of our applications + shared costs — we now want to put them all into an Attribution Group. 

Below, you can see an Attribution Group “Applications”, containing Attributions representing the costs of three different Applications and our shared costs, along with unallocated costs.

Group of Attributions representing our different Application costs, along with shared costs.

Group of Attributions representing our different Application costs, along with shared costs.

They also allow you to break down a group of Attributions by another group. In the example below, we’re able to break down application costs by environment with two Attribution Groups — one containing application costs and the other containing environment costs.

Splitting shared and unallocated costs

Now we’re ready to split unallocated and shared costs among the three applications we’re looking to track costs for. Take the interactive tour to experience this yourself or follow along below.

To do so, we’re going to build a report using our “Applications” Attribution Group. Then we’re going to click on the vertical ellipsis next to the “Applications” chip and then on “Distribute costs”.

Then, we’re going to split our unallocated costs first by selecting the “Unallocated” item from the dropdown.

You have three options when splitting costs:

• Evenly split - Allocates costs evenly across all selected Attributions.
• Proportional - Allocates costs across your Attributions based on the proportional weighted cost of each selected Attribution.
• Custom - Allocates costs across your targets based on a custom-defined percentage.

We’re going to split unallocated costs evenly among the three Application Attributions.

Finally, we’re going to click “Distribute cost” and re-run the report. We will do this again for our “Shared Costs” Attribution as well.

Below we can view how each team’s costs are split between their actual costs and their portion of shared and unallocated costs.

Now we have a more accurate view of what each team’s costs are responsible for. But in the longer-term you’d want to minimize those unallocated costs (ideally bringing them down to $0) via tagging and/or refining your Attributions.

Conclusion

One of the main FinOps principles is that “Everyone takes ownership for their cloud usage”. But in order for engineering teams to do that, they need an accurate view of their costs. Otherwise, any conclusions they arrive at from an analysis of their cloud costs risk being way off. 

Cost splitting in the DoiT Console allows you to spread shared and unallocated costs among your relevant business units so you can not only drive cost transparency among your cloud users, but accountability as well.

Take the interactive tour, which will take you through creating an Attribution and Attribution Group, and ultimately splitting shared and unallocated costs among them.