Smart Tags

Real cloud estates are unevenly tagged, and 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. By default a derived value lives inside ZopNight for cost attribution only, and nothing in your AWS / GCP / Azure account changes until you explicitly apply it to the cloud.

Governance → Smart Tags: the Pending Review, Accepted, and Tag Compliance cards over the Pending Review and Accepted tabs, filterable by provider.

Before you start

• A role with the smart-tags policies to review, accept, and revoke derived values. See Scopes.
• Discovered resources. Values are derived from fields ZopNight already holds for every resource, so no cloud tags are needed to start.
• To apply tags to the cloud: the cloud account at the Read + Write permission level, because the write goes through the provider’s own tagging API.

How it works

How a tagging policy works

A tagging policy enforces one tag key and builds its value from the resource’s own fields (or its existing tags) with a template. For example:

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 (the resource’s 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.

Several policies, one tag key

One policy per tag key is the simple case. You can also point many policies at the same key, each with its own condition, which turns the key into a decision table: one rule per line, each matching a different slice of your estate. This is how you fill in an Application tag from a list of name patterns, for example, rather than trying to express every case in a single rule.

When more than one policy matches a resource, the winner is decided in order: the most specific scope first, then priority (lower numbers win), then whichever policy was created first. So you can add a broad catch-all and layer narrower exceptions above it without rewriting anything.

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.

State	Meaning
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, and 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.

Create a tagging policy

Write tagging policies in Governance → Policies → Tagging, or click Manage tag policies on the Smart Tags page. See Tagging policies for value templates, lookup tables, tag checks, and managing policies in Excel. Derived values appear under Pending Review within seconds of saving.

Review derived tags

The Smart Tags page (Governance → Smart Tags) 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 counts derived values awaiting your decision, and Tag Compliance counts resources breaking a tag rule, so the two numbers 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

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).

Start from	Action
Pending	Accept & apply does both in one step: the value is accepted in ZopNight and written to the cloud resource.
Accepted	Apply to cloud writes an already-accepted value onto the resource. Once written, it shows an on cloud marker. The value is 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 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. ZopNight works out which from the policy itself, so there is no mode switch to set:

Job	What the policy does
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. Accepting a Smart Tag for a required key therefore clears its missing_required violation automatically a short while later, without touching the cloud account. You can also 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.

Where Smart Tags show up

Once accepted, Smart Tags behave like cloud tags everywhere attribution is done:

• Costs → Reports → 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.
• Untagged spend (Costs → Reports → Tags): the Tags view reports untagged cost separately, so accepting Smart Tags on untagged resources moves that spend into tagged values.

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.
• They do not govern your infrastructure code. Tagging policies judge resources that already exist; to catch a missing tag in a Terraform pull request before it merges, see IaC governance, whose policies are attached from Governance → IaC Validations.

Troubleshooting

Next steps