System-Generated and Custom Routes in GCP and Azure

Google Cloud and Microsoft Azure automatically create routes to provide basic network connectivity. These provider-managed routes allow resources within a virtual network to communicate without requiring administrators to build every route manually.

Both platforms also support custom routes for traffic inspection, hybrid-cloud connectivity, VPN access, and other advanced routing requirements. However, GCP and Azure organize and apply these routes differently.

Understanding System-Generated Routes

System-generated routes are created automatically when you create or modify cloud networking resources.

Examples include routes for:

• Communication within a VPC or VNet
• Internet-bound traffic
• VPC or VNet peering
• VPN and dedicated private connections
• Cloud service endpoints

These routes are managed by the cloud provider, but the degree to which they can be replaced or overridden differs between GCP and Azure.

Routing in Google Cloud

Google Cloud uses a distributed virtual routing system. Routes are defined at the VPC network level rather than through a separate route table attached to each subnet.

Subnet Routes

GCP automatically creates a subnet route for every primary and secondary IP range assigned to a subnet.

For example, if you create:

Subnet: application-subnet
IP range: 10.10.0.0/24

Google Cloud automatically creates a route similar to:

Destination: 10.10.0.0/24
Next hop: application-subnet

This route allows resources throughout the VPC to reach the subnet.

Subnet routes are created, updated, and removed automatically as the corresponding subnet ranges change. They cannot be manually deleted independently of the subnet.

GCP evaluates subnet routes before custom static and dynamic routes. Under normal routing behavior, a custom route cannot replace a subnet route or redirect traffic belonging to that subnet. Google Cloud routing documentation

System-Generated Default Routes

When a VPC is created, Google Cloud normally adds an IPv4 default route:

Destination: 0.0.0.0/0
Next hop: Default internet gateway

Unlike subnet routes, GCP’s system-generated default route can be deleted and replaced. For example, an organization may replace it with a custom default route directing outbound traffic through a firewall appliance.

Removing the default internet route does not remove all special Google-managed routing paths, such as certain load-balancer, health-check, and Identity-Aware Proxy paths.

Custom Static Routes

Administrators can create custom static routes to direct traffic to next hops such as:

• A VM acting as a router or firewall
• An internal passthrough Network Load Balancer
• A Classic VPN tunnel
• The default internet gateway

For example:

Destination: 0.0.0.0/0
Next hop: Central firewall appliance
Priority: 100

This route could send outbound traffic through a security appliance instead of using the system-generated internet route.

For custom static and dynamic routes, GCP first evaluates the most specific destination prefix. A /24 route, for example, is more specific than a /16 route.

Network Tags

GCP can limit certain custom static routes to VM instances with specific network tags.

For example, consider this route:

Destination: 0.0.0.0/0
Next hop: Inspection appliance
Network tag: inspected-workload

Only VMs carrying the inspected-workload tag use this route. Other VMs in the same VPC can use a different applicable route.

This provides route-level control over selected VM workloads without creating a separate subnet. Network tags can be used with custom static routes and policy-based routes.

Cloud Router and Dynamic Routing

Cloud Router manages BGP sessions and exchanges routes between a Google Cloud VPC and connected networks. It works with services such as:

• HA VPN
• Dedicated Interconnect
• Partner Interconnect
• Cross-Cloud Interconnect
• Router appliances

Suppose an on-premises router advertises:

172.20.0.0/16

Cloud Router can learn that prefix through BGP and instruct the VPC to create a corresponding dynamic route.

Cloud Router is a control-plane service. It manages BGP and programs dynamic routes, but it does not sit in the traffic path or forward packets itself. Google Cloud Router overview

A VPC’s dynamic routing mode determines whether learned routes apply regionally or globally.

Routing in Microsoft Azure

Azure automatically creates system routes for every subnet. Each subnet has an effective route table composed of system routes, applicable BGP routes, and any user-defined routes.

Unlike GCP, Azure custom routes are placed in a route-table resource that is associated with one or more subnets.

Azure System Routes

Azure automatically creates system routes for destinations such as:

• The VNet address space
• Internet-bound traffic
• Private IP ranges
• Peered VNet address spaces
• Routes learned through a virtual network gateway
• Service endpoint destinations

A simplified default route set might include:

VNet address range → Virtual network
0.0.0.0/0         → Internet
10.0.0.0/8        → None
172.16.0.0/12     → None
192.168.0.0/16    → None

The None next hop causes matching traffic to be dropped unless a more applicable route exists.

Azure system routes cannot be directly created or deleted by the user. However, many can be overridden with custom routes. Azure virtual network routing documentation

User-Defined Routes

Azure custom static routes are called user-defined routes, or UDRs.

A UDR is created inside an Azure route table. The route table is then associated with one or more subnets. Each subnet can have no more than one route table associated with it, although one route table can be associated with multiple subnets.

For example:

Destination: 0.0.0.0/0
Next-hop type: Virtual appliance
Next-hop address: 10.0.100.4

If this route table is associated with an application subnet, outbound traffic from that subnet is sent to the network virtual appliance at 10.0.100.4.

A common use case is:

Azure Route Selection

Azure primarily uses longest-prefix matching.

For example, if both routes are present:

10.0.0.0/16 → Virtual appliance
10.0.1.0/24 → Virtual network

Traffic to 10.0.1.10 uses the /24 route because it is more specific.

When multiple routes have the same prefix, Azure generally uses this priority:

1. User-defined route
2. BGP route
3. System route

There are important exceptions. Certain routes associated with VNet connectivity, VNet peering, and service endpoints receive special treatment. In particular, service-endpoint routes cannot be overridden by a UDR.

Azure Next-Hop Types

Azure UDRs support next-hop types such as:

• Virtual appliance — sends traffic to a firewall, router, or other network appliance
• Virtual network gateway — sends traffic through a VPN gateway
• Virtual network — keeps traffic within the VNet
• Internet — sends traffic toward the internet
• None — drops the traffic

Azure automatically creates some next-hop types, such as Virtual network peering and VirtualNetworkServiceEndpoint. Users cannot select these types when creating a UDR.

Dynamic Routes in Azure

Azure can learn routes dynamically through BGP when an on-premises network exchanges routes with:

• Azure VPN Gateway
• ExpressRoute
• Azure Route Server
• Azure Virtual WAN

For example, if an on-premises router advertises 172.20.0.0/16, Azure adds a route for that prefix to the applicable subnet route tables.

Gateway route propagation can also be disabled through a subnet’s associated route table when administrators need tighter control over routing.

Key Differences Between GCP and Azure

Example: Routing Internet Traffic Through a Firewall

GCP

An administrator could create a custom static route:

Destination: 0.0.0.0/0
Next hop: Internal passthrough load balancer

The load balancer could direct traffic to a highly available pair of firewall appliances. The route could apply to the entire VPC or only to VMs with a selected network tag.

Azure

An administrator would:

1. Create a route table.
2. Add a UDR for 0.0.0.0/0.
3. Set the next hop to an Azure Firewall or network virtual appliance.
4. Associate the route table with the workload subnet.

Every workload in that subnet would then use the custom route, subject to Azure’s routing rules and exceptions.

Final Perspective

GCP and Azure both provide automatic routing for basic cloud connectivity and custom routing for advanced network designs. The main architectural difference is how those routes are organized and applied:

• GCP routes are primarily VPC-level objects, with certain routes selectively applied through network tags, regions, or route type.
• Azure UDRs are organized into route tables and associated with subnets.

In both platforms, “override” does not simply mean that a custom route always wins. Route selection depends on prefix specificity, route type, applicability, priority, and platform-specific exceptions. Understanding those rules is essential when designing firewalls, hybrid connectivity, forced tunneling, or centralized network inspection.