Define a Tagging Strategy

Why

Tags are the metadata layer that bridges cloud infrastructure and business meaning. Your account hierarchy provides structural cost allocation (who pays), but tags answer the questions structure alone cannot: which project funded this resource, who is accountable for it, and when should it be decommissioned?

Without a tagging standard, cost allocation relies entirely on account structure, which lacks component-level detail. Every downstream capability — showback, chargeback, forecasting, optimisation routing — depends on consistent, machine-readable tags.

What

Produce a published tagging standard that defines:

1. Tag taxonomy — which tags are mandatory, recommended, and optional.
2. Controlled vocabularies — the allowed values for each tag.
3. Application rules — where each tag is applied (account level, resource group level, or resource level) per cloud provider.
4. Governance model — who owns the taxonomy, how changes are approved, and the review cadence.

How

Design the Tag Taxonomy

Follow seven design principles: business-aligned, minimal but sufficient, consistent, machine-readable (lowercase kebab-case), provider-compatible (design for the most restrictive provider — GCP labels: lowercase, max 63 chars), hierarchically applied, and versioned.

Tags fall into four categories serving different stakeholders:

Tag Categories
═══════════════════════════════════════════════════════════════

  FINANCIAL           Consumers: CFO, Finance, FinOps
  (FinOps Core)       → chargeback, showback, budget reports

  OPERATIONAL         Consumers: Eng leads, SRE, on-call
  (Ownership)         → alert routing, ownership, lifecycle

  COMPLIANCE          Consumers: Security, auditors, GRC
  (Security)          → data classification, audit evidence

  TECHNICAL           Consumers: IaC pipelines, automation
  (Automation)        → patching, backup, shutdown schedules

Mandatory tags (must-have):

Recommended tags (should-have):

Define Controlled Vocabularies

Free-text tag values are the number one cause of tagging failure. Every mandatory tag must have a predefined, versioned list of allowed values.

Controlled Vocabulary — Example
═══════════════════════════════════════════════════════════════

  Tag: environment
  Allowed:      prod, stg, dev, sbx
  Owner:        Platform team
  Review cycle: Annual

  Tag: cost-center
  Allowed:      CC-XXXX (pattern match, sourced from GL)
  Owner:        Finance team
  Review cycle: Monthly (synced with GL updates)

  Tag: business-unit
  Allowed:      finance, marketing, engineering, platform,
                sales, legal, hr, data-science
  Owner:        FinOps team (synced with org chart)
  Review cycle: Quarterly (tracks reorgs)

Define Where to Apply Each Tag

Not every tag belongs on every resource. Apply at the highest appropriate level and inherit downward. Three patterns:

Pattern 1: Structural Tags (business-unit, environment)
═══════════════════════════════════════════════════════════════
  Value is the SAME for every resource in the boundary.
  Apply at: Account / Subscription / Project level.

  AWS:   Account tag → activate as cost allocation tag → CUR
  Azure: Subscription tag → Tag Inheritance → cost records
  GCP:   Project label → project.labels in BigQuery export

Pattern 2: Team/Component Tags (application, owner)
═══════════════════════════════════════════════════════════════
  Value differs per team/component within one account.
  Apply at: Resource Group (Azure) or Resource level.

  AWS:   Resource tag via IaC (no RG equivalent)
  Azure: RG tag → Azure Policy inherit to resources
         → Tag Inheritance to cost records (best story)
  GCP:   Resource label via IaC (no inheritance)

Pattern 3: Instance Tags (data-classification, expiry-date)
═══════════════════════════════════════════════════════════════
  Value differs per individual resource.
  Apply at: Resource level on all providers.

Store and Version the Taxonomy

Store the tagging standard in a versioned, accessible location:

Recommended: Git Repository
───────────────────────────────────────────
  /tagging-strategy
    ├── taxonomy.yaml           ← Master tag definitions
    ├── vocabularies/
    │   ├── environment.yaml    ← Allowed values per tag
    │   ├── business-unit.yaml
    │   └── cost-center.yaml    ← Synced from GL via script
    ├── policies/               ← Generated from taxonomy
    │   ├── aws-tag-policy.json
    │   ├── azure-policy.json
    │   └── gcp-org-policy.yaml
    └── CHANGELOG.md

Alternatives: Service Catalogue / CMDB (e.g., ServiceNow, Backstage) for enterprises with existing ITSM processes, or a hybrid approach where Git holds the taxonomy definition and the CMDB serves dynamic values.

Define Governance and RACI

Assign clear ownership for every tagging activity:

Who Does What
═══════════════════════════════════════════════════════════════

  FinOps:      Defines WHAT to tag and MEASURES compliance
  CCoE:        Builds HOW to enforce (tooling + policies)
  Engineering: Actually TAGS their resources and REMEDIATES gaps

Establish cadences: quarterly taxonomy reviews, monthly vocabulary refreshes (cost centres, reorgs), and an annual strategy review against FinOps maturity benchmarks.

Deliverable Checklist

• Published tag taxonomy document (mandatory / recommended / optional)
• Controlled vocabulary registry with owners per tag
• Application rules per cloud provider (where to apply)
• Versioned repository or CMDB entry
• RACI matrix and review cadence defined
• Stakeholder sign-off (FinOps, Platform, Engineering leads)