Skip to content
What does adding a business context to every dollar of your bill mean?
We all know that Cloud billing is complex. For example, AWS has more than 200 services, billing with per second billing resolution; there are different teams provisioning resources, there are always inconsistencies on how they tag or not tag resources, and there are shared costs like bandwidth cost and/or AWS business support. So how do you allocate all this to the right business units and outcomes?
It’s a challenging problem.
In this blog post, I will walk you through the process of how we use nOps to add a business context to our AWS bill. Just for context, we process close to half-of-billion dollars in AWS spend, and we run our infrastructure on AWS; the challenges we face in our internal environment are similar to what our customers face in their environment. So let me walk you through our process of creating Showbacks to allocate every dollar of our AWS bill.
Is it Prod, Prod Production, or Prod1?
Let’s start with one of the most common problems companies see when allocating costs. We always see inconsistencies in how different teams tag their resources. Take a simple example of a production environment; some teams might call it Prod, others might name it Production, Databrick-productions, and so on. That’s not to mention the occasional typo. This is a common problem we see in infrastructure and for most of our customers.
So rather than trying to implement a perfect tagging strategy, we create policies to account for inconsistencies in tagging.
Here is an example of us mapping different prod environments and mapping it to COGS.
Even trickier are costs that cannot be tagged – like Marketplace purchases or resources that don’t have a clear tagging policy that meets the view. For these, we create a rule that can be based on accounts, regions, specific services, usage types, or even operations. We can choose to wholly allocate these views to a Showback value or even distribute them to different cost centers.
Unallocated Resources to Allocated business context
Now different people in the organization might look at the AWS bill from a different context. As a SaaS company, our CFO needs to precisely allocate the AWS bill between COGS and R&D to determine gross margin accurately. Our CFO also pro-rates AWS Support among the different accounts, business units, and teams. At the same time, our engineering head has a different business context; he needs more granular information, and he looks at a cost in terms of services, squads, or labs. So depending on your role, you create different business contexts.
But no matter what’s your context, you always start with a clean slate–100% of the cost is unallocated. Then you slowly start to allocate the cost by adding tag policies or by adding accounts, certain usage types, or operation types. Every step of the way, you keep moving costs from the unallocated costs bucket to allocating costs to fit your business optic. Once you are done with this exercise, we will have 100% of the cost allocated. Here is a screenshot of our cost 100% allocated.
What about Shared cost?
As I mentioned earlier, there are many line items on your AWS bill, like the purchase of a saving plan or bandwidth cost business support, that needs to be allocated across multiple teams and business units. And depending on the nature of the cost, you might want to spread through across different cost allocations. We have the ability to allocate them based on fixed percentages or weight them based on a percentage of spend, which accounts for variable usage among teams or services.
Here is an example of us distributing our AWS support cost by percent of spend.
Conclusion
I hope you find this blog post helpful. Here at nOps, we envision a world where different teams take control of their cloud consumption, so they can pay for only what they use – not what they provide. So we are constantly building solutions to help our customers optimize cloud costs. Based on our experience, show back provides an effective way to drive accountability and ownership across different team
