AWS Cost Categories: what split charge rules can and can't do (2026)

Cost categories are the one AWS allocation feature that works backwards in time, which makes them the natural fix for everything tagging cannot reach. Split charge rules then promise the last mile: take shared costs and divide them across teams. They do that, and there is one sentence in the documentation that determines whether the result is usable in your pipeline. It is worth reading before you build on it.

What is a cost category?

A key-value pair applied to every line item by rule rather than by resource. Per the cost categories documentation: "similar to resource tags, which are key-value pairs applied to AWS resources, a cost category is a key-value pair, applied to every cost line item. The key is the cost category name. The value is the cost category value."

The rules are built from billing dimensions, not from anything on the resource: Account, Charge type, Cost category (another one, for hierarchy), Region, Service, Tag key, Usage Type and Billing Entity. Operations are Is, Is not, Is absent, Contains, Starts with and Ends with, with the last three documented as case sensitive.

Rule order is significant: "cost category rules are evaluated in a top-down order". There are two rule types, and the second is the one worth knowing. A Regular Rule "adds statically defined cost category values". An Inherited Value rule "dynamically inherits the cost category value from the dimension value defined", so pointing it at a tag key generates a category value per distinct tag value automatically. That is how you get a team dimension without enumerating every team in a rule list.

Why are cost categories retroactive when tags are not?

This is the sentence that makes them worth the trouble:

"Cost categories are effective at the start of the current month. If you create or update your cost category in the middle of the month, your change is automatically applied to cost and usage from the start of the month. For example, if you updated your rules for a cost category on Oct 15, any cost and usage since Oct 1 will use your updated rules."

Compare that with tagging, where AWS states "tags are not applied to resources that were created before the tags were created", and where recovering earlier months needs an explicit backfill that can only restore activation status, not tags. Those limits are covered in why cost allocation tags show up empty.

A cost category rule written today reorganises this month's spend from the first of the month, with no resource changes and no waiting. That makes it the right instrument for untagged legacy estate, for accounts you do not control, and for anything where the cost has no taggable resource behind it.

It is month-scoped, though, not unlimited. "Start of the current month" is not "all history", so a category created in October does not reorganise September. And processing is not instant: "after you create or edit a cost category, it can take up to 24 hours before it has categorized your cost and usage information", with a status of Processing until it flips to Applied.

Where do cost categories show up?

Everywhere that matters, which is what makes the split charge limitation later so surprising. "After you create the cost categories, they appear in Cost Explorer, AWS Budgets, AWS CUR, and Cost Anomaly Detection. In Cost Explorer and AWS Budgets, a cost category appears as an additional billing dimension… In AWS CUR, the cost category appears as a new column with the cost category value in each row."

In CUR 2.0 that lands in the tags map under the costCategory/ prefix, alongside resourceTags/, accountTag/, userAttribute/ and iamPrincipal/. So a category named Team is queryable as:

SELECT tags['costCategory/Team'] AS team,
       sum(line_item_unblended_cost) AS cost
FROM   cur2
WHERE  bill_billing_period_start_date = TIMESTAMP '2026-08-01 00:00:00'
GROUP  BY 1
ORDER  BY 2 DESC

Worth noting that AWS's own example output shows a SavingsPlanCoveredUsage row carrying a category value, which is a useful reminder that categories apply to line item types that a naive WHERE line_item_line_item_type = 'Usage' filter would drop.

What do split charge rules do?

They divide a shared bucket across other buckets. From the splitting charges documentation: "splitting charges is useful when you have costs that aren't directly attributed to a single owner", with the examples being shared "data transfer costs, enterprise support, and operating costs".

Three terms, three allocation methods:

Proportional is the one most people want and the one that needs the most thought: it allocates by each target's existing weighted cost, so the team that already spends most absorbs most of the shared cost. That is defensible for a platform whose usage tracks spend, and indefensible for something like a support subscription whose consumption has nothing to do with EC2 footprint. Pick the method to match what actually drives the shared cost.

Where do split charge results actually appear?

Here is the sentence to read before designing anything around this:

"Split charge rules and the total allocated costs are only presented on the cost categories details page. These costs do not appear and don't impact your AWS Cost and Usage Reports, Cost Explorer, and other AWS Cost Management tools."

So the split exists in the console and in a CSV you download from that page, and nowhere else. It is not a column in the CUR. It is not a dimension in Cost Explorer. It will not reach a dashboard, a Budget, an anomaly monitor, or any pipeline that reads the CUR from S3.

This is a sharp and easily missed distinction, because the cost category value itself does reach all of those places. Categorisation propagates; the split does not. A team that builds a chargeback report on the CUR and assumes their split charge rules are reflected in it will ship numbers where shared costs were never distributed at all.

The practical consequence: if your chargeback lives anywhere other than that console page, split charge rules are a cross-check, not a data source. You will be implementing the allocation yourself in your own query, and the feature's value is that it gives you an authoritative AWS-computed number to reconcile your implementation against.

What are the rules about sources and targets?

Two structural constraints, both easy to hit:

• "A cost category value can be used as a source only once across all split charge rules. This means that, if a value is used as a source, it can't be used as a target. If the value is used as a target, it can't be used as a source. A value can be used as a target in multiple split charge rules."
• Values created by Inherited Value rules cannot be used until processing finishes: "you must wait until the cost category status changes to Applied."

The first one rules out chained allocation. You cannot split a networking bucket into a platform bucket and then split platform across teams, because platform would be both a target and a source. Multi-hop cost models common in internal chargeback have to be flattened into single hops.

AWS also recommends a specific ordering, which follows from top-down rule evaluation: "we recommend that you move your cost category values containing shared costs to the top of the rule list… your shared costs are categorized before individual business units are categorized. After these shared costs are categorized, they can then be split across your business units." Get that order wrong and shared costs are absorbed into a business unit before there is anything left to split.

What are the quotas?

From the Billing quotas and restrictions page:

Note the API and console rule limits differ by a factor of five, so a category built through the API can become uneditable in the console. Also note the character restrictions on names, which permit only numbers, Unicode letters, spaces not at the start or end, underscore and en dash. And access is restricted the same way tag activation is: "only the management account in AWS Organizations or individual accounts can create and manage cost categories."

Category or tag?

They are complements, not alternatives. Tags carry ownership that only the resource owner knows. Categories carry structure that only finance knows, and reach cost that has no resource at all: support charges, taxes, marketplace fees, and the shared middleboxes covered in what a NAT Gateway actually costs.

For genuinely shared infrastructure, be honest about which layer solves it. A cost category can label an EKS node group as shared, but only split cost allocation data divides that node's cost across the pods on it, and that division does land in the CUR. Split charge rules are a reporting-layer approximation; SCAD is a billing-layer measurement. Where both are available, prefer the one that reaches your data.