GCP Labels vs Tags: Labels, Network Tags, and Resource Manager Tags Explained

Simple explanation

Here is the short version before we go deeper:

• Labels are metadata key-value pairs you attach to GCP resources. They are used for organisation, resource filtering, and cost attribution in billing reports. They do not affect runtime behaviour.

• Network tags are plain strings attached to Compute Engine VMs. They control which firewall rules and VPC routes apply to a VM. They are Compute Engine-only and have nothing to do with billing or organisation.

• Resource Manager tags are a newer governance feature used in large organisations. They can be used in IAM conditions and Organisation Policies to enforce rules based on resource attributes. Beginners usually do not need them.

How it works

Labels

You attach labels to a resource at creation time or afterwards. Labels are key-value pairs like env=production or team=backend. GCP stores them as metadata on the resource. They appear in the Cloud Console, in gcloud describe output, and crucially, in your billing export to BigQuery. Once billing export is enabled, every line item in the export includes any labels attached to the resource that generated it.

Labels work across most GCP resource types: Compute Engine VMs, persistent disks, Cloud Storage buckets, Cloud SQL instances, BigQuery datasets, Cloud Run services, and more.

Network tags

Network tags are attached only to Compute Engine VMs. When you create a firewall rule, you can target it at all VMs carrying a specific tag rather than at individual IPs or subnets. Any VM you add the tag to immediately inherits the firewall rule. Any VM without the tag is unaffected, even if it is in the same subnet.

Network tags can also be used with VPC routes. See the network tags guide and firewall rules explained for the full detail on how these interact.

Resource Manager tags

Resource Manager tags are attached at the project, folder, or organisation level and cascade down to resources. Unlike labels, their values are strongly typed and controlled by IAM, meaning only authorised users can create or modify them. They are primarily used for enforcing Organisation Policies or writing IAM conditions that depend on resource attributes. This is an advanced governance feature most beginners will not need.

Why are these three systems separate?

They evolved to solve different problems. Labels came first as a general-purpose metadata layer. Network tags were a Compute Engine-specific mechanism for firewall targeting that predates labels. Resource Manager tags were introduced later to support policy-as-code governance at enterprise scale. They share similar terminology but were built independently and serve different purposes.

When to use this

Use labels when you want to:

• Know which team or environment a resource belongs to at a glance
• Filter long resource lists by environment, app, or team in the Cloud Console or gcloud
• Break down monthly cloud spend by environment, team, or application in BigQuery
• Charge costs back to different teams or business units
• Audit which resources are missing required metadata

Use network tags when you want to:

• Allow HTTP/HTTPS traffic to a group of web server VMs without listing each IP
• Restrict database VMs to only accept connections from application-tier VMs
• Apply different routing behaviour to specific VMs in a VPC

Use Resource Manager tags when you want to:

• Prevent resources tagged as data-classification=sensitive from being created in certain regions
• Write IAM conditions that grant access only to resources with a specific attribute
• Enforce governance rules consistently across a large multi-project organisation

Labels vs network tags vs Resource Manager tags

Labels in depth

A label is a key-value pair you define. GCP does not prescribe keys or values. The convention is entirely yours. Common patterns that cover most organisations:

• env=production, env=staging, env=dev
• team=backend, team=data, team=platform
• app=checkout-api, app=reporting-service
• cost-centre=marketing, cost-centre=engineering

Label syntax rules

• Keys and values must be lowercase letters, numbers, hyphens, or underscores
• Keys must start with a letter
• Maximum 64 labels per resource
• Keys up to 63 characters; values up to 63 characters

Create a VM with labels at creation time (the most important moment to label):

gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --labels=env=production,team=backend,app=payments-api

Add or update labels on an existing resource:

gcloud compute instances add-labels my-vm \
  --zone=us-central1-a \
  --labels=cost-centre=engineering

Filter a resource list by label value. Works in gcloud and the Cloud Console:

gcloud compute instances list \
  --filter="labels.env=production"

Add labels to a Cloud Storage bucket:

gcloud storage buckets update gs://my-bucket \
  --update-labels=env=staging,team=data

Labels and cost attribution

The most practical use of labels is breaking down cloud costs. When you enable billing export to BigQuery, GCP writes every line item from your bill into a BigQuery dataset. The labels attached to each resource are included in that export. You can then query spending by any label key.

“Billing export to BigQuery” simply means: GCP writes a detailed record of every charge to a BigQuery table you own, updated daily. From there you can run SQL queries to answer questions like “how much did the production environment cost this month?” or “which team is responsible for the highest storage spend?”

-- Monthly spend breakdown by team label
SELECT
  labels.value AS team,
  ROUND(SUM(cost), 2) AS total_cost_usd
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXXX`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND DATE(usage_start_time) >= DATE_TRUNC(CURRENT_DATE(), MONTH)
GROUP BY team
ORDER BY total_cost_usd DESC;

For a fuller picture of how GCP cost management works, see cost breakdown reports and billing budgets and alerts. Labels also complement project-level cost separation. See GCP Projects to understand when to separate by project versus by label.

Network tags (Compute Engine-specific)

Network tags are not labels. They are plain strings attached to Compute Engine VMs that GCP uses to match firewall rules and VPC routes. They have no connection to billing, no key-value structure, and no effect on other resource types.

A firewall rule can target all VMs carrying a specific network tag. Any VM you add that tag to automatically inherits the rule. Any VM without the tag is unaffected, even if it sits in the same subnet.

Create a VM with network tags:

gcloud compute instances create my-web-server \
  --zone=us-central1-a \
  --tags=http-server,https-server

Create a firewall rule that targets all VMs tagged http-server:

gcloud compute firewall-rules create allow-http \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80 \
  --target-tags=http-server

Any VM created later with the http-server tag automatically receives port 80 access. Any VM without the tag does not. This is far more manageable than maintaining firewall rules by IP address as your fleet grows.

For the complete picture of how network tags interact with VPC routing, see the dedicated network tags guide.

Resource Manager tags

Resource Manager tags are a separate governance feature. You probably do not need them yet, but you should know they exist so you do not confuse them with labels or network tags.

Unlike labels, Resource Manager tags have strongly-typed values that are controlled by IAM. Only users with the right permissions can create or assign them. They cascade down through the resource hierarchy: attach a tag at the organisation or folder level and it applies to all child projects and resources automatically.

They are primarily used for:

• Writing IAM conditions that grant access only to resources with a specific tag value
• Enforcing Organisation Policies, for example, blocking resource creation in specific regions unless the resource carries an approved tag

For most teams, labels and network tags are sufficient. Resource Manager tags become relevant when you are managing a large multi-project environment and need policy enforcement that cannot be handled by project structure alone.

Best practice naming strategy

Labels are only useful when applied consistently. A good starting convention uses four keys and applies them to every resource from day one:

• env: production, staging, development
• team: the owning team, e.g. backend, data, platform
• app: the application or service, e.g. checkout-api, reporting-service
• cost-centre: the cost centre for billing chargebacks, e.g. engineering, marketing

Audit VMs missing the env label:

gcloud compute instances list \
  --format="table(name,zone,labels.env)" \
  --filter="NOT labels.env:*"

Inspect all labels on a specific resource:

gcloud compute instances describe my-vm \
  --zone=us-central1-a \
  --format="value(labels)"