Google Cloud Tags and Labels

Google Cloud billing export data includes multiple label sources across different fields. Ternary combines these sources into a single namespace that is used for reporting, filtering, and custom label definitions.

The billing export includes the following label fields:

• labels
• system_labels
• project.labels

Billing export also supports tags, which are exposed as key value pairs in a separate column.

Ternary merges labels, system labels, project labels, and tags into a unified set of dimensions. These dimensions are available in the Reporting Engine for grouping, filtering, and defining custom labels.

How does Ternary resolve Google Cloud label conflicts

Conflicts can occur when the same key exists across multiple label sources with different values. For example, a project may have a label team: A and a tag team: B.

Ternary resolves conflicts using the following order of precedence: Tags > Labels > System Labels > Project Labels

Why is this precedence applied?

Tags are centrally managed at the organization level and are typically more standardized than Google Cloud labels, which can be applied in an ad hoc manner. As a result, labels can be less consistent or reliable. Tags are often used in scenarios that require correctness and consistency, such as IAM policy enforcement.

Among label sources (project.labels, system_labels, labels), precedence is determined based on specificity and intentionality.

• Project labels are the least specific, as they apply to all resources within a project. They are therefore overridden by more specific label types.
• System labels provide resource level information but are system generated. While they are specific, they are not intentionally defined by users.
• Resource labels are both resource specific and user defined. Because they reflect explicit user intent, they are given the highest precedence among label based sources.