$3.1 trillion. That’s how much bad data annually costs the US economy, estimated by IBM. Bad data can have catastrophic effects from completely nuking your finances to rendering any potential insight into your organization impossible. Combine that with the inherent difficulty of analyzing data from your AWS accounts, and you have a worst-case scenario on your hands.

That’s where AWS Cost Categories come to lift the burden.

An invaluable feature in your AWS arsenal, Cost Categories give you the power to automatically sort your data into useful and immediately understandable categories without needing to lift a finger. All you need to do is know what they are and how to set them up to do that.

Hence why this post will cover:

• What are AWS Cost Categories?
• AWS Cost Categories in action
• Where do tags factor in?
• How to set up your categories
• Drawbacks to using AWS Cost Categories
• Alternatives to AWS Cost Categories

Let’s get started.

What are AWS Cost Categories?

AWS Cost Categories are a feature of the AWS Cost Management suite which allows you to group your cost and usage data into custom categories for easier analysis and access.

These Cost Categories operate on rules-based logic to determine where and how your data should be grouped. These rules are highly customizable, letting you create a nuanced view of your organization’s cost and usage data. Once your data is sorted into categories, these defined groups are then represented in many of the AWS-native ways to view your data, such as your Cost and Usage Reports, AWS Cost Explorer, and so on.

While there are some limitations on what your “rules” for these categories can be (mostly due to reasonable limitations on the details of the data you’re collecting), this gives you a fantastic way to plug one of the major holes in AWS’ offering. The main issue this solves is that AWS can be a nightmare to manage and interpret.

Think about it - if you didn’t (or don’t) have a wealth of experience when it comes to AWS, is there any way that you can expect to download your latest Cost and Usage Report and understand any of it?

What about your instances? While there are ways to simplify what you’re paying for when spending money on instances, how long will it take you to separate your data into digestible chunks for, say, your manager, finance department, or CFO for review and justification?

That’s the real power of AWS Cost Categories. Not only do they make it easier for your team to review what’s going on and see where changes need to be made (eg, spending running over budget), they also make your data easier to present when it comes to people who don’t have the AWS knowledge to see what you and your team sees.

AWS Cost Categories in action

Before we get started with seeing the Cost Categories in action, you need to understand that the way that these are set up will largely depend on how your wider AWS organization is arranged. Are you separating accounts by team, by function, or by cost? These distinctions will largely carry over in your categories, which is another reason to be careful when arranging your accounts.

Let’s dive into how AWS Cost Categories work to really show their value.

Let’s say that your AWS accounts are separated by the team they belong to. Team 1 has a few accounts under their belt, Teams 2-3 have similar numbers and closely work together, and Team 4 is much more specialized, leading to fewer accounts.

To help you enforce this distinction at a high level and save you from having to manually separate their data (if, for example, you’ve consolidated your bills), you set up some AWS Cost Categories.

Since your teams are the basis of account separation, it makes sense to divide your data in the same way. So, you set up one Cost Category each for Team 1, Team 2, Team 3, and Team 4, naming them as such to make it easy to tell them apart at a glance. You then map the data for each team into these categories so that everything is automatically arranged that way in the future.

By itself, this isn’t a massive change. You’ve organized your data slightly, but the effort saved on each future report is rather minimal, since those categories match up with your account divisions.

However, you then go on to set up more categories that draw from and combine your data sources in ways that almost auto-analyze your future data for you.

For example, you could set up categories to denote which teams are working together, thus grouping their cost and usage data to show their overall contributions and performance.

This could mean having separate categories for Team 1 and Team 4 (since they work independently of everyone else) but grouping Team 2 and Team 3 together due to their close collaboration. This would allow you to quickly see which endeavors are, in broad terms, costing you the most, and where you might be able to cut costs to stay in budget. In these terms, separating Team 2 and Team 3 wouldn’t make sense because you wouldn’t be able to easily view their total costs and usage data versus the benefits that they’re bringing to your organization.

Where do tags factor in?

Like much of AWS, Cost Categories can get a little confusing when diving into the minutia of the feature. This is especially true if your team is already experienced with and uses AWS tags, and more specifically AWS cost allocation tags.

Tags are unique identifiers (metadata) applied by your engineers to public cloud resources. This is done with the intention of making it easier for your team to identify them, such as showing which team those resources are controlled by, what environment they belong to, and so on.

While this sounds similar to categories, the key thing to remember is that tags serve a different purpose, and at a different scope. Tags are designed for a much more granular approach to your data at the expense of customization and any kind of formulae to filter them. While you can filter, say, your latest CUR to look for multiple tags, you can’t automatically divide your CUR into sections that group your data together based on multiple aspects.

Categories are useful for structured, broad divisions in your organization that are crucial to understanding its health. Tags are a great way to label resources with internal identifiers and to filter the views of your categories in greater detail. Think about it like top-down vs. bottom-up.

With that out of the way, let’s get into a few tips on how to set up your AWS Cost Categories.

How to set up your categories

Before even booting up your computer, you need to know what kind of categories would be best for your organization. The easiest way to see this is to look at your business and the metrics you are expected to report on.

For example, you could start off by separating your data by the team it’s relevant to, but also add categories based on specific product lines, environments, and cost types.

Once you know this, you can set up categories by going into your AWS Billing console and opening the “AWS Cost Categories” section. Create a new category and choose its name - this will be the “at a glance” identifier for that data group, so it needs to be short and obvious such as “Team” or “FinOps”.

Here you can also choose to have your category retroactively apply to your data by selecting the “Apply cost category rules starting any specified month from the previous 12 months” option.

Now comes the tricky part - setting up the rules for your categories. Rules are formulas that apply Cost Category values to your data. These values can be anything from assigning data to a wider Cost Category, or flagging the data with a custom term which can be later used for more granular analysis.

Quick disclaimer, you can create a maximum of 50 Cost Categories, each of which may contain up to 100 rules if you’re using the built-in Rule Builder, or 500 rules with the JSON editor.

We’ll be talking a lot about Cost Category “values”, which is akin to a tag that your rules apply to data they isolate. It’s important to know that these values function as a tag, category, and sub-category all in one - it all depends on what the rule specifies as what it should do when finding data.

When setting up your rules you have the option of using either the Rule Builder or the JSON editor. The editor is great if you’re looking to get extremely specific with your rules, but the Rule Builder will work perfectly for most use cases and doesn’t require you to type the specific syntax, so we’ll focus on that option.

First you’ll have to choose whether to have a “Regular” or “Inherited value” type of rule. Inherited values are only useful when trying to apply your AWS tags or AWS account name to your Cost Categories system, as they simply apply an existing value that data holds to itself in a way the system can understand.

“Regular” rules are going to make up the majority of your library, as these are what govern the data that goes into your categories and sub-categories. The “Team value” field is the label that your rule will apply (the “value” that your rule will create), so name it something immediately recognizable, such as “Team 1”.

Now you can add “Dimension”s to your rule.

These are the logic statements that your rule will follow to isolate the data that you want it to. These are made up of a “Dimension”, an “Operator”, and a final filtered value based on your choice of dimension”. Yes, in true confusing AWS fashion, “Dimension” is the name of a logic statement your rules follow and the type of data that said statement will be checking.

Choose from Account, Service, Charge Type, Tag key, or Cost Category for your Dimension, then select your Operator. You can choose from Is, Contains, Starts with, and Ends with.

Finally, depending on what your initial selections were, you can select the final filtered value which will dictate what logic your rule is made to follow, and thus to what data the new value will be applied.

For example, imagine that you have a Cost Category called “Team” in which you want to identify the different teams that your account data should be attributed to.

To identify and assign the value of “Team 1” to accounts belonging to Team 1, you’d choose the Dimension of “Account”, the Operator of “Is”, and then pick one of your AWS accounts from the filtered dropdown which we’ll call Account 1. This gives your rule the logic of “data from Account 1 will always be given the Cost Category value ‘Team 1’”.

Drawbacks to using AWS Cost Categories

AWS Cost Categories were created to give better structure to AWS financial reporting. The power of Cost Categories to slice and dice your spending data is incredible. There’s just one issue; all corporate financial reporting originates from data in the accounting system. The accounting system is the single source of truth for your FP&A team and does not inherently reflect the data divisions from your Cost Categories.

So let’s say your company wants to report your AWS expenses by team because each team is regionally distributed and the company reports its financials geographically. You can absolutely construct a report in the AWS Billing Console on the basis of the Team Cost Category from our example above, but how are you going to get that data into the accounting system?

Ultimately, data goes into the accounting system through transactions. That means the AWS bill. If the bill is properly split amongst geographies at the time of data entry, then the reporting will be accurate.

Herein lies the problem; the AWS bill contains none of this data, and so it won’t be passed on to the accounting system.

The AWS Billing Console, like all other administrative aspects of AWS, is built for developers. It’s hard to imagine teaching an Accounts Payable clerk how to pull a Cost Category report in order to properly enter the AWS bill, let alone granting that clerk the administrative privileges required in order to do so.

So, while this technique is incredibly powerful, it’s best to think of these Cost Categories as your engineering tool for approximating financial reporting, rather than expecting financial reporting teams to source their data from your AWS Cost Management reports.

In layman’s terms, AWS Cost Categories are (practically) only usable by and visible to your engineering team. They don’t contribute to the efforts of your financial reporting teams.

Alternatives to AWS Cost Categories

If your company’s goal is to divide your AWS bill to make financial sense of your usage, AWS Cost Categories aren’t the tool you need. Instead, try out our AWS Invoice Management Software.

We give you the tools to divide and organize your invoice, following similar rule constructs as you could build with AWS Cost Categories. Then, we automatically deliver that data to your accounting team for easy entry into the accounting system alongside your AWS bill. All of a sudden, your accounting team has all the data they need for advanced financial reporting, and you don’t have to lift a finger to help them understand it.

Need an extra hand in knowing what you need to analyze and which metrics to pay attention to in relation to your business goals? Speak to our friendly AWS Financial Operations Services. Our expert team will draw up a model to develop and maintain cloud financial maturity for you - we handle all of the data gathering, management, and analysis for you.

‍Get your ideal AWS journey started by speaking to the Aimably team today.