Introduction
Your AWS bill went up again, and finance wants a name next to every large line item. Many of your resources have no tags, so there is nothing to read the name from. If you need to know how to allocate AWS costs without tags, give every account one owner, group shared and untagged spend with Cost Categories rules, split shared costs by direct spend or usage, and turn on split cost allocation data for ECS and EKS. Dentulu is a useful starting point, because its CTO has talked publicly about a bill that got out of hand.
Its CTO, Shiva Kumar, said on The CTO Story podcast that there were times their AWS bill ran about $30,000 a month, and that it came down to roughly $3,000 before settling between $3,000 and $5,000. He did not say how, and we have no inside view of their setup. Any cost cut starts at the same place, though, which is knowing which workload owns which dollars, and that is what goes missing when tags do. Even your largest line items can end up with no owner, and the reason sits in how AWS reports cost.
Why a growing AWS bill has no owner when tags are missing
The reason is that Cost Explorer groups spend by service, account, region and usage type, and it cannot group by team or workload unless the billing data says who a charge belongs to. Tags are the usual label. Without them, the cost lands in a "No tag key" bucket with no owner, so no one reviews it and it keeps growing. Retrofitting tags across hundreds of resources is slow, so aim for an owner on your biggest line items this week. Before you can assign an owner, you need to know which workload the growth came from, and Cost Explorer can narrow that down in five steps.
Which workload is driving your AWS bill
The steps work by elimination. Start with what is left after you remove everything you can already explain.
Open Cost Explorer, set the range to the last three months and group by month.
Group by linked account. If one or two accounts explain most of the growth, you have your first answer.
Filter out the costs that carry a tag, then group what remains by service, then by usage type. NatGateway-Hours and NatGateway-Bytes separate the cost of a gateway existing from the cost of data moving through it.
Switch to the amortized cost view so Savings Plans and Reserved Instance fees spread across the usage that earned them instead of sitting in one lump.
For the top five items, pull the Cost and Usage Report (CUR) or a Data Export to get the resource IDs behind each charge.
Look at data transfer separately. It often shows up as one line item with no link to the resource that caused it, so it stays unallocated longest. You should end up with five to ten charges that explain most of the increase, each with an account, a service and a usage type. That list tells you what is expensive but not who should answer for it. One field on every charge already answers that, and it needs no tags.
How to allocate AWS costs without tags: start with accounts
That field is the account. Every resource lives in an account (a linked account under your AWS Organizations management account), and the account ID is part of its ARN. An account-to-owner table therefore covers everything in that account, even when teams forgot tags. AWS's own cost allocation guidance says account-based allocation takes minimal effort and does not depend on tagging individual resources. Our GCC e-commerce engagement below used the same idea, with a unified resource inventory across accounts and cost ownership assigned to business units.
To set that up, give each account one owning team and one named person or distribution list accountable for its bill. Keep production, staging and development in separate accounts, and give CI workloads their own account. Then sort accounts by monthly spend and assign owners from the top down.
Splitting accounts has a cost, because more accounts also mean more shared networking, such as Transit Gateway or NAT, so do it only where ownership differs. If you already run several, our post on the FinOps multi-subscription framework covers how to organize ownership across them. Accounts settle who pays, but tagged ownership can still go wrong when a pipeline creates the resources instead of a person.
Who owns the spend when a CI role created it
Say a pipeline role creates most of your infrastructure. You enforce an owner tag, coverage looks excellent, and your top cost items all list the same three CI roles as owner. The tag is present and useless, because it names the role that ran the deploy instead of the team that should pay.
Three fixes work without touching every resource. Move CI and temporary test workloads into their own account, bill it to the platform team, and schedule a cleanup. Set the owner value from your infrastructure-as-code metadata (the cost center that should pay) instead of the role that created the resource. And keep a small ownership table that maps a stable ID, such as a service name, to a team.
That table helps with new resources. For an old resource with no clear owner, check the CloudTrail create event to see which pipeline made it. Setting ownership inside the pipeline is DevOps work (see our DevOps solutions) and costs less than chasing owners later. That leaves accounts that several teams share, and there the account ID alone cannot tell you who owns what.
Use Cost Categories to group untagged spend
Cost Categories fill that gap. They map spend to business groups with rules, and a rule does not need a resource tag, so this is how to allocate AWS costs without tags below the account level. According to the AWS documentation, rules can match on account, service, usage type, region, charge type or a tag key, and the result shows up in Cost Explorer, Budgets, the CUR and Cost Anomaly Detection.
A workable setup:
Create a category called Team or Owner.
Add account rules first, then service or usage type rules for shared services (for example, all NAT Gateway usage), then a default value called Unallocated.
Review the Unallocated value every month and work to shrink it.
Cost Categories also work backwards: when you create a category you can apply the rules to any month in the previous 12, so you get history on day one.
Split charge rules go a step further. They spread one value, such as a shared platform account, across other values using a proportional, fixed or even split. AWS documents two limits: up to 10 split charge rules per cost category, and results that appear on the cost category details page instead of in Cost Explorer or the CUR. Check that finance can read the output before you promise a chargeback or showback report. Rules assign a cost to a group, but some charges, such as NAT Gateways and data transfer, have no single team behind them.
Allocate shared and untaggable costs
These shared costs, which also include support plans, commitment fees and shared databases, do not belong to any one team. They are the hardest part of allocating without tags, because there is no resource to point at. Give each one a rule you can explain in one sentence.
Proportional to direct spend. Each team pays a share equal to its share of directly attributable spend.
By usage, where you can measure it. Split NAT and data transfer by traffic share, containers by CPU and memory share, and shared databases by connection or query counts.
To the platform team, openly. If a cost has no fair split, leave it with the platform team and label it shared. A labeled shared cost beats a fake owner.
A worked example with illustrative numbers (not client data): shared networking costs $3,000 a month, and three accounts carry direct spend of $12,000 (payments), $6,000 (search) and $2,000 (internal tools). Proportional allocation gives payments 60% ($1,800), search 30% ($900) and internal tools 10% ($300).
That method is easy to defend and wrong in one way. If internal tools generates most of the traffic but little direct spend, it pays less than it uses. Start proportional, then move to usage-based allocation for the one or two shared costs large enough to argue about. Containers are where usage-based splitting pays off most, because the bill shows an instance while the spend sits in the workloads on it.
Allocate container costs without tags
On ECS or EKS, one instance serves many workloads, so an instance-level bill says little about any single one. Turn on split cost allocation data and AWS divides the amortized instance cost by each container's share of CPU and memory, then writes the result to the CUR. For EKS it also creates cost allocation tags such as namespace and workload name, so you get per-workload cost inside a cluster even when no one tagged a pod. That is the container version of how to allocate AWS costs without tags, and it lets AWS measure usage instead of asking a team to label it. Plan for someone to query the CUR.
That covers workloads where no one tagged anything. Some teams did tag their resources but never activated the tag in billing, and that history may still be recoverable.
Can you backfill cost allocation tags in AWS?
Yes, with limits. Since March 2024 you can backfill activated cost allocation tags for up to 12 months. Only management account users can request it, you can submit one request every 24 hours, and the tag must have been assigned to the resource at the time for data to appear. Older guidance, including parts of AWS's own tagging whitepaper, still says tag activation is not retrospective.
If you tagged resources last quarter but never activated the tag, backfill recovers the history. If a resource was never tagged, it returns nothing, so you still need the account and Cost Category methods above. That gap is where ownership has to be assigned directly, and the GCC e-commerce bill below shows how we did that across more than one account.
What we saw on a GCC e-commerce AWS bill
A fast-scaling e-commerce company in the GCC region was preparing to expand internationally, and its AWS spend sat across more than one account with no single view of it. We built a unified resource inventory across accounts, ran a 90-day spend trend analysis to find anomalies, reviewed idle and misconfigured services, assigned cost ownership to business units, and set up a central FinOps dashboard.
The result was about $6,000 a month saved in 90 days, a reduction of over 25%, with no services going down. The engagement also included automated tagging, so it does not show that tags are optional. The parts that carry over when tags are missing are the cross-account inventory and ownership by business unit. You can read the full case study. How much of this you can do yourself depends mostly on how many accounts you run and how much of the bill is shared.
Ready to allocate your AWS costs without tags and take control of your cloud spend?
At Techieonix, we help SaaS and e-commerce businesses optimize AWS costs with FinOps, AWS cost allocation, Cost Categories, shared cost allocation, and cloud cost optimization strategies. Whether your AWS bill is growing across multiple accounts or your unallocated spend has no clear owner, we can help you identify the biggest cost drivers and build a clear ownership framework. Get in touch with us today for a free AWS cloud cost review.
Talk to an ExpertWhen to do this yourself and when to bring in help
Most teams can do this themselves. With one to three accounts and a bill under roughly $20,000 a month, you can work out how to allocate AWS costs without tags in a week, using Cost Explorer and an account-to-owner table. Outside help pays off when:
You run many accounts and do not control all of them.
Shared platforms such as EKS or shared databases carry most of the bill.
Finance needs a chargeback report that holds up under questions.
The Unallocated bucket will not shrink after the steps above.
If none of these apply, the questions below cover the sticking points that remain.
Frequently asked questions
How do I allocate AWS costs without tags?
Start with accounts and give each one an owner. Then use Cost Categories rules for shared services, split shared costs proportionally or by usage, and turn on split cost allocation data for ECS and EKS. Cost Explorer grouped by account, service and usage type shows where to begin.
Why do I see untagged costs when all my resources are tagged?
Some charges cannot carry a resource tag: Savings Plans and Reserved Instance fees, support, and often data transfer. Usage from before you activated the tag also shows as untagged. The amortized view covers commitments, and backfill covers history.
Why can't I see cost allocation tags in Cost Explorer?
Cost allocation tags have to be activated in Billing from the management (payer) account. Member accounts cannot activate them, and a new tag can take up to 24 hours to appear for activation.
Do AWS Cost Categories require tags?
No. A Cost Category rule can match on account, service, usage type, region or charge type. A tag key is one optional dimension, so Cost Categories work when tagging is incomplete.
How long do cost allocation changes take to show up?
About 24 hours. New tags can take that long to appear for activation, Cost Categories take up to 24 hours to categorize your data, and backfilled tag data refreshes once every 24 hours.
Want help applying any of this?
If your Unallocated bucket will not shrink, or finance needs allocation that holds up, our FinOps team can set this up across all your accounts. We start with a free cloud cost review, with no commitment, and you leave with a list of the charges that explain your increase.
Or see our FinOps service and DevOps services
No tags? No problem. Allocate AWS costs, reduce cloud waste, and give every dollar an owner.