Set up tag governance

Define the tag taxonomy that drives allocation, coverage, and most cost insights, then drive your estate to compliant.

1. Start from what the recommendations read (Catalog)

Go to Tagging → Catalog. The line under the title says, in resources and in attributable spend, how much of your estate the recommendation engine can read.

The What the recommendations read panel lists the exact tag keys and values the engine matches (environment, schedule, criticality) with a coverage bar per group: production / non-production / unreadable value / no tag. Each gap has a Tag them in Studio button that opens Tag Studio on exactly the resources without that key, with the key already in the action dock. Resources with no environment tag are read from their name, which makes their findings review-only; the panel counts those too. See the next section for what each tag unlocks.

If your cloud tags resources with an environment value we do not know (env=shd, ambiente=homo), the Environment values we cannot read list under the three cards shows each one with its resources and spend. Click Production to have us read it as production, or Non-production (after a confirmation) to read it as non-production. Nothing is written to your cloud: the choice is saved in leancosts only, and you can switch it or delete it in Tag Studio. A non-production choice never overrides a resource your cloud already tags production. The Environment card then shows how many resources you declared, while its bar keeps showing what your cloud says.

2. Govern the tags you use (Catalog)

The Catalog is the authoritative list of governed tags. Each row carries the meaning (description), value mode (free_text or allowed_values), enforcement level (inform → audit → append → deny), required or optional, a coverage line (resources and share of attributable spend carrying the key), and the values in use with two distinct flags:

• unrecognized (red): outside the allowed values you declared;
• no recommendations (amber): on a key the engine reads, a spelling it does not match (develop instead of dev, teste instead of test). Click it to open Tag Studio on those resources. A value you mapped in the Environment values we cannot read list loses the flag.

Recommended keys you have not adopted yet (application, project, environment, squad, cost_center, criticality, schedule, lifecycle, repository, revision) sit at the end of the list with an Add tag button, the fast, non-AI way to a starter taxonomy.

Below the catalog, In your estate, not in the catalog lists the human tag keys your teams already apply that nothing governs, ranked by the spend they cover, each one click from becoming a catalog entry. Keys with almost one value per resource are marked looks like an id so identifiers stay out of the taxonomy.

Tag matching is case- and separator-insensitive: cost-center, cost_center, and Cost Center collapse to one key; prod, PRD, and Production collapse to one canonical value via aliases.

Tip

Tighten enforcement only after the catalog reflects reality, or you’ll flood your coverage numbers with false violations.

3. Tag what unlocks savings

Some of the biggest recommendations we can make are only safe off production: shutting compute down overnight, moving capacity to Spot, dropping geo-redundant storage to local, removing a high-availability replica. We will not propose any of them unless we can tell that a resource is non-production, and your tags are the only honest source for that.

The What the recommendations read panel on the Catalog tab lists exactly what we match, so nothing here is guesswork:

Tag	Keys we read	What it unlocks
Environment	env, environment, ambiente, and tier / stage when they hold an environment word	Off-hours shutdown, Spot, geo-redundancy downgrade, HA-replica removal
Schedule	schedule, autostop, AutoShutdownSchedule, and similar	Stops us recommending a shutdown window you already run
Criticality	criticality, business_criticality	Sets the backup and snapshot retention we hold you to

Three things worth knowing:

• Capitalization never matters. Environment, env and ENV are one key, and Dev, dev and DEV are one value. Separators don’t matter either: Non-Prod, non_prod and nonprod are the same word to us.
• tier and stage are read cautiously. They often hold a SKU tier or a pipeline step rather than an environment, so we act on them only when the value is an environment word we know. tier=dev classifies; tier=Standard is ignored, and we fall back to the resource name as if the tag weren’t there.
• A production value protects the resource. Tag something environment=Production and every non-production recommendation above is withheld for it, even if its name says dev. Your word beats our inference.
• No environment tag at all? We fall back to reading the resource name and the account or project id. That’s a weaker signal, so those findings are marked review-only and carry no ready-to-run change. Tagging the resource is what turns them into something you can act on.

The panel is the live list: read it there rather than trusting a copy, including this one.

System-derived _system.* tags (Azure RG/subscription, AWS account, GCP project) are emitted automatically at ingest: useful for MSP per-tenant pivots even before you author anything. On Tagging → System tags you can promote a system key into the formal taxonomy; it then appears in the catalog.

4. Find the gaps and apply tags (Studio)

Go to Tagging → Studio. The header badge shows your overall tag coverage %, with a chip per required tag below 100%: click one to list the resources without that tag and prefill it in the action dock.

1. Filter the estate by cloud, resource type, free text, an existing tag = value, or without tag key. Tag Studio is cross-cloud: Azure, AWS and GCP resources can be in the same selection.
2. Multi-select the resources to fix (the selection persists across pages).
3. Pick an operation (Set value or Remove key) and a tag key/value.
4. Click Stage change to queue the changes in the Staging workbench, or Copy CLI to get the exact az tag (Azure), AWS tagging, or gcloud label command right away. leancosts never writes tags itself. A few resource types have no label command at all (Cloud SQL, for example): those are listed by name so you can tag them in the cloud console instead.
5. (Optional) Save as change request to log the change to the dual-control ledger for an audit trail.

normalizable (right value, wrong spelling) counts toward coverage as auto-fixable, so the headline percent is “compliant or one alias away”.

5. Review and preview staged changes (Staging)

Go to Tagging → Staging to manage changes you’ve staged before running them.

• Filter the staged queue by cloud, type, operation (set / remove), or tag predicates.
• Each row shows what the engine will read once the change is applied: read as production, read as non-production, unreadable value, or contradicts live … when it would flip a resource’s production protection. The recommendation engine reads a staged tag straight away, so a finding can appear before you run the CLI; running it makes the tag real in your cloud.
• Select a subset and click Get CLI for these to copy the exact provider commands for just those resources.
• Virtual tags are not listed here, because there is nothing to run. A virtual tag lives only in leancosts: save one from Tag Studio’s Save as virtual tag action and it applies to every resource matching the filter, under both the Live and the Planned lens, re-resolving after every sync. It is never written to your cloud.
• Switch /costs to Planned (the toggle in the page header) to see what your cost allocation by tag will look like once the changes land: staged cells appear with a diagonal hatch and an “incl. $X staged” label. Grand totals never change (only re-attribution across tag values).
• After running the CLI in your cloud shell, click Mark applied. The next connector sync will automatically dissolve staged rows whose real tags now match, keeping the queue clean.

Why it matters downstream

Coverage and the canonical tag map feed allocation rules, cost-by-tag pivots, and hunter scoping. Good tags upstream make every other surface trustworthy.