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

How Route Tables Enforce Public vs. Private Subnets

A subnet’s classification as “public” or “private” isn’t an inherent property configured directly on the subnet itself — it’s entirely determined by which route table is associated with it. A subnet becomes “public” specifically because its associated route table contains a route sending internet-bound traffic (typically 0.0.0.0/0) to an internet gateway; a subnet is “private” because its route table lacks that route, sending internet-bound traffic to a NAT gateway instead (for outbound-only access) or nowhere at all. This means the distinction between public and private subnets is purely a routing configuration decision, and understanding this is essential for correctly diagnosing connectivity issues — a resource in a subnet with the “wrong” route table associated will have unexpected connectivity regardless of security group or NACL configuration, since traffic never reaches the intended gateway in the first place.