Smart Tags | ZopNight Docs

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; the Pending Review, Accepted, and Tag Compliance summary cards over the Pending Review and Accepted tabs, filterable by provider and managed from a tagging policy.

By default a derived value lives inside ZopNight for cost attribution only — nothing in your AWS / GCP / Azure account changes. When you want the tag on the real resource, an explicit Apply to cloud action writes it to the provider — never automatically. See Applying tags to the cloud.

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.

Applying tags to the cloud

Accepting a value is a ZopNight-only decision — it drives cost attribution but leaves your cloud account untouched. When you want the tag to actually exist on the resource, use Apply to cloud: ZopNight writes it onto the live resource through the provider’s own API (AWS / GCP / Azure).

From Pending

Accept & apply does both in one step — the value is accepted in ZopNight and written to the cloud resource.

From Accepted

Apply to cloud writes an already-accepted value onto the resource. Once written it shows an on cloud marker; it’s counted and live, with nothing left to do.

A few properties keep this safe:

Additive only. Apply sets the policy’s tag; your existing cloud tags are never removed. Revoking a Smart Tag later doesn’t strip the tag from the cloud either.
Always confirmed. Every apply asks first, naming how many tags and resources it will write and on which provider.
Bulk or single. Apply one resource or select many; each resource is written independently, so one failure never blocks the rest.
Not every type yet. Some resource types can’t be tagged from ZopNight and are skipped — they stay detection-only.

Once the write lands, the tag is genuinely on the cloud resource. On the next discovery refresh ZopNight reads it back as a native tag, so the value shows as on cloud and any compliance violation for that key clears at the source.

Tag compliance

A tagging policy does one of two jobs, and ZopNight picks which from the policy itself; there is no separate mode switch to set:

Derive

The policy supplies a value built from resource fields. ZopNight fills the gap by deriving that value where it’s missing; the result is a pending Smart Tag you accept, exactly as above.

Validate

The policy states a rule about a tag rather than a value; a required key, an allowed set of values, or a key that must not exist. ZopNight checks every in-scope resource against the rule and raises a violation wherever the tag doesn’t comply.

Violations surface under the Tag Compliance card on the Smart Tags page — its Review non-compliant link opens the full list, each violation labelled by type so you can see why a resource is out of policy:

Violation	What it means	Example
`missing_required`	The policy requires a tag key and the resource doesn’t have it (on the cloud, or as an accepted Smart Tag).	Policy requires `env`; an EC2 instance has no `env` tag.
`value_not_allowed`	The tag key is present but its value isn’t in the policy’s allowed set.	Policy allows `env ∈ {prod, staging, dev}`; a resource is tagged `env = production`.
`forbidden`	The tag key is present but the policy says it must not be.	Policy forbids `owner`; a resource still carries a legacy `owner` tag.

A tag counts as present whether it lives on the cloud resource or you’ve accepted it as a Smart Tag. So accepting a Smart Tag for a required key clears its missing_required violation automatically a short while later, without touching the cloud account — or you can Apply to cloud to write the tag onto the resource and fix it at the source. Accepting never hides a wrong value, though; a value_not_allowed or forbidden violation stays until the actual tag is corrected on the resource.

Only resources the policy’s scope selects are judged; a policy scoped to one account or resource type never raises violations elsewhere. Compliance is re-evaluated on every refresh alongside derivation, so a violation clears automatically once the tag is fixed (or the policy changes), the same way an accepted value is reconciled below.

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 opens on two tabs — Pending Review and Accepted — with a row of summary cards above them: Pending Review, Accepted, and Tag Compliance, each with its own org-wide count. Pending Review and Tag Compliance answer different questions; Pending Review is “derived values awaiting your decision”, Tag Compliance is “resources breaking a tag rule”, so the two counts are unrelated and won’t match. The Review non-compliant link on the Tag Compliance card opens the violations. 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
Apply to cloud — write an accepted value onto the real resource, one at a time or in bulk
Review compliance violations by type, and clear a missing_required one by accepting a Smart Tag for that key

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 to the cloud provider unless you ask. A derived value stays inside ZopNight until you explicitly Apply to cloud — there is no automatic or silent write-back.
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 or any other resource behaviour — a Smart Tag is only an attribution label, never a signal about what a resource does.