Smart Tags: Deriving Missing Tags From Resource Data

Automated tagging means applying tag values by rule instead of by hand. It exists because enforcement at creation never reaches everything: resources that predate the tagging standard, resources launched by tools that do not pass tags through, and resources whose owner can be inferred but was never written down. Smart tags are ZopNight’s form of automated tagging: virtual tags derived from policies, reviewed by a person, and used for cost attribution.

What cloud providers automate natively

Each provider automates part of the problem, and it helps to know where that stops:

• AWS can apply the AWS-generated aws:createdBy cost allocation tag, once the management account activates it, to supported resources created after activation. It appears only in Billing and Cost Management reports, not in Tag Editor. Resources associated with an application in AWS Service Catalog AppRegistry automatically receive the awsApplication tag.
• Azure Policy’s built-in definitions can add a tag, add or replace one, or inherit one from the resource group or subscription, and modify-effect policies can remediate existing resources.
• Google Cloud labels are set by whoever creates the resource or by your provisioning tooling.

None of these infers an owner from context. A resource named payments-api-worker-3 in a shared account still arrives with no team.

How smart tags derive values

A tagging policy in ZopNight enforces one tag key and derives its value from the resource’s own fields: provider, region, type, instance_type, or name. Several policies can share a key, which turns them into a decision table: for example, one row per name contains ... rule mapping name fragments to application values, which can be imported from a spreadsheet. When more than one policy matches a resource, scope decides first, then an explicit priority where lower wins, then creation order.

Review before it counts

Derived values start as pending. A person accepts or revokes them per key, and only accepted values count toward cost attribution. Two rules keep the review queue honest:

• If the derived value already equals the resource’s live cloud tag, it is accepted automatically, so correctly tagged resources are not left in the queue.
• Derivations are reconciled on every refresh; an accepted tag is kept only while the policy still derives the same value, so a renamed resource does not keep a stale owner.

Writing tags back to the cloud

Accepted smart tags live in ZopNight by default. They can also be written back to the provider on demand through an apply-tag remediation job, which skips any tag whose cloud value already matches. Writing a tag changes the resource, so it needs a cloud account connected with read and write access; read-only accounts still get derivation and attribution.

Using them well

• Derive from the most stable field available. Account-level facts beat names, and names beat instance types.
• Keep decision tables short and ordered, and review conflicts where two policies match.
• Treat derived tags as a bridge while the tagging standard is enforced at creation, not as a replacement for it.

For the standard itself, see cloud tagging best practices; for how tags feed reports, see cost allocation and the Sankey cost breakdown.