Routes in GCP Explained: System Routes, Custom Routes, and Cloud Router

Simple explanation

A route is an instruction. It tells GCP: when a VM sends traffic to this range of IP addresses, forward it to this next hop. That next hop might be the internet gateway, a VPN tunnel, another VM acting as a firewall, or a specific IP address inside the VPC.

How routing works in a GCP VPC

When a VM sends a packet, GCP looks at the destination IP and finds all routes whose destination range includes that IP. It then selects the best match using this logic:

1. Longest prefix match: the most specific destination range wins. A /28 beats a /16 when both match the destination IP. This rule always takes precedence.
2. Priority: if two routes cover the same prefix length, the one with the lower priority number wins. Priority 100 beats priority 1000.
3. ECMP: if two routes share the same prefix length and priority, GCP distributes traffic across all matching routes using equal-cost multi-path routing. This is useful for balancing load across multiple VPN tunnels.

Every route specifies a next hop. The available next hop types are:

• Default internet gateway: for outbound internet traffic from VMs with external IPs
• VM instance: used for appliance-style routing through a firewall VM, IDS, or proxy
• IP address: a specific internal IP within the VPC
• VPN tunnel: for traffic going to on-premises or other networks via Cloud VPN
• Cloud Router (BGP): for dynamically learned routes over a BGP session

Routes are defined at the VPC level and apply to all VMs in the network by default. You can restrict a route to specific VMs by adding a network tag to the route. Only VMs carrying that tag will use it for outbound traffic. Tags have no effect on which traffic arrives at those VMs.

System-generated routes

GCP automatically creates two categories of routes in every VPC. You do not need to add these. They exist as soon as the VPC and its subnets do.

Subnet routes

For each subnet in your VPC, GCP creates a route covering that subnet’s IP range with the virtual network as the next hop. This is what allows VMs in the same VPC to reach each other using private IP addresses, even across regions. A VM in us-central1 and one in europe-west1 can communicate privately because subnet routes exist for both.

Subnet routes cannot be deleted manually. GCP manages them and removes them only when you delete the subnet itself.

Default internet route

Every new VPC also gets a default route with destination 0.0.0.0/0 pointing to the default internet gateway. This catch-all route is why VMs with external IP addresses can reach the internet straight away. The 0.0.0.0/0 route matches any destination not covered by a more specific route.

Cloud NAT, which provides internet access for VMs without external IPs, also depends on this default route. If you delete it, both directly-reachable VMs and Cloud NAT lose internet access.

# View all routes in your VPC
gcloud compute routes list --filter="network:production-vpc"

# Describe a specific route to see its full configuration
gcloud compute routes describe default-route-abc123

Custom static routes

Static routes are routes you create manually to direct traffic to a specific next hop. GCP will not add or remove them automatically. They persist until you delete them.

Common reasons to create a static route:

• Sending traffic for an on-premises subnet through a VPN tunnel
• Routing specific traffic through a network appliance (firewall VM, IDS, proxy)
• Using network tags to give a subset of VMs a different outbound path from the rest
• Overriding or replacing the default route to control internet egress

# Route traffic for an on-premises subnet through a VPN tunnel
gcloud compute routes create route-to-onprem \
  --network=production-vpc \
  --destination-range=192.168.10.0/24 \
  --next-hop-vpn-tunnel=vpn-tunnel-1 \
  --next-hop-vpn-tunnel-region=us-central1 \
  --priority=100

# Route all internet-bound traffic through a network appliance VM
gcloud compute routes create route-via-appliance \
  --network=production-vpc \
  --destination-range=0.0.0.0/0 \
  --next-hop-instance=network-appliance \
  --next-hop-instance-zone=us-central1-a \
  --priority=100

# Apply the appliance route only to VMs tagged inspect-traffic
gcloud compute routes create tagged-route-via-appliance \
  --network=production-vpc \
  --destination-range=0.0.0.0/0 \
  --next-hop-instance=network-appliance \
  --next-hop-instance-zone=us-central1-a \
  --tags=inspect-traffic \
  --priority=100

Static routes work well when your network topology is stable and predictable. When subnets change frequently, when you have multiple tunnels with failover requirements, or when remote routes change without notice, maintaining static routes by hand becomes error-prone. That is where Cloud Router helps.

Dynamic routing with Cloud Router

Cloud Router is a managed GCP service that runs BGP (Border Gateway Protocol) on behalf of your VPC. It exchanges route information dynamically with connected networks, such as an on-premises router over a Cloud VPN tunnel, or a partner’s edge router over a Cloud Interconnect connection.

This matters in practice. If your on-premises network has subnets that change occasionally, Cloud Router keeps the VPC routing table in sync automatically. With static routes, you would need to add, update, or delete entries by hand every time something changed on the other side.

# Create a Cloud Router to enable dynamic BGP routing
gcloud compute routers create prod-router \
  --network=production-vpc \
  --region=us-central1 \
  --asn=65001

# Check the Cloud Router status and BGP session state
gcloud compute routers get-status prod-router \
  --region=us-central1

The —asn flag sets the Autonomous System Number for your VPC. Use a private ASN in the range 64512–65534 if you do not have a registered public ASN. For a broader overview of connecting GCP to on-premises infrastructure, see Hybrid Connectivity Overview.

When to use this

Routes are relevant whenever you need to control how traffic leaves a VM or moves through the network. Here are the situations where routing decisions matter most:

• Connecting to an on-premises network: traffic going to a non-GCP network needs a route pointing to the VPN tunnel or Interconnect connection. Use static routes for simple, fixed setups. Use Cloud Router when remote subnets change or you have multiple tunnels.
• Routing through an inspection appliance: security teams often require that certain VM traffic passes through a firewall VM or intrusion detection system before leaving the VPC. This needs a custom route pointing to that appliance VM (with IP forwarding enabled), and optionally a network tag to apply it only to specific VMs.
• Controlling internet egress: if you want to restrict which VMs can reach the internet, replace or remove the default 0.0.0.0/0 route, or use a tagged custom route to steer specific VMs through a proxy or controlled gateway.
• Hybrid networking with Cloud Router: when using HA VPN or Cloud Interconnect, Cloud Router handles route exchange and failover dynamically. Managing routes manually for these setups is impractical as the topology grows.
• Steering specific workloads differently: network tags let you apply different routes to different sets of VMs. A VM tagged inspect-traffic can use a different default path while other VMs use the standard internet route.

Routes vs related networking concepts

Routes vs firewall rules

This is the most common source of confusion. Routes and firewall rules solve different problems and are evaluated independently.

A route answers: where should this packet go next? A firewall rule answers: is this packet allowed to pass? If you want to block traffic, use a firewall deny rule. Do not rely on deleting a route. Removing a route may cause packets to take a different path or be silently dropped, rather than being blocked with a clear error. See Firewall Rules Explained for how to control access properly.

Static routes vs dynamic routes

Static routes are permanent entries you create manually. They do not change unless you update them. They are a good fit for stable, well-understood topologies with a small number of fixed paths.

Dynamic routes are learned by Cloud Router via BGP. They are added and removed automatically as connected networks change. For VPC Peering and Shared VPC, routes are also exchanged automatically without needing Cloud Router.

Routes vs Cloud NAT

Routes and Cloud NAT are often confused because both affect how VMs reach the internet. The distinction is straightforward: Cloud NAT provides source address translation for VMs without external IPs so they can initiate outbound internet connections. It does not change routing. Cloud NAT relies on the default route (0.0.0.0/0) already being present in the VPC. Routes determine the path; Cloud NAT handles the address translation for private VMs. Delete the default route and Cloud NAT stops working.

How to check and manage routes

# List all routes in your VPC
gcloud compute routes list --filter="network:production-vpc"

# List routes sorted by priority to understand which routes take precedence
gcloud compute routes list \
  --filter="network:production-vpc" \
  --sort-by=priority

# Describe a specific route to see all its fields
gcloud compute routes describe route-to-onprem

# Delete a custom route that is no longer needed
gcloud compute routes delete route-via-appliance

Audit your routing table periodically. Static routes pointing to VPN tunnels that no longer exist, or to VM IPs that have been reassigned, cause silent routing failures that are harder to diagnose than firewall problems. For a systematic approach, see Troubleshooting Network Issues.