Labeling Strategy

Overview

This page defines what is considered compliant with our cost allocation and attribution strategy.

This page documents the required labels for resources and projects. These requirements are a subset of the Infrastructure Labels and Tags standard.

Compliance with this strategy

Compliance is evaluated at the level of GCP billing line items.

A line item is considered compliant if it falls into one of these buckets (defined in more detail below):

1. Resource level gl_service label with a valid reference to the service catalog
2. Project level gl_service label with a valid reference to the service catalog
3. General Networking costs: service.description = 'Networking'
4. Support costs: service.description = 'Support'
5. Committed Use Discounts (CUDs) costs: sku.description LIKE '%commit%'

Line items are evaluated in this precedence order — the first matching bucket wins.

Service catalog based allocation

The primary goal of this strategy is to associate line items with services in the GitLab service catalog.

We use the gl_service label to reference a service in the catalog. This label enables:

• Cost allocation - Understanding which services are driving costs
• Resource attribution - Identifying ownership and operational responsibility

The label can be defined at two levels:

1. Resource level: Most granular and preferred
2. Project level: Fallback for the entire GCP project when resource-level labels are absent

Project-level labels provide a faster way to attribute all project costs to a single service without labeling individual resources.

All projects with a clear mapping to a single service should have a project-level gl_service label. This also ensures non-resource costs (for example, networking) are attributed to the correct service.

How to implement

All services should:

• Have an entry in the GitLab Service Catalog
• Be managed in Terraform, with labels applied to resources and projects

Adding or updating services in the service catalog

To add a new service or update an existing one, follow the service catalog documentation. For reference, see this example MR that adds a new team and service.

Adding the gl_service label to existing infrastructure via Terraform

To add gl_service to existing infrastructure, update the relevant Terraform configuration. For reference, see this example MR.

Values must reference an entry in the GitLab service catalog. Example values include:

• ci-runners - GitLab Runner service
• ci-jobs-api - CI Jobs API service
• frontend - Frontend application service
• patroni-ci - Patroni cluster for CI

Please consult the service catalog for the complete list of valid service catalog entries. Consider adding to the catalog if a service is not represented yet.

Non-resource cost: Networking, Support, Other

Networking and Support-related cost can’t have resource labels.

It is possible to associate these cost with a service using a project-level gl_service label. However, for generic projects (e.g. gitlab-production), there is no 1:1 mapping between the project and a service in the catalog.

For these cases, we capture Networking and Support cost using separate buckets (3, 4 in above list).

These buckets are not associated with a service and don’t have an explicit owner.

Committed Use Discounts (CUDs)

GCP Committed Use Discounts (CUDs) are long-term commitments (typically 1 or 3 years) to use a minimum level of resources in exchange for discounted pricing. CUD-related billing line items are identified by their SKU description containing the word “commit” (case-insensitive match).

Classification rule: cud (priority 5)

How CUD costs appear in billing data:

• CUD costs are identified by matching sku.description LIKE '%commit%' against the GCP billing export.
• These line items represent the commitment fees and associated credits that GCP applies to offset on-demand pricing.
• All CUD costs are placed in the committed_use_discounts cost bucket and marked as compliant.

Important note on Billed Cost vs. Effective Cost:

In GCP’s billing export, Billed Cost and Effective Cost are currently calculated identically as cost + SUM(credits.amount). Per the FinOps FOCUS specification, Effective Cost should redistribute commitment fees (such as CUD upfront payments) to the individual usage lines that benefit from those commitments. However, GCP currently amortizes commitment charges by time and distributes them alongside usage charges rather than performing this redistribution. As a result, the “moving” of cost from the commitment fee SKU to the corresponding usage line does not happen in GCP’s data today. This distinction will become more meaningful if GCP updates their billing export to align with the FOCUS specification.

“Other” non-resource costs (bucket 5) are line items tied to specific SKUs that inherently have no associated resource (e.g. licensing fees, committed use discounts, or platform-level charges). We determine these costs based on SKU-based bucketing rules defined in our SQLMesh catalog. These costs are considered compliant as they are explicitly identified and categorized, even though they cannot be attributed to a specific service.

Related Documentation

For the complete infrastructure labels and tags standard, including additional labels and realm-specific requirements, see the Infrastructure Labels and Tags handbook page.