Your tagging program follows every recommendation. Tags are enforced through Terraform, mandatory keys are documented, and cost allocation tags are activated in the Billing console. Yet when you group spend by team in Cost Explorer, a substantial share of the bill still falls under “No tag key,” often larger than any single team’s allocation.
That bar is not a compliance problem. Most of what’s in it has no tag to forget, and closing it is an AWS cost allocation problem that tags alone cannot solve.
What are untaggable AWS costs?
Untaggable AWS costs are charges that either have no tag support at all or carry a tag that names the wrong owner. Cost allocation tags never reach them, so their attribution has to happen through allocation rules instead. They fall into a handful of categories, and together they explain most of the unallocated spend that survives even a disciplined tagging program.
If you’re responsible for showback, chargeback, or unit economics, this is the spend that quietly breaks your numbers.
| Category | Why tags fail | How to allocate it |
| Data transfer | Charges inherit the resource owner’s tag, not the traffic’s cause | Proportional to a traffic driver, or compute spend as a proxy |
| NAT gateway processing | One gateway’s tag, every tenant’s traffic | VPC Flow Logs split, or compute footprint proportions |
| RIs and Savings Plans | Discounts float across accounts; commitments bill to the purchaser | Redistribute cost and benefit by eligible usage |
| Support fees | Org-level percentage of the bill, no resource to tag | Proportional to each team’s spend share |
Marketplace, credits, tax | Account-level line items with weak resource association | Owner mapping: distribute credits like the spend they offset |
| Shared platforms (EKS, shared databases) | Taggable, but one tag can’t express multi-tenant ownership | Split by internal consumption metrics |
Why Untaggable Costs exist
Three structural causes, none of which more tagging can fix.
Some charges bill above the resource layer
Support fees are a percentage of your bill charged at the organization level. Credits, refunds, and taxes land on the payer account. There is no resource, so there is nothing to tag.
Some infrastructure is shared, and a tag holds one value
A NAT gateway serves every team in the VPC. A multi-tenant EKS cluster runs workloads from eight teams. The honest answer to “whose cost is this” is a usage-weighted split, and tags have no way to express that. Tagging shared resources to the platform team just turns their cost center into a dumping ground.
Some charges inherit the wrong tag
Data transfer bills against the resources involved, so a load balancer tagged team: platform absorbs the egress costs of every product behind it. The tag identifies the resource’s owner, not the traffic’s cause. The cost looks allocated and is still wrong.
This is why the numbers surprise people: only a small share of AWS resources are truly untaggable, but unallocated spend routinely hits 20 to 40% of the bill, because the biggest offenders are shared platforms and network paths. And it stacks on top of ordinary tag decay, the inconsistent keys and forgotten console resources that erode even taggable spend.
How to allocate untaggable AWS costs: four methods
Four approaches, in order of effort.
1. AWS Cost Categories with Split Charge Rules
Cost Categories group spend into logical buckets using rules over accounts, tags, and services. Split charge rules, then distribute a shared bucket across teams using proportional, fixed-percentage, or even splits at no cost.
Two limits matter in practice:
- Allocated results appear only on the Cost Categories details page, not in Cost Explorer or your CUR.
- Proportional splits can only be weighted by cost, not by a custom driver like request volume.
2. Account Tags for Cost Allocation
Since December 2025, tags applied to AWS accounts in Organizations can be activated as cost allocation tags. They automatically cover all usage in the account, including refunds, credits, and charges that can’t be tagged at the resource level.
If your account boundaries map cleanly to teams, this recovers real spend with almost no effort. It does nothing for shared accounts and shared VPCs, which is where the hard part lives.
3. Proportional Splitting with Your Own Drivers
For everything shared, the pattern is always the same:
- Define the pool (NAT processing charges, the EKS cluster’s total cost).
- Pick a driver that approximates who caused it (compute footprint in the VPC, CPU requests per Kubernetes namespace).
- Write the rule down and get sign-off once.
- Automate the split.
Precision is the wrong goal here. Consistency is the goal: an allocation everyone understands and nobody relitigates beats a perfect model only its author trusts.
4. Custom CUR Processing
Export the Cost and Usage Report into Athena or a data lake and apply your own allocation math. This is the most flexible option and the most expensive to own.
The SQL isn’t the hard part; the hard part is that rules change every reorg, driver metrics need fresh joins every month, and the pipeline lives or dies with the engineer who built it.
Native tooling handles the easy 60–70% of the problem. The remainder, usage-weighted splits, custom drivers, and allocated numbers that show up in every report are where teams either build or buy.
AWS cost allocation tags: best practices
None of this is an argument against tagging. Clean tags make every allocation method above work better. The practices that pay off:
- Activate your tags; don’t just apply them. Applying a tag to a resource and activating it as a cost allocation tag are two separate steps. Activation happens in the billing console; only the management account can do it, and new tag keys take up to 24 hours to appear. Miss this and your tags never show up in Cost Explorer.
- Enforce tags in your IaC pipeline, where enforcement is free. Mandatory tag variables in Terraform modules catch most resources at creation.
- Standardize keys and values before chasing coverage. Consolidating team, Team, and squad into one dimension recovers more attribution than any enforcement push.
- Tag your accounts, not just your resources. Account tags now flow into cost allocation and catch the account-level charges resources can’t.
- Measure allocated share of spend, not tag coverage of resources. They’re different numbers, and the first one is what finance actually cares about.
- Document every allocation rule and revisit quarterly. The failure mode isn’t a slightly wrong driver; it’s an implicit rule that gets relitigated every budget cycle.
- Never let shared costs default to the platform team. It distorts their trend line and poisons showback conversations.
For the full walkthrough on setting these up correctly, from activation to key naming conventions, see our AWS cost allocation tags guide.
Where Economize comes in
Economize picks up where native tooling stops. You group shared costs into pools, choose the teams or products to split them across, and spread them proportionally, evenly, or by weights you define. The rules run continuously across your AWS, GCP, and Azure billing data, and because everything is computed at query time, they apply to historical data too: no backfill, no re-tagging.
Virtual tags normalize inconsistent keys and values the same way, without touching a single resource. Setup is agentless and takes under five minutes.
The result is every team’s fully loaded cost, shared spend included, reconciled back to your actual bill in numbers finance and engineering both trust.
Start a free trial or schedule a demo to see your unallocated spend attributed.
FAQ
1. What are AWS cost allocation tags?
Cost allocation tags are key-value labels on AWS resources that, once activated in the Billing console, organize your spend in Cost Explorer and the Cost and Usage Report. AWS supports two kinds: user-defined tags you create and AWS-generated tags applied automatically. They’re the foundation of cost attribution, and this article covers the spend they can’t reach.
2. What’s the difference between untagged and untaggable spend?
Untagged spend is a compliance gap: taggable resources someone forgot to tag, fixable with enforcement. Untaggable spend is structural: charges with no tag support or tags that name the wrong owner, fixable only with allocation rules. Splitting your unallocated bucket into these two halves is the first diagnostic step, because they have different cures.
3. How much AWS spend typically ends up unallocated?
Architecture matters more than discipline. Organizations with clean per-team accounts often sit at 5 to 15%. Organizations with multi-tenant clusters and shared VPCs commonly see 30% or more, regardless of tag coverage.
4. Do cost allocation tags apply retroactively?
No. Resource tags only allocate costs incurred after activation, so fixing tags today leaves your historical data broken. This is a real argument for handling attribution at the reporting layer, where rules can be applied to past billing data.
5. Should shared costs be allocated for showback or chargeback?
Both. For showback, teams should see their fully loaded cost so the numbers are honest. For a chargeback, expect scrutiny on your driver, so pick one you can defend. The only wrong answer is leaving shared costs unallocated and calling per-team numbers complete.
More Like this
Maximize Cloud Efficiency and Optimize Costs
Get started free in our sandbox or book a personalized call with our experts
