Tag Governance: What Our Own Untagged Estate Looks Like

Every article about cloud tagging opens the same way: a statistic about how badly other people tag their resources, followed by advice. This one opens with ours, because we run the same kind of estate as everyone else and it seemed dishonest to grade someone else's homework first.

Our own numbers, first

Measured against our production database on 7 September 2026, across every active resource in every connected account:

• 1,743 active resources
• 1,074 of them carry no tags at all — 61.6%
• 91 carry an owner tag — 5.2%
• 4 carry an environment tag — 0.2%

Four. Not four percent — four resources. If you asked our own platform "show me production spend versus development spend", it could answer for four resources out of 1,743 and would have to say nothing about the rest.

We are publishing that because a tag governance feature written by a team with immaculate tags would be a feature designed for a problem its authors have never had. The parts of this that are hard are hard for us too.

Counting resources and counting dollars disagree, and both are right

The obvious next number is what the untagged resources cost. Over the thirty days to 6 September:

• Resources with at least one tag: $7,696.05
• Resources with no tags at all: $2,721.34

So 61.6% of resources are untagged, but they carry only 26.1% of the spend. Those two figures describe the same estate and they tell opposite stories, and which one you quote depends entirely on what you are trying to prove.

Neither is wrong. They answer different questions. Coverage by resource count tells you how much of your estate is ungoverned — how many things exist that nobody has claimed. Coverage weighted by cost tells you how much of your bill you cannot allocate. A snapshot costing eleven cents a month and an untagged database costing four hundred dollars are one resource each and are not one problem each.

The reason ours diverge so sharply is that untagged resources skew small: EBS snapshots, log groups, volumes, the debris that infrastructure produces automatically and that no human ever named. That is a genuinely good reason to weight by cost when you are deciding where to spend an afternoon — and a genuinely bad reason to ignore the count, because ungoverned small things are how estates accumulate the orphaned spend nobody notices.

CLARITY computes both, as two separate functions rather than one number with a footnote: coveragePercent(taggedResources, totalResources) and costWeightedCoverage(taggedCost, totalCost). Where a screen shows one, it says which.

Six tag keys that are the same tag

Before you can measure coverage you have to decide what counts as the same tag, and that turns out to be where estates quietly break. Run over our own resources, these six keys each exist in more than one spelling:

• Created By and Created by
• Owner and owner
• Project and project
• Role and role
• Service and service
• System and system

Look at the second one. 73 resources carry Owner, 18 carry owner, and not one carries both — so the single dimension you would use to charge costs back to a team is split cleanly across two keys that every tool, including a naive version of ours, treats as two unrelated dimensions. Group your bill by Owner and you silently drop 18 resources. Nothing errors. The report renders. It is simply missing people, and the missing people are the ones whose engineer typed a lowercase o.

AWS resource tags are case-sensitive on the key, so this is not a bug in anyone's cloud — it is two engineers, two Terraform modules, or one engineer on two different days.

The most-used tag key in our estate was not written by us

Sorted by how many resources carry them, our top tag keys are:

• aws:backup:source-resource — 125
• a key named after the business unit that owns most of the estate — 106
• Name — 81
• Owner — 73
• role — 50
• cm-resource-parent — 42
• aws:cloudformation:logical-id, stack-id, stack-name — 42 each
• Project — 38, service — 37

The most common tag key on our estate is one AWS Backup writes automatically. Five of the top twelve are provider- or tool-generated — Backup, CloudFormation, a resource-manager parent link — and every one of them is useful for tracing what created a resource and useless for answering who pays for it.

This matters for a specific reason: a coverage metric that counts "has at least one tag" will happily report a snapshot as tagged on the strength of aws:backup:source-resource, which its owner never chose and cannot be charged to. A resource can be fully tagged and completely ungoverned. That is why a required-tag policy — naming the keys that actually have to be present — is a different question from coverage, and the product treats it as one.

What the feature does

Concretely, and only what is built:

• Coverage, two ways. By resource count and cost-weighted, per service, with a severity band — healthy at 80% or above, warning from 50%, critical below.
• A required-tag policy. You name the keys that must be present; the product lists the resources missing them.
• The untagged list. Not a percentage — the actual resources, so the afternoon has somewhere to start.
• Alias suggestions. The case-collision list above is generated, not hand-written: the product groups tag keys that are identical when lowercased and reports every key with more than one spelling. You then declare which spelling is canonical and coverage is computed against the merged key.

The alias engine deserves a precise description rather than a flattering one, because "intelligent tag suggestions" would be an overstatement of what is a GROUP BY LOWER(key) HAVING COUNT(DISTINCT key) > 1. It finds one class of collision — case — and finds it exhaustively and without false positives. That is the whole capability.

What it does not do

The narrowness is the point, so here is the boundary drawn honestly:

• It does not catch env versus environment. Those are different keys, not different spellings of one, and deciding they mean the same thing is a judgement about your organisation that we are not in a position to make. Suggesting it as a merge would eventually merge two keys that genuinely differ.
• It does not fix anything in your cloud. CLARITY holds read-only credentials and does not write tags. It tells you which resources are missing which keys; the change happens in your Terraform, your console, or your tagging policy.
• It does not judge tag values. A resource tagged Environment: prod and one tagged Environment: Production both count as covered. Value normalisation is a harder problem and we have not solved it.
• It cannot tell you what an untagged resource is for. Nothing can. That information never existed anywhere except in the head of whoever created it.

Where to start

If you take one thing from our numbers, take the gap between 61.6% and 26.1%. Fixing tags in resource-count order and fixing them in dollar order are different projects with different sponsors, and the first meeting goes badly when two people are quoting different figures at each other without knowing it.

The order we would suggest, and are following ourselves: resolve the case collisions first, because it is a one-time declaration that immediately makes every subsequent number more honest. Then set a required-tag policy with two or three keys rather than ten — an owner and an environment will carry most of the value. Then work the untagged list in cost order, and accept that the tail of eleven-cent snapshots is a cleanup task, not a governance one.

We will publish our own figures again when they have moved. If they have not moved, we will publish that too.