Labeling guidance: Start with subset of labels

- **Wastage Monitoring (Resource Optimization)**: To proactively ensure efficient resource utilization by identifying and eliminating unnecessary spending. This includes detecting idle resources, rightsizing over-provisioned instances, removing orphaned assets, and optimizing reserved capacity to maximize the value derived from every dollar spent on cloud infrastructure.

- **Label Compliance (Tagging Strategy)**: To ensure the fundamentals of our infrastructure are properly attributed, which forms the bedrock of proper reporting. Consistent tagging enables accurate cost allocation and granular visibility into spending patterns across teams, projects, environments, and business units.

- **Label Compliance (Tagging Strategy)**: To ensure the fundamentals of our infrastructure are properly attributed, which forms the bedrock of proper reporting. Consistent tagging enables accurate cost allocation and granular visibility into spending patterns across teams, projects, environments, and business units. See our [Labeling Strategy](labeling-strategy) page for details on the core labels we're implementing.

It's important to also call out there is a lifecycle to these items and it all starts with **Label Compliance**.

---

title: "Labeling Strategy"

description: "Core labels for cost allocation and resource attribution in GCP"

---

## Overview

This page documents the core set of labels that the Cloud Cost Utilization team is implementing across GCP resources (to start with).

This is a subset of the [Infrastructure Labels and Tags](/handbook/company/infrastructure-standards/labels-tags/) standard.

These four labels form the foundation of our cost allocation and resource attribution strategy:

- **`gl_service`** - Service Catalog Reference (most important one to establish ownership)

- **`gl_env_type`** - Environment Type

- **`gl_product_category`** - GitLab Product Category

- **`gl_resource_type`** - Cloud Resource Type

These labels are being applied across GCP to start with, and we will expand this subset into a full label taxonomy that builds upon the existing [Infrastructure Labels and Tags standard](/handbook/company/infrastructure-standards/labels-tags/) as we go along.

### Why These Labels?

These four labels provide the essential information needed for:

- **Cost allocation** - Understanding which services, products, and environments are driving costs

- **Resource attribution** - Identifying ownership and operational responsibility

The **`gl_service`** label is the most important of these four, as it provides direct ownership information by linking resources to entries in the [GitLab service catalog](https://gitlab.com/gitlab-com/runbooks/-/blob/master/services/service-catalog.yml). This establishes clear operational responsibility for cost allocation.

> **Important:** Teams must ensure their services are added to the service catalog. If a service is not represented in the catalog, please [add it following the service catalog documentation](https://gitlab.com/gitlab-com/runbooks/-/blob/master/services/README.md?ref_type=heads).

## Service Catalog Reference (`gl_service`)

{{% alert color="warning" %}}

This label is the **most important** for cost allocation and ownership attribution.

{{% /alert %}}

```terraform

gl_service: 'ci-runners'

```

This label links resources to entries in the [GitLab service catalog](https://gitlab.com/gitlab-com/runbooks/-/blob/master/services/service-catalog.yml), establishing clear ownership and operational responsibility for cost allocation.

### Expected Values

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](https://gitlab.com/gitlab-com/runbooks/-/blob/master/services/service-catalog.yml) for the complete list of valid service catalog entries. Consider [adding to the catalog](https://gitlab.com/gitlab-com/runbooks/-/blob/master/services/README.md?ref_type=heads) if a service is not represented yet.

## Environment Type (`gl_env_type`)

{{% alert color="success" %}}

This label is required.

{{% /alert %}}

```terraform

gl_env_type: 'gprd'

```

### Expected Values

| Value         | Description                                                             |

|---------------|-------------------------------------------------------------------------|

| `gprd`         | Production or production-like environment with major impact if powered off. |

| `gstg`         | Staging environment with major impact if powered off. |

| `experiment`  | Individual user experiments with no impact if powered off or data lost. |

| `test`        | Multi-user experiments (POCs, load testing) with disruptive impact if powered off. |

| `other`       | As a last resort, you can use the other category. These are subject to periodic review. |

## GitLab Product Category (`gl_product_category`)

{{% alert color="success" %}}

This label is required. If not applicable, set to `shared`

{{% /alert %}}

This label maps resources to GitLab product capabilities and feature categories that the resource supports directly. If there is no direct relationship between a resource and a category, label with `shared`.

```terraform

gl_product_category: 'gitaly'

```

### Expected Values

Product categories should match one of the categories defined in [`categories.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/categories.yml) in the handbook.

By providing this value, costs can be directly mapped back to a specific set of features, as well as a set of owners within both Product and Engineering.

## Resource Type (`gl_resource_type`)

{{% alert color="info" %}}

This label is optional but recommended for production resources.

{{% /alert %}}

```terraform

gl_resource_type: compute

```

GCP doesn't support easy reporting based on type of resource and name unless you use labels. This is optional, but recommended for resources that cost a significant amount of money or are part of a production service. This is not recommended for sandbox and ephemeral use cases.

### Example Values

- `database` - Relational or NoSQL databases

- `storage` - Object storage, block storage, file systems

- `compute` - VMs, containers, serverless functions

- `loadbalancer` - Load balancing infrastructure

- `network` - Networking components (VPCs, subnets, etc.)

- `cache` - Caching layers (Redis, Memcached)

- `queue` - Message queues and streaming services

- `application` - Application-level services

Whenever possible, use values from the above list and add to this list as deemed necessary.

## Related Documentation

For the complete infrastructure labels and tags standard, including additional labels and realm-specific requirements, see the [Infrastructure Labels and Tags](/handbook/company/infrastructure-standards/labels-tags/) handbook page.