Azure tags are simple key-value labels you attach to resources and resource groups, and they flow into Cost Management so you can group and filter spend by whatever the tags encode — team, project, environment, cost center. For most Azure services that is a routine exercise. For Claude on Microsoft Foundry there is one structural fact you must design around first: the billing meter attaches to the Foundry resource, not to the individual model deployments inside it.
Why resource layout comes before tags
Foundry uses a two-level hierarchy: a resource holds security and billing configuration, and one or more Claude deployments (the model instances you actually call) live inside it. Claude usage bills through a single Azure Marketplace meter — Claude Consumption Units (CCU) — as one line per resource in Cost Analysis. Azure's cost tooling cannot split that line between two deployments sharing a resource, and deployments are not independently taggable billing objects.
The consequence: if two teams share one Foundry resource, no tag strategy can separate their costs in billing reports. Per-model token and request detail exists in the Foundry portal's Monitoring tab, and you can apportion costs manually from it, but that is spreadsheet work, not automated allocation. The clean pattern is one Foundry resource per cost owner:
- Per team or product: each owning team gets its own Foundry resource (usually in its own resource group), with as many Claude deployments inside as it needs.
- Per environment: separate resources for production and non-production, so experimentation never muddies the production cost line.
- Shared-platform teams: if a central platform team fronts Claude for many consumers behind a gateway, attribution has to happen in the gateway's own logs — the Azure bill will only ever show the platform team's resource.
A tag schema that answers real questions
With one resource per cost owner, tags turn Cost Analysis into self-service reporting. Keep the schema small and mandatory rather than large and aspirational:
| Tag key | Example value | Question it answers |
|---|---|---|
cost-center | CC-4211 | Which budget line pays for this? |
team | claims-automation | Who do I talk to about this spend? |
project | doc-triage | Which initiative is consuming Claude? |
environment | prod / dev | Is this production or experimentation? |
Apply the same tags to the resource group and the Foundry resource. Tag values, casing, and allowed keys should be enforced rather than requested: Azure Policy can require tags at creation time or inherit them from the resource group, which is far more reliable than after-the-fact cleanup (see governing Foundry with Azure Policy). Whether a given cost report groups by resource tags or resource-group tags depends on your billing account type and report settings — verify the behavior in your tenant against the Cost Management documentation before promising finance a report.
What tags still won't tell you
Tags allocate the CCU total; they do not explain it. For "why did the claims team's spend double?" you still need per-model, per-deployment detail from the Foundry portal's Monitoring tab, plus the usage object in API responses if you log at request level. And remember that negotiated discounts are applied when tokens convert to CCUs via Azure Marketplace private offers — two identically tagged resources in different subscriptions can pay different effective rates if only one benefits from a private offer.
Where to go next
Pair this with analyzing Foundry spending in Cost Management to build the actual reports, and budget alerts so each tagged owner gets warned about their own overruns.