Skip to main content
Attribute first, write back later

Untagged spend,
attributed
anyway.

Every tagging initiative dies the same way: it needs the tags to exist before it can show anyone the value. A tagging policy derives the tag from what the resource already tells you, so cost attribution starts before a single write reaches your cloud account.

5derivable fields
Reviewbefore any write
Priorityordered decision tables
Every refreshreconciled

Derive, review, attribute, then write.

In that order, which is why it finishes.

01

Write a policy

Pick the tag key you want enforced and derive its value from the resource's own fields: provider, region, type, instance type and name. Many policies can feed one key, so Application becomes a decision table of name-matching rules imported straight from a spreadsheet.

02

Review before committing

Derived tags arrive as pending. You accept or revoke per key. A derived value that already matches the resource's live cloud tag is accepted automatically, so the work you already did is counted as done instead of queued back at you.

03

Attribute the cost

Accepted tags drive cost attribution inside ZopNight immediately. You can show a team its spend before anyone has agreed to change a single resource in the cloud console.

04

Write back when ready

Apply to cloud pushes accepted tags to the provider as a remediation job. Any tag already matching the live value is skipped, so there are no redundant writes.

When two policies want the same key.

The resolution order is fixed and documented, so the result is reproducible.

Precedence
Scope first, then explicit priority where lower wins, then creation time, then id. A spreadsheet import stamps sheet-row order as the priority, so the sheet's own ordering is the behaviour.
Pending versus accepted
Pending is derived minus accepted. There is no reject state, because a rejected tag and an unaccepted one are the same thing and two words for it would only cause arguments.
Reconciliation
An accepted tag is kept only while it is still derived with the same value. Rename the resource and the tag that was derived from its name is re-evaluated on the next refresh rather than going stale.
Where the tags land
Cost attribution by tag reads both your real cloud tags and the accepted derived ones, tracking which is which. Each tag key and value pair carries the full resource cost, with no splitting.

Show a team its spend this week.

Write one policy, accept what it derives, and the attribution appears without touching your cloud accounts.

Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·