Cross-Region Routing

Cross-Region Network does not add its own routes. Reachability between regions inside a VPC works on the routes that already exist in the VPC route table — the local subnet routes the platform provisions for each subnet, any dynamic routes learned through Border Gateway, and any custom routes you added yourself.

This page covers what those routes are, how they're evaluated when multiple routes match the same packet, and what you do (and don't) need to touch when working across regions.

Route Types in a VPC Route Table

A VPC route table can hold several types of routes. The platform evaluates route types in this order:

Type	Who Creates It	Typical Purpose
Policy route	You	Source-based routing: send traffic from a specific source prefix out a specific next hop
Subnet route	Platform (automatic)	Every subnet in the VPC — local-region and remote-region — is installed here automatically when the subnet is created
Custom route	You	A prefix you want to send to a specific next hop — an instance, a NAT Gateway, or a Border Gateway
Dynamic Route	Platform (automatic)	Prefixes learned dynamically, for example from Border Gateway BGP sessions
NAT Gateway route	Platform (automatic)	Default routes that send covered sources to a NAT Gateway

Cross-region subnets show up as ordinary subnet routes — the same type used for same-region subnets. There is no special "cross-region" route type.

How Routes Are Matched

When a packet needs a routing decision, the platform evaluates candidates in this order:

1. Route type. Policy routes win first, then subnet routes, then custom and Dynamic Routes, then NAT Gateway routes.

2. Policy priority and source prefix. Within policy routes, lower priority values win first; if needed, the most specific source prefix wins.

3. Destination prefix. Within the same route-type bucket, the most specific destination prefix wins.

4. Route priority. If there is still a tie, the route with the lower priority value wins.

Priority values are integers from 0 to 65535, smallest first. If you don't set a priority explicitly, routes are given a default value.

What You Don't Have to Do

• You don't add routes for cross-region subnets. When a subnet is added to a VPC — in any region — the platform installs a subnet route for it. Remote-region subnets are visible to every subnet in the same VPC from the moment they exist.

• You don't add or remove routes when you raise Cross-Region Bandwidth. Bandwidth purchases don't change the route table. Routing and capacity are independent: the routes were always there; the purchase only raises the rate the path can carry.

• You don't maintain routes for Border Gateway sessions. Learned prefixes arrive as Dynamic Routes and are withdrawn automatically when a session drops.

What You Might Do

Override a mesh-reachable route for a source. If you want traffic from a specific source subnet to take a different path — for instance, through a firewall appliance before crossing regions — use a policy route. Custom routes do not outrank subnet routes, even if the custom route has a more specific destination prefix.

Block or redirect a remote subnet for selected sources. Use policy routing or a firewall in the path to block or redirect traffic from the sources you choose. A plain custom route is not the right override mechanism for an automatic subnet route.

Carve out a source-specific path. A policy route can send traffic from one of your subnets through a different egress (a Border Gateway, for example) while leaving the rest of the VPC on the default cross-region path.

Route Conflicts

Before a new route can be installed — whether by the platform or by you — the platform checks for conflicts with existing routes on the same table. If there's a conflict, the operation is rejected with an error that names the conflicting route.

Common causes:

• You already have a custom route for a prefix that overlaps a subnet you're now trying to create.

• Two custom routes with the same destination and same priority are submitted at the same time.

To resolve: remove or renumber the conflicting route, then retry.

Viewing Cross-Region Routes in the Console

In the management console, navigate to VPC → Route Tables, select the relevant table, and filter by route type. Subnet routes include entries for every subnet in the VPC regardless of region — remote-region subnets sit alongside local ones. If you've added Border Gateway, Dynamic Routes appear as a separate type.