Tagging is the single most important thing you can do to unlock cost accountability in Azure. Without it, your Azure bill is one undifferentiated number. With a good tagging strategy in place, you can see exactly what every team, product, environment, and workload is costing you — and start holding the right people accountable for the right numbers.
The bad news is that tagging is also one of the most consistently neglected fundamentals. Most organisations have some tags, applied inconsistently, on some resources. That's usually not enough to be useful. This guide covers how to build a tagging strategy that actually works — from deciding which tags to use, to enforcing them, to using them to drive cost allocation.
What Azure Tags Are and How They Work
An Azure tag is a name-value pair that you attach to a resource, resource group, or subscription. For example, a virtual machine might have the tag Environment: Production and the tag Owner: platform-team. Tags are metadata — they don't change how the resource behaves, but they change what you can do with the cost data.
Once resources are tagged, you can:
Filter cost reports by tag in Azure Cost Management
Set budgets scoped to a specific tag value
Allocate costs to teams or business units by tag
Enforce tag presence using Azure Policy
Build chargeback and showback models across the organisation
The key insight: Tagging doesn't save money on its own. What it does is create the visibility and accountability structure that makes saving money possible. It's the foundation the rest of your FinOps practice is built on.
Azure supports up to 50 tags per resource. Each tag name can be up to 512 characters and each value up to 256 characters. Tags are not case-sensitive for lookup purposes, but case is preserved in the display.
One important limitation to understand: not all Azure resources support tags. Some resource types (certain classic resources, some platform services) don't support tagging at the resource level. In these cases, tagging at the resource group or subscription level is the alternative.
Building Your Tag Schema
Before you tag a single resource, you need to agree on which tags you'll use, what values are acceptable, and who's responsible for applying them. A tag schema that hasn't been agreed on across the organisation is just as useless as no schema at all — you'll end up with env: prod, Environment: Production, and environment: PROD all meaning the same thing, which makes filtering and allocation unreliable.
Start with the minimum viable tag set
Don't try to capture everything at once. Start with the tags that give you the most immediate FinOps value and expand from there. A sensible core set for most organisations is:
Tag name | Example values | Purpose |
|---|---|---|
| Production, Staging, Development, Test | Separate prod costs from non-prod; identify waste in dev/test environments |
| platform-team, data-team, payments-squad | Assign accountability for cost to a specific team |
| CC-1234, CC-5678 | Map costs to finance's cost centre structure for chargeback/showback |
| customer-portal, data-platform, migration-2026 | Track cost by project or workload rather than just team |
| ecommerce-api, reporting-service, auth-gateway | Allocate costs to specific applications within a team's portfolio |
Define allowed values for each tag
Open-ended tag values invite inconsistency. Where practical, define a controlled list of allowed values for each tag. Environment should only ever be one of four values — not a mix of prod, Prod, Production, and PRODUCTION. Controlled values are enforced through Azure Policy (more on that below).
Decide on naming conventions
Pick a convention and stick to it. Common choices:
PascalCase:
CostCentre,Owner,Environment— clean and readablekebab-case:
cost-centre,owner,environment— common in engineering-led organisations
Either works. The only wrong answer is using both.
Architect's Perspective — Design Decisions That Affect Tag Coverage
Subscription and resource group design interacts with tagging
If your Azure landing zone is structured so that each team has their own subscription or resource group, you get a degree of cost separation without relying on tags at all. Subscription-level and resource group-level filtering in Cost Management gives you team or workload allocation for free. This doesn't mean you don't need tags — you still want resource-level granularity — but it reduces your reliance on every individual resource being correctly tagged.
If you have a flat structure where many teams share subscriptions and resource groups, tags become even more critical because subscription-level filtering alone won't separate team costs. The messier your landing zone structure, the more disciplined your tagging needs to be.
Inheritance doesn't work the way you think
Azure tags do not inherit from parent scopes. A tag applied to a subscription or resource group does not automatically appear on the resources inside it. This surprises a lot of teams. Each resource needs its own tags — either applied directly, or through automation at provisioning time.
Azure Policy can help push tags from a resource group down to resources within it, but this is a policy you have to configure explicitly.
You also have a Tag Inheritance feature discussed on this page in Azure Cost Management.
Tag at provisioning, not retroactively
Retroactive tagging at scale is extremely painful. If you have hundreds of untagged resources and decide to tag them after the fact, you'll spend significant time identifying who owns what, chasing down teams to confirm values, and dealing with resources that have been orphaned or forgotten. The right approach is to enforce tagging at provisioning time so resources are never created without the required tags. Azure Policy is the mechanism for this.
Don't wait until you have a perfect schema. A common mistake is spending months designing the ideal tag taxonomy while resources continue to be created without any tags at all. Start with three or four tags and enforce them. You can extend the schema later. Gaps in historical data are recoverable; a backlog of thousands of untagged resources is not.
Infrastructure as Code makes tagging much easier
If your team uses Terraform, Bicep, or ARM templates to provision Azure resources, tagging can be embedded in your templates and applied consistently every time. This is the most reliable way to ensure coverage — tags are defined in code, reviewed in pull requests, and applied automatically at deployment. Ad-hoc resources created through the portal are where tag gaps appear, so minimising portal-based provisioning helps too.
Enforcing Tags with Azure Policy
Agreement on a tag schema is not enough — you need enforcement. Without it, resources will be created without the required tags and your cost allocation data will always have gaps.
Azure Policy provides several built-in policy definitions for tag enforcement:
Policy | What it does | When to use it |
|---|---|---|
Require a tag on resources | Denies resource creation if the specified tag is missing | For mandatory tags like |
Require a tag and its value | Denies resource creation if the tag is missing or has an unapproved value | For tags with a controlled list of allowed values |
Inherit a tag from the resource group | Adds the specified tag to a resource if missing, copying the value from the parent resource group | For tags that can be set at resource group level and inherited down |
Append a tag and its value | Adds a tag with a default value if not already present (doesn't deny creation) | For less critical tags where you want a default rather than a block |
Assign your mandatory tag policies at the management group or subscription level so they apply to everything. Start with an Audit effect rather than Deny — this lets you see the scope of the problem without immediately blocking teams. Once you've assessed coverage and communicated the requirement, move to Deny for new resources.
Using Tags for Cost Allocation
Once your tags have reasonable coverage, you can start using them to build cost allocation models. Cost allocation is the process of taking your Azure spend and distributing it to the right teams, products, or business units — turning one large bill into something every stakeholder can understand and own.
Showback vs chargeback
Showback means giving teams visibility into what they're spending without actually billing them internally. This is where most organisations start — it creates awareness and accountability without requiring a formal internal billing process.
Chargeback means actually billing teams internally for their Azure consumption, transferring the cost to their budget. This requires more organisational infrastructure (finance processes, internal billing systems) but creates stronger cost accountability because teams are spending their own budget, not an abstract shared IT budget.
Most organisations start with showback and evolve toward chargeback as their FinOps practice matures.
Handling shared costs
Not everything can be cleanly tagged to one team. Shared infrastructure — networking, security services, monitoring, shared Kubernetes clusters — is consumed by multiple teams but difficult to attribute to any one of them. Common approaches:
Fixed split: Divide the shared cost equally across teams
Proportional split: Divide based on each team's share of total Azure spend
Usage-based split: Divide based on actual consumption metrics (e.g. node usage in a shared AKS cluster)
Central pool: Keep shared costs in a central platform team budget and don't distribute them
There's no universally right answer — the important thing is that you make a deliberate decision and apply it consistently, rather than ignoring shared costs and leaving unexplained spend in your allocation model.
Common Cost Optimisation Uses for Tags
Identify and clean up non-production spend
Once you have an Environment tag with reliable coverage, you can quickly filter to see everything tagged as Development or Test and ask whether it needs to be running at the size and uptime it currently has. Dev and test workloads running at production scale 24/7 are one of the most common sources of avoidable Azure spend.
Find orphaned resources
Resources with no Owner tag — or an owner tag pointing to a team that no longer exists — are often orphaned. Nobody's watching the cost and nobody will notice when it accumulates. Regularly reviewing resources with missing or suspect owner tags surfaces cleanup opportunities that would otherwise be invisible.
Enforce shutdown schedules by environment
With reliable Environment tags in place, you can build automation that shuts down Development and Test resources outside business hours. A dev environment that runs 8 hours a day instead of 24 costs one third as much. Turbo360 Cost Analyzer can automate scheduled scaling and shutdown based on resource metadata including tags.
Set budget alerts per team or project
Scoping Azure budgets to a tag value (e.g. all resources tagged Owner: platform-team) lets each team have their own budget threshold and alert. This distributes cost awareness across the organisation rather than having one central budget that nobody individual feels responsible for.
How Can Turbo360 Cost Analyzer Help?
Turbo360 Cost Analyzer is designed to work with your tagging strategy and make it operationally useful from day one.
Cost views by tag
Cost Analyzer lets you slice and filter your Azure spend by any tag dimension. If you've tagged resources by Owner, CostCentre, or Project, you can immediately build cost views for each team or initiative without building custom reports. This is the core Inform capability — turning tags into visibility.
Spot untagged resources
Cost Analyzer surfaces resources that are missing required tags, so you can identify and remediate coverage gaps. This is particularly useful in the early stages of implementing a tagging strategy, when you're trying to understand the scope of the problem and track improvement over time.
Anomaly detection scoped to tag groups
When a cost anomaly occurs, Turbo360 can surface it in the context of your tag-based cost views — so rather than seeing a spike in total spend, you see which team or project it came from. This makes investigation much faster and gets the right people notified immediately.
Budget monitoring per tag
Set budgets scoped to tag values and configure alerts when a team's spend is trending over threshold. This makes individual teams responsible for their own budget — the accountability model that FinOps depends on.
Scheduled resource management
Use tag-based rules to automate shutdown schedules for Dev and Test environments. Resources tagged Environment: Development can be shut down overnight and at weekends automatically, with no manual intervention required from the teams who own them.
Tag Manager
If you have an environment which changes rapidly and does not have tagging policies in place then the Tag Manager feature can look at your resources and apply missing tags defined in a rule set.
FAQ
How many tags should we use?
Start with as few as you need to answer your most important cost questions — typically three to five tags. More tags create more overhead for teams applying them and more complexity in your enforcement policies. Add tags incrementally as your needs grow. A small set of well-enforced tags is worth far more than a large set of inconsistently applied ones.
What do we do about the hundreds of untagged resources we already have?
Start by enforcing tags on all new resources — this stops the problem getting worse. Then work through existing resources in priority order: start with your highest-cost resources, since those have the biggest impact on your cost allocation accuracy. Use tools like Turbo360 to identify untagged resources and triage them. Accept that you may never achieve 100% retroactive coverage on historical resources, and focus your energy on what's being created going forward.
Should we tag at the resource group level or the resource level?
Both, ideally. Resource group tags give you a level of allocation without relying on every individual resource being tagged. Resource-level tags give you more granular visibility within a resource group. If you have to choose, resource-level tagging is more valuable for cost allocation because it's where the billing data originates. Use Azure Policy or tag inheritance to inherit tags from resource groups to resources to get both with less manual effort.
Do tags affect Azure cost or performance?
No. Tags are purely metadata — they have no effect on how a resource performs, how it's billed, or its availability. The only cost consideration is the time your team spends applying and maintaining them, which is why automation and enforcement policies are important.
Can we use tags for governance beyond cost allocation?
Yes — and this is another reason to invest in tagging. Tags can be used to drive security policies (e.g. all resources tagged DataClassification: Confidential must have private endpoints), compliance reporting, operational runbooks (e.g. backup policies based on environment tag), and access control (ABAC). A good tagging strategy pays dividends well beyond FinOps.
Useful Resources
Turbo360 blog posts
Related playbook pages
Microsoft documentation