Route Table

What is a route table?

A route table is an ordered set of rules — destination CIDR → target — evaluated by longest-prefix match: the most specific matching route wins. Every subnet associates with exactly one table; every packet leaving instances in that subnet consults it. The local VPC route (10.0.0.0/16 → local) exists implicitly; everything else — internet, NAT, peering, VPNs, endpoints — is a row you add.

Longest-prefix match is the whole logic

A table containing 0.0.0.0/0 → igw and 10.8.0.0/16 → peering sends traffic for 10.8.4.7 over the peering connection (more specific /16 beats /0) and everything else to the internet. Understanding this one rule lets you read any cloud network: “public subnet” is shorthand for “its table’s default route targets an internet gateway”; inspection architectures work by inserting more-specific routes toward firewalls; VPN failover is two routes with different specificity.

Debugging with route tables

Half of “can’t reach X” tickets resolve to routing, not security groups. The triage order that saves hours: does the subnet’s table (not the main table you assumed) contain a route to the destination? Is there a more specific route hijacking it? Does the return path exist on the far side — routing must work in both directions, and asymmetric routes are the classic peering failure.

What people get wrong

• Editing the main route table thinking it applies everywhere — subnets with explicit associations ignore it.
• Forgetting the return route: adding the outbound row and not the remote side’s route back.
• Blackhole routes after teardown — routes pointing at deleted NATs/peerings fail silently; audit for blackhole status after infrastructure changes.

Primary source: AWS VPC documentation — route tables