Smart Tags: Policy-Derived Tags for Cost Attribution

How a tag gets derived

A tagging policy names a tag key, such as Application or cost-allocation, and says how to compute its value from fields every discovered resource has: provider, region, resource type, instance type and name. Several policies can share one key, which turns them into a decision table: for example a set of “name contains checkout” style rules, imported from a spreadsheet, each mapping to a different Application value.

When more than one policy matches a resource, the winner is decided by scope first, then by an explicit priority (lower wins, and an import keeps the spreadsheet’s row order), then by creation date. The tagging-policy editor lives under Settings, Policy, Tagging.

Pending, accepted, revoked

Derived tags start as pending. You accept them per key, and you can revoke an accepted tag to send it back to pending. There is no separate reject state, because a derivation you disagree with is fixed by changing the policy.

Two rules keep the list honest:

• If a derived value already equals the resource’s live cloud tag, it is accepted automatically. A resource your team already tagged correctly counts as done.
• On every refresh, an accepted tag is kept only while the policy still derives the same value. Rename a resource and its derived tag follows the new facts.

The Smart Tags page shows pending and accepted tags with organisation-wide totals, filterable by AWS, GCP or Azure.

What accepted tags do

Attribution inside ZopNight. Accepted tags feed tag showback alongside real AWS tags, GCP labels and Azure tags, marked with their source so you can tell a derived value from one set in the cloud. The dashboard’s tag coverage widget shows tagged versus untagged spend.

Write-back, on request. Apply to cloud writes accepted tags to the provider through a remediation job. Tags that already match the live cloud value are skipped, so nothing is rewritten for no reason. Write-back needs a read + write cloud account; derivation and attribution work on read-only accounts.

Why derive instead of enforce

Enforcing tags at creation time depends on every pipeline and console user complying. Deriving them from resource facts covers the estate you already have, including resources created before the policy existed.

See showback for how tags become cost views, tagging strategy for choosing keys, and cloud tagging best practices.