Smart Tags
Policy-driven virtual tags that give under-tagged resources a consistent cost-attribution key; applied inside ZopNight, never written back to your cloud.
Real cloud estates are unevenly tagged. Some accounts have clean cost-center and env tags on everything; others have resources with no tags at all. That inconsistency breaks cost attribution, because showback can only split spend by the tags that exist. Smart Tags close the gap: they derive a consistent virtual tag from a policy you define, so every resource gets an attribution key even when its cloud tags don’t.
Smart Tags; derived values split across Pending Review and Accepted, filterable by provider, managed from a tagging policy.
How a tagging policy works
A tagging policy enforces one tag key and derives its value from the resource’s own fields. You choose which field drives the value:
| Derive value from | Example result |
|---|---|
provider | cloud = aws |
region | region = us-east-1 |
type | workload = rds |
instance_type | size = m5.xlarge |
name | service = payments-api (parsed from the resource name) |
Because the value comes from fields ZopNight already has for every resource, the policy produces a value for every resource in scope; including the ones with no cloud tags at all.
Manage policies from Settings → Policy → Tagging.
Pending vs accepted
A derived Smart Tag doesn’t count toward cost attribution until you accept it. This keeps you in control of what shows up in showback.
Pending
The policy derived a value but you haven’t accepted it yet. Pending values are visible on the Smart Tags page but are excluded from showback and reports.
Accepted
You’ve accepted the derived value. It now counts toward tag attribution in Showback, marked as a derived (Smart Tag) value rather than a native cloud tag.
A derived value is either pending or accepted; anything not yet accepted stays pending. There is no separate “rejected” state; to drop a value, revoke it and it returns to pending.
Reconciliation on every refresh
Smart Tags are re-evaluated on every discovery refresh. An accepted tag is kept only while it’s still derived with the same value. If a resource changes such that the policy would now derive a different value (for example, it moved region), the old accepted value is dropped and the new one returns to pending for you to review. This stops stale attribution from silently lingering.
Reviewing derived tags
The Smart Tags page lists derived values split across Pending and Accepted tabs, each with org-wide counts. From here you can:
- Filter by cloud provider (AWS / GCP / Azure)
- Accept a pending value (per key) so it counts toward attribution
- Revoke an accepted value to return it to pending
Where Smart Tags show up
Once accepted, Smart Tags behave like cloud tags everywhere attribution is done:
- Showback → Tags tab: accepted Smart Tags feed the tag attribution table alongside native cloud tags, labelled as derived values so you can tell them apart.
- Cost Flow Sankey: any layout with a tag-derived dimension reflects accepted Smart Tags.
- Tag Coverage widget: accepting Smart Tags on untagged resources raises your tagged-cost percentage.
What Smart Tags are not
- They are not written back to the cloud provider: no
CreateTags, no label mutation, nothing leaves ZopNight. - They are not a scheduling trigger on their own; they help you find and group resources, but schedules act on the resources you attach. See Scheduling.
- They do not predict stop-eligibility. That heuristic behaviour from the legacy auto-tagger has been removed.