How do you enforce Azure tagging and allocate cloud costs reliably?
Asked by
VelvetKite42
Management asked me for a breakdown of last month's Azure spending by department, but Cost Management has been difficult to work with. Tag filters are inconsistent, and many resources appear as "unassigned" in the billing export. Resources deployed by an external vendor are grouped into dedicated resource groups, so those costs are easy to identify. Older resources created by the internal team are much less organized, with untagged storage accounts, NAT gateways, and other resources that have no clear owner. How do you enforce tagging standards and improve cost allocation without manually chasing every resource?
Answers
We maintain an approved tag map for each resource group and run a check before monthly reporting. A remediation job then copies resource-group tags to child resources on a schedule. For costs that do not map neatly to a resource group, we keep a separate service-to-cost-center mapping file. That combination is easier to maintain than expecting every individual resource to be perfect.
Reply to this answer
Pulling detailed cost data through the Azure Cost Management API can make reporting more flexible than the portal. You can combine resource IDs, resource groups, tags, and a maintained ownership map, then schedule weekly checks for new outliers. Automation helps with detection, but it still needs a reliable mapping for legacy resources that were never tagged.
Reply to this answer
PowerShell or another automation tool can enforce the tagging standard across existing resources and flag anything that cannot be classified. There are reusable modules for this, so you do not have to build every check from scratch. I would start in audit mode, identify owners for the unassigned resources, and only move to automatic remediation after validating the exceptions.
Reply to this answer
Azure Policy is a good starting point. Use it to require key tags and inherit tags from the resource group where possible. Be careful with strict deny policies, though—services such as AKS and container platforms may create child resources that do not behave exactly like ordinary deployments. Infrastructure as code can also apply the expected tags consistently at creation time.
Reply to this answer
If your environment is already separated cleanly, reporting at the resource-group level may be more dependable than relying entirely on tags. A common setup is one service or workload per resource group, with each group assigned to a department or cost center. You can still use policy to add useful metadata such as owner and creation date.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions