Routing Example: A Cloud Route Table With a Peering Connection

A cloud route table is an ordinary routing table, and longest prefix match decides where traffic from a subnet goes. A team runs a VPC, a private network in a cloud account, on 10.0.0.0/16, peered with a second VPC on 10.1.0.0/16 that holds a shared database. Its route table, as shown in the AWS console, has three rows.

Three destinations, and the target each one reaches:

• 10.0.3.7, another server in the same VPC. It matches the /16 local route and the /0 default; the /16 is longer, so the packet stays inside the VPC.
• 10.1.5.9, the database in the peered VPC. It matches the peering route and the default; the /16 wins, so it goes through the peering connection. It does not match the local route, because 10.1 is not 10.0.
• 198.51.100.20, a public API. It matches only the default, so it leaves through the internet gateway.

Two things are worth noticing.

It is the same rule as on a router. The console calls next hops "targets" and gives them resource names rather than addresses, but the decision is longest prefix match, row by row.

The local route cannot be overridden by a broader one. Even if someone adds a route for 10.0.0.0/8 through a VPN, traffic inside 10.0.0.0/16 still matches the local /16 first, because it is more specific. Traffic to 10.2.0.0, which matches only the /8 and the default, would go to the VPN.