Advanced tagging

Auto-tagging is powerful, but raw host metadata is noisy — cloud providers attach dozens of internal tags you don’t want cluttering your taxonomy. Advanced tagging is the filter that decides which self-reported tags are accepted, configured per server agent profile.

Filter modes

Each profile that has server-led tagging enabled sets a filter mode and a set of tag pairs:

Mode	Behaviour
Include	Keep only collected tags whose (group, value) pair is in the filter set. Everything else is dropped.
Exclude	Drop collected tags whose (group, value) pair is in the filter set. Everything else is kept.

If the filter set is empty, all collected tags pass through — the filter only constrains once you populate it.

Matching is on the full key + value pair

This is the detail that surprises people: the filter matches a specific tag, i.e. a group and a value together — not a bare key.

Consider a profile in exclude mode with one filter entry Environments = QA:

• a collected Environments = QA is dropped,
• a collected Environments = UAT is kept (same group, different value).

So excluding one noisy value from a group does not blanket-exclude the whole group. If you want to drop an entire group, add every value you wish to exclude, or use include mode and simply never list that group.

Include mode for a tight taxonomy

On regulated or high-cardinality fleets, prefer include mode. Enumerate the exact tag pairs you want (Environment=production, Team=payments, …) and every other piece of host metadata is discarded at the door. Your taxonomy stays curated no matter what the cloud provider attaches.

Where the filter lives and how it’s applied

The filter is stored against the profile as a set of specific tags (group + value rows), so it always references real, known tags in your organisation rather than free-text strings.

It is applied in two places, defence-in-depth:

1. On the agent, before tags are ever sent. The agent fetches the profile’s pre-enrollment configuration — the filter mode and the list of allowed/blocked {group, value} pairs — and filters locally. If that fetch fails for any reason, the agent proceeds with tagging treated as disabled, so enrollment never breaks.
2. On the backend, at enrollment, the same filter is re-applied to whatever the agent sent. A misbehaving or outdated agent can’t smuggle filtered tags past the server.

How the final tag set is computed

At enrollment the server’s tags are the union of:

• the profile’s assigned tags (always applied), and
• the server-reported tags that survived the filter.

Runtime re-syncs are additive only. The practical consequences:

• Profile-assigned tags are guaranteed on every host, filter or not.
• Turning a value off in the filter stops it being added going forward; it doesn’t retroactively strip hosts that already have it.
• To fully retire a tag from hosts, remove it in the dashboard — the filter governs intake, not deletion.

Worked example

A web-tier profile with server-led tagging on, mode include, filter:

Environment = production
Environment = staging
Team        = platform

A host whose cloud metadata reports Environment=production, Team=platform, aws:cloudformation:stack-name=web-42, CostCentre=1234 enrolls with exactly:

• Environment = production and Team = platform (matched the filter), plus
• whatever tags the web-tier profile assigns directly.

The aws:cloudformation:* and CostCentre tags are discarded — they were never in the include set.

Related

• Tagging & auto-tagging — the sources and the tag-group model.
• Fleet & profiles — enabling server-led tagging.