Tags are labels attached to cloud resources. But deciding which tags are mandatory, what values are valid, who is responsible for maintaining them, and how compliance is enforced — these are governance decisions. And like most governance decisions, the technical implementation is the easy part.
Organisations that approach tagging as a configuration task end up with tag schemas that were never consistently applied, cost reports that nobody trusts, and compliance gaps that cause problems at every audit. Organisations that approach it as a governance decision arrive at a system that actually works — because the people who need to apply it understand why it exists and accept the rules.
A tagging framework is more than a list of tag keys. It covers four dimensions that together determine whether the system works in practice.
What is tagged? Not every resource needs to carry every tag. The framework defines which resource types require which tags — distinguishing between core resources (VMs, storage, databases) and supporting resources (network configurations, security rules). This distinction prevents tag fatigue: teams aren’t asked to maintain 20 tags on a firewall rule.
What values are valid? Free-text values in tags are the beginning of the end. “dev”, “Dev”, “development”, “Development”, and “DEV” all mean the same thing — but from a cost-reporting and automation perspective they are four different values. A good framework defines allowed values for each tag wherever possible, making deviation visible.
Who is responsible? Each tag has an owner: someone who decides what the tag means, maintains the list of valid values, and handles exceptions. Without clear ownership, tags degrade silently — nobody notices when values become inconsistent, because nobody is watching.
How is compliance enforced? Enforcement has two dimensions: what happens when a non-compliant resource is created, and how existing non-compliance is identified and remediated. Both need a defined answer before the first guardrail is activated.
A tag schema that works is one that was designed collaboratively with the people who will apply it. Tags developed in isolation by a central team and then mandated to all teams tend to fail: either they don’t fit real-world needs, or teams don’t understand the purpose and apply them inconsistently.
Start with the questions you need to answer
The best tag schema is derived from the reporting and governance requirements it needs to serve. What cost allocation reports do we need? Who needs to prove compliance ownership? What does automated remediation need to identify? These questions determine the tags — not the other way around.
Involve the teams that will apply tags
Platform team, FinOps, security, and at least two application teams should be in the room. Teams that help design the schema understand its purpose and apply it consistently. Teams that receive a mandate from above apply it reluctantly — and inconsistently.
Define realistic, not ideal, valid values
Valid values should reflect how the organisation actually works — not how it ideally should work. A cost centre tag that requires a code that three teams don’t have yet will produce three non-compliant teams from day one. Work with Finance to ensure the valid values exist in the systems where they need to.
Document what each tag means
Every tag key needs a description: what does it mean, why is it needed, what are the valid values, who owns it? This documentation is the reference teams will consult when they’re unsure. Without it, tags are guesswork.
The most effective tag rollouts start small and expand based on evidence — not on a big-bang mandate that creates compliance theatre rather than real compliance.
The first phase is audit-only: monitoring without enforcement. New and existing resources are checked against the tag schema. Violations are visible but don’t block anything. This phase builds a picture of the current state and gives teams time to understand and apply the schema before it has consequences.
The second phase introduces soft enforcement for new resources: resources without mandatory tags trigger a notification. Teams are informed, given support to remediate, and given a timeline. The purpose is to stop new non-compliance from accumulating while existing non-compliance is being addressed.
The third phase reaches full enforcement: non-compliant new resources are blocked. Existing non-compliance has been remediated or explicitly acknowledged as an exception. The tag schema is now a real governance control, not an aspiration.
A tag catalogue defines which tags are mandatory for every cloud resource — and which values are permitted. Without defined value sets, tags become a free-text field that nobody can filter, report, or enforce automatically.
Five mandatory tags form the minimum standard for a governable cloud environment:
environment — The operational environment of the resource. Enables clear assignment of resources to lifecycle and operational phases.
| Value | Meaning |
|---|---|
prod | Production environment, used by end users or business processes |
dev | Development environment for new features and initial validation |
test | Test environment for functional, technical, or automated testing |
qa | Quality assurance before further release of a solution |
stage | Production-like validation before deployment to production |
uat | User Acceptance Testing by business users or stakeholders |
demo | Demonstration environment for customers, training, or internal demos |
archive | Archived or decommissioned resources still needed for audit or recovery |
int | Integration environment for interface and end-to-end testing |
sandbox | Experimentation and evaluation outside defined development processes |
provisioned-by — How the resource was created. This tag enables detection of resources created outside the IaC process — a critical governance signal.
| Value | Meaning |
|---|---|
iac | Provisioned through Infrastructure as Code (Terraform, OpenTofu, Pulumi, Bicep, CloudFormation) |
portal | Created through a web portal or graphical management interface |
cli | Provisioned through a Command Line Interface |
sdk | Provisioned through a cloud provider SDK |
rest-api | Provisioned directly through the cloud provider REST API |
Resources tagged portal or cli in a production environment signal that someone bypassed the IaC process — exactly the governance visibility this tag is designed to provide.
cost-center — The organisational unit bearing the costs. The value must be a valid identifier from the authoritative finance or ERP system. Only approved cost centre identifiers are permitted.
data-classification — The sensitivity of data processed, stored, or transmitted by the resource. Drives security controls, encryption requirements, and access restrictions.
| Value | Meaning |
|---|---|
public | Public or unclassified information, intended for publication |
internal | Internal information for employees, partners, or authorised third parties |
restricted | Increased protection requirements; unauthorised disclosure causes significant impact |
confidential | High protection requirements; unauthorised disclosure causes serious consequences |
secret | Very high protection requirements; disclosure causes critical consequences |
top-secret | Highest classification; disclosure causes existential or catastrophic consequences |
application-id — The unique identifier of the application from the CMDB or application register. This tag creates the traceable connection from cloud resource to business application.
Two governing principles apply to the entire tag catalogue: tags reference information, they do not duplicate it. A tag points to the authoritative system rather than reproducing its data inline. And tags never replace a CMDB — they reference it. The CMDB holds the full application context; the tag merely establishes the link.
What works
Few, meaningful tags with clear ownership. Valid values defined in advance. Enforcement introduced gradually. Teams involved in design. Exceptions handled through a defined process, not ad hoc overrides.
What fails
Too many tags that nobody understands. Free-text values that fragment reports. Big-bang enforcement that blocks teams before they understand the schema. Tags defined by the platform team alone without input from those who apply them.
Define reporting requirements: What questions should the tag schema answer? Cost by team, environment, project, data classification — these requirements drive the tag design, not abstract best practices.
Design the schema collaboratively: Workshop with platform team, FinOps, security, and representative application teams. Define tag keys, valid values, ownership, and the purpose of each tag.
Document and communicate: Every tag gets a description. The schema is published where all teams can find it. Teams that need to apply tags understand why — not just what.
Audit-only phase: Activate monitoring without enforcement. Understand the current state. Support teams in remediating existing non-compliance. Refine valid values based on what you learn.
Phased enforcement: Starting with the most critical resources, activate enforcement. Handle exceptions through a defined process. Expand to full coverage.
How the tag schema integrates into cost reporting and optimisation is covered in Showback & Chargeback.