A multicloud tagging dictionary is the single source of truth for how you label spend across providers: a short list of mandatory keys, a controlled vocabulary of allowed values, an owner for each key, and a normalization step that reconciles the four providers into one report. Without it, AWS tags, Azure tags, GCP labels, and OCI tags drift into separate dialects, untagged spend climbs past a third of the bill, and no one can answer the only question that matters, which is who owns this cost. The fix is not more tags. It is fewer, enforced, and identical everywhere.
This dictionary is the foundation of every allocation and showback program. Below is the exact key set we deploy, how the four providers differ, how to enforce it, and how to recover an estate that was never tagged.
Why does allocation fail without a shared dictionary?
Every cloud lets teams attach metadata to resources, but each does it differently and none of them enforce a standard for you. One team writes Environment, another writes env, a third writes Stage. One uses production, another prod, another Prod. The bill technically carries tags, but the values do not group, so the allocation report shows a large bucket called untagged or other and a scatter of near duplicate categories. At six figures and up of annual spend, that bucket is the difference between a chargeback that finance trusts and a spreadsheet nobody believes.
The dictionary fixes this by deciding the vocabulary once. There is exactly one key for environment, exactly one set of allowed values, and one owner accountable for keeping it clean. Teams stop inventing schemes because the scheme already exists and is enforced at deploy time.
What keys belong in the dictionary?
Keep the mandatory set small. Five enforced keys allocate the overwhelming majority of spend, and every key you add is a key someone has to populate correctly forever. We standardize on lowercase keys with no separators so they survive every provider, and a controlled list of values for each.
| Key | Purpose | Allowed values (example) |
|---|---|---|
| owner | The team or person accountable for the spend | A team identifier from your directory, never a personal email |
| environment | Lifecycle stage, drives schedule and commitment policy | production, staging, development, sandbox |
| costcenter | The finance dimension chargeback rolls up to | A finance approved code list |
| application | The product or service the resource serves | A registry of named applications |
| dataclass | Sensitivity, drives retention and residency cost decisions | public, internal, confidential, regulated |
Optional keys such as a deployment identifier, a compliance scope, or a sunset date can be added per cluster, but they are advisory. Mandatory means deploys fail or get flagged without them. Advisory means nice to have. Confusing the two is how a dictionary turns into a wish list.
How do tags differ across AWS, Azure, GCP, and OCI?
The four providers do not implement tagging the same way, and the differences are exactly where dictionaries break. Designing for the strictest provider keeps you compatible everywhere.
| Provider | What it calls them | The gotcha |
|---|---|---|
| AWS | Tags | Case sensitive keys and values; tags must be activated as cost allocation tags in billing before they appear in the Cost and Usage Report |
| Azure | Tags | Keys are case insensitive but values are case sensitive; some resource types and classic resources do not inherit tags, so resource group policy matters |
| GCP | Labels | Keys and values are forced lowercase with a restricted character set and a length cap; this is the strictest scheme, so design to it |
| OCI | Tags, with defined tag namespaces | Case sensitive; defined tags live in namespaces and can be enforced centrally, which is an advantage if you use them |
Because GCP forces lowercase and limits characters, a dictionary of lowercase keys and lowercase, separator free values is portable across all four. The last mile is a normalization step in your billing pipeline. The FinOps Foundation FOCUS specification standardizes billing data into one schema, and your tags should be mapped into FOCUS columns so production reads identically whether it originated in AWS, Azure, GCP, or OCI.
How do you enforce the dictionary so it stays clean?
Enforcement is the whole game. A dictionary that lives in a document decays in weeks. Push it into the deploy path so noncompliant resources cannot reach production untagged.
In practice that means policy as code: AWS tag policies in Organizations plus a guardrail that flags or blocks untagged launches, Azure Policy that requires the mandatory keys at resource group level and inherits them down, GCP organization policy with required labels validated in the deployment pipeline, and OCI defined tag namespaces with required values. Layer infrastructure as code checks on top so a module that omits a mandatory key fails review before it ever runs. Then measure tag coverage weekly as a first class metric and route the gaps to the owner, not to a central team that cannot fix other people's resources.
If your allocation report has an untagged or other bucket above five percent of spend, the dictionary is not enforced, it is merely published. Enforced dictionaries drive that bucket toward zero and keep it there.
How do you retrofit tags onto an untagged estate?
Most estates were not tagged from day one, so the dictionary arrives mid life. Do not try to tag everything at once. Work in order of money. Pull the top spending resources from each provider's billing export, tag those first because a small number of resources usually carries most of the cost, and you will allocate the majority of the bill in the first pass. Use account, subscription, project, and compartment structure as a fallback dimension while you backfill, since those boundaries often map cleanly to teams already.
For resources where ownership is genuinely lost, an owner of record on the account or project is better than untagged, and it gives you someone to ask. Set a date after which untagged spend is charged back to the owning account by default. Nothing populates tags faster than spend that lands on a budget when the metadata is missing.
A European SaaS company running across AWS, Azure, and GCP had an untagged bucket near thirty percent and three competing environment keys. We deployed a five key dictionary, enforced it with policy as code, normalized tags into FOCUS columns, and backfilled the top spending resources first. The untagged bucket fell below five percent within the first 90 days, showback finally reconciled to finance, and the clean allocation exposed idle and overprovisioned resources that were part of leaving the estate materially lighter. Figures are verified against billing data and anonymized.
Where this fits in your multicloud program
A tagging dictionary is the data layer under every other cost decision. Once spend is allocatable, showback holds up, commitment coverage can be targeted by team, and KPIs mean something. See how clean allocation feeds multicloud showback that holds up and which metrics to publish in multicloud cost KPIs for the board. The full cross cloud picture lives in the cross cloud cost optimization guide.
Frequently asked questions
What is a multicloud tagging dictionary?
Do tag keys differ across the four clouds?
How many tags do you actually need?
Make your cloud spend allocatable
We design and enforce tagging dictionaries that make spend allocatable across AWS, Azure, GCP, and OCI, then use clean allocation to find the savings underneath. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.