GCP Network Tags Explained: Firewall Rules, Routes, and Security

The simple explanation

Imagine you have three groups of VMs inside a VPC network: web servers that face the internet, application servers in the middle tier, and database servers that should never be reachable from outside. You want firewall rules that match this structure without naming every individual VM.

Network tags solve this. You attach the string web-server to your web VMs, app-server to your application VMs, and database to your database VMs. Then you write firewall rules that say: allow HTTPS from the internet to VMs tagged web-server, allow port 8080 from web-server VMs to app-server VMs, allow port 5432 from app-server VMs to database VMs. Add a new web VM tomorrow, give it the web-server tag, and it immediately picks up all the right rules.

That is the whole model. Tags group VMs. Firewall rules and routes reference those groups. The tags themselves have no inherent meaning or effect until something references them.

What network tags are

A network tag is an arbitrary string attached to a Compute Engine VM instance. The string has no inherent meaning and you define the convention. Common examples include web-server, database, app-tier, allow-ssh, and use-proxy.

Network tags serve two purposes in GCP:

• Firewall rules: a rule can target VMs with a specific tag. Only those VMs are affected by the rule, not all VMs in the network.
• Routes: custom routes can specify that they apply only to VMs with a given tag. This lets you route outbound traffic differently for a subset of VMs, for example sending certain VMs through a network appliance for inspection while others go directly to the internet.

Tags have no effect on billing, cost reporting, or resource organisation. A tag on a VM does nothing on its own. It only has an effect when a firewall rule or route explicitly references that tag.

How network tags work

The mechanism is straightforward once you see it step by step:

1. Attach a tag to a VM. You add a string like web-server to a Compute Engine instance. The tag sits on the VM but has no effect yet.
2. Create a firewall rule or route that references the tag. The rule specifies either a target tag (which VMs the rule applies to) or a source tag (which VMs the traffic originates from). The route specifies a tag to limit which VMs use that route.
3. GCP evaluates the rule against tagged VMs. When traffic arrives at or leaves a VM, GCP checks whether any firewall rule with a matching target tag applies. If the VM has the tag, the rule applies. If not, it does not.

A VM can have multiple tags at once. All firewall rules that match any of those tags apply simultaneously. You can attach web-server and allow-ssh to the same VM and get both the HTTPS rule and the SSH rule applied together.

When to use network tags

Tags are the right tool in several common situations:

• Tiered application architecture. Web, application, and database VMs in a subnet structure. Tags let you define exactly which tiers can talk to each other on which ports without managing individual IP addresses.
• Health check access. Load balancers send health checks from specific Google IP ranges. A rule targeting allow-health-check on your backend VMs opens health check access cleanly without touching other rules.
• Selective routing through a proxy or appliance. If you need only certain VMs to route traffic through a network appliance or Cloud NAT gateway, a tagged route applies the custom path only to those VMs.
• Environment separation inside a VPC. If you run staging and production workloads in the same VPC, tags let you apply different firewall policies to each environment without requiring separate networks.
• Temporary access for operations. Adding an allow-ssh tag during maintenance and removing it afterwards is faster than creating and deleting a firewall rule each time.

Tags are not the right tool when you need a strong security guarantee. That case is covered in the service account comparison below.

Network tags vs resource labels

This is the most common source of confusion for people new to GCP. Network tags and resource labels both live on VM instances, but they do entirely different things and have no connection to each other.

Adding a label role=web-server to a VM does not change which firewall rules apply to it. Adding a network tag web-server has no effect on your billing reports. If you want both network policy and cost tracking on the same VM, you need both. They are completely independent systems. See Labels and Tags in GCP for a full walkthrough of both.

Network tags vs service account targeting

Firewall rules can target VMs in two ways: by network tag, or by service account. Both work, but they have very different security properties.

Tags are flexible and easy to use. Any user with the Compute Engine Instance Admin role can add or remove tags from a VM without restarting it. This is useful in practice because you can quickly adjust which rules apply to a VM. But it also means that anyone with VM edit access can add a tag to a VM and gain whatever network access that tag unlocks. In a large team or environment with broad Compute permissions, this is a meaningful risk.

Service account targeting is more rigid but more secure. The service account a VM uses is set at creation time. On a running VM, you cannot change the service account without stopping the instance. This makes it much harder to accidentally or maliciously grant access by manipulating a VM’s identity.

# Service account targeted rule — the service account cannot be changed on a running VM
gcloud compute firewall-rules create app-to-db-sa \
  --network=production-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-service-accounts=app-server-sa@project.iam.gserviceaccount.com \
  --target-service-accounts=database-sa@project.iam.gserviceaccount.com

A practical rule of thumb: use tags for general traffic segmentation such as web/app/db tiers, health check access, and environment grouping. Use service account targeting for sensitive rules where unauthorized access would have serious consequences. See Network Security Best Practices for a fuller framework on this decision.

Adding tags to VMs

You can add network tags at VM creation time or update them on a running instance. Tags take effect immediately with no restart needed.

Create a new VM and attach tags at the same time:

gcloud compute instances create web-server-1 \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --network=production-vpc \
  --subnet=web-subnet \
  --tags=web-server,allow-health-check

Add tags to a VM that is already running:

gcloud compute instances add-tags web-server-1 \
  --zone=us-central1-a \
  --tags=monitoring-target

Remove a tag you no longer want:

gcloud compute instances remove-tags web-server-1 \
  --zone=us-central1-a \
  --tags=allow-health-check

Check what tags a VM currently has:

gcloud compute instances describe web-server-1 \
  --zone=us-central1-a \
  --format="get(tags.items)"

A VM can have up to 64 network tags. When creating VMs at scale using instance templates, tags defined in the template are applied to every VM in the group automatically.

Using tags in firewall rules

Firewall rules reference network tags in two distinct ways:

• Target tags: the rule applies to VMs carrying this tag. These are the VMs the rule acts on, controlling what traffic they can receive (ingress) or send (egress).
• Source tags: for ingress rules, traffic originating from VMs with this tag is matched as the source. This lets you say “allow traffic from web-server VMs” rather than specifying IP ranges.

Here is a complete three-tier worked example. Allow HTTPS from the internet to web servers:

gcloud compute firewall-rules create allow-https-to-web \
  --network=production-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server

Allow web servers to reach application servers on port 8080:

gcloud compute firewall-rules create web-to-app \
  --network=production-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:8080 \
  --source-tags=web-server \
  --target-tags=app-server

Allow application servers to reach databases on PostgreSQL port 5432:

gcloud compute firewall-rules create app-to-db \
  --network=production-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-tags=app-server \
  --target-tags=database

See Firewall Rules Explained for the full rule model including priority, statefulness, and implicit defaults.

Using tags in routes

Custom routes can also reference network tags. A route with a tag only applies to VMs that have that tag. All other VMs ignore it and use their default route. This is useful when you want selective outbound routing: send some VMs through a proxy or inspection appliance while others go directly to the internet.

Create a custom route that only applies to VMs tagged use-proxy:

gcloud compute routes create route-via-proxy \
  --network=production-vpc \
  --destination-range=0.0.0.0/0 \
  --next-hop-instance=proxy-vm \
  --next-hop-instance-zone=us-central1-a \
  --tags=use-proxy \
  --priority=100

Only VMs tagged use-proxy will route their outbound traffic through proxy-vm. Other VMs continue using the default route to the internet gateway.

Best practices

• Use a consistent naming convention. Choose a scheme like role-purpose (for example, backend-app, backend-db, ops-bastion) and apply it consistently. Tags that follow a pattern are easier to audit and harder to misuse.
• Keep tags role-based, not person-based. Tags should reflect the function of the VM, not who created it or which team owns it. Role-based tags map cleanly to firewall rules. Person-based or team-based tags create sprawl.
• Avoid tag sprawl. Each tag you create is a potential firewall target. Review your tags periodically and remove ones that no longer correspond to active rules.
• Document tags in Terraform or deployment manifests. If you are managing infrastructure as code, every tag used in a firewall rule should be visible in the same codebase. A rule targeting allow-health-check is opaque if the tag itself only exists in the console.
• Use service account targeting for sensitive rules. For rules that protect databases, secrets APIs, or internal management interfaces, prefer service account-based targeting over tags. The added rigidity is a feature, not a limitation.
• Review firewall rules regularly. Over time, tags accumulate and old rules persist. Use Connectivity Tests and firewall log analysis to find rules that are no longer matched or that allow more access than intended.