3.1.65 Tags

The Tags column represents the set of tags assigned to tag sources that also account for potential provider-defined or user-defined tag evaluations. Tags are commonly used for scenarios like adding business context to cost and usage data to identify and accurately allocate charges. Tags may also be referred to by data generators using other terms such as labels.

A tag becomes finalized when a single value is selected from a set of possible tag values assigned to the tag key. When supported by a data generator, this can occur when a tag value is set by provider-defined or user-defined rules.

Tags MUST adhere to the following requirements:

• Tags MUST be of type JSON Object (serialized as a String where necessary).
• Tags MUST conform to StringHandling requirements.
• Tags MUST conform to KeyValueFormat requirements.
• Tags MAY be null.
• When Tags is not null, Tags MUST adhere to the following requirements:
  • Tags MUST include all user-defined and provider-defined tags.
  • Tags MUST only include finalized tags.
  • Tags SHOULD include tag keys with corresponding non-null values for a given resource.
  • Tags MAY include tag keys with a null value for a given resource depending on the data generator's tag finalization process.
  • Tag keys that do not support corresponding values, MUST have a corresponding true (boolean) value set.
  • Tag values MUST match the provided values unless true (boolean) is applied to valueless tags.
• Provider-defined tags MUST adhere to the following requirements:
  • Provider-defined tag keys MUST be prefixed with a predetermined, provider-specified tag key prefix that is unique to each corresponding provider-specified tag scheme.
  • Provider-specified tag key prefixes SHOULD be publicly documented.
• User-defined tags MUST adhere to the following requirements:
  • User-defined tag keys in all but one user-defined tag scheme MUST include a predetermined, provider-specified tag key prefix that is unique to each corresponding user-defined tag scheme when the data generator has more than one user-defined tag scheme.
  • User-defined tag keys MUST NOT include a tag scheme-specific prefix when the data generator has only one user-defined tag scheme.
  • Reserved tag key prefixes MUST be prevented from being used as prefixes for any user-defined tag keys within a prefixless user-defined tag scheme.
• Tag finalization documentation MUST adhere to the following requirements:
  • Tag finalization documentation SHOULD include tag finalization methods and semantics.
  • Tag finalization documentation SHOULD be accessible to practitioners.

This example illustrates various tags produced from multiple user-defined and provider-defined tag schemes. The first three tags illustrate examples from three different, user-defined tag schemes. The data generator predetermined that one user-defined tag scheme (i.e., "foo": "bar") does not have a prepended prefix, but the remaining two user-defined tag schemes (i.e., "userDefinedTagScheme2/foo": "bar", "userDefinedTagScheme3/foo": true) do have provider-defined and reserved prefixes. Additionally, the third tag is produced from a valueless, user-defined tag scheme, so the data generator also applies true as its default value.

The last two tags illustrate examples from two different, provider-defined tag schemes. Since all provider-defined tag schemes require a prefix, the data generator has prepended predefined and reserved prefixes (providerDefinedTagScheme1/, providerDefinedTagScheme2/) to each tag.

    {
        "foo": "bar",
        "userDefinedTagScheme2/foo": "bar",
        "userDefinedTagScheme3/foo": true,
        "providerDefinedTagScheme1/foo": "bar",
        "providerDefinedTagScheme2/foo": "bar"
    }

Within a data generator, tag keys may be associated with multiple values, and potentially defined at different levels within the data generator, such as accounts, folders, resource and other resource grouping constructs. When finalizing, the data generator reduces these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each data generator and are documented within their respective documentation.

As an example, assume one sub account exists with one virtual machine with the following details, and tag inheritance favors Resources over Sub Accounts.

• Sub Account
  • id: my-sub-account
  • user-defined tags: team:ops, env:prod
• Virtual Machine
  • id: my-vm
  • user-defined tags: team:web

The table below represents a finalized dataset with these resources. It also shows the finalized state after all resource-oriented, tag inheritance rules are processed.

Because the Virtual Machine Resource did not have an env tag, it inherited tag, env:prod (italicized), from its parent sub account. Conversely, because the Virtual Machine Resource already has a team tag (team:web), it did not inherit team:ops from its parent sub account.

The set of tags assigned to tag sources that account for potential provider-defined or user-defined tag evaluations.