Route tables and routers

The implicit router

There is no router resource in a VPC. Every VPC has an implicit router that AWS operates, and route tables are how you configure it.

Each VPC has an implicit router.
Route tables configure it.
A VPC can hold several route tables.
Each subnet is associated with exactly one route table.
A subnet with no explicit association uses the VPC’s main route table.

The main route table is created with the VPC. Editing it changes routing for every subnet that has not been explicitly associated with another table, which is easy to do by accident — associating each subnet explicitly, and leaving the main table minimal, avoids it.

Route table contents

Every route table contains a local route for the VPC’s CIDR block, which cannot be removed, and whatever routes you add. Selection is by longest prefix match: the most specific route wins, and 0.0.0.0/0 is the fallback.

Targets can be an internet gateway, an egress-only internet gateway, a NAT gateway, a virtual private gateway, a transit gateway, a VPC peering connection, a gateway VPC endpoint, or a network interface.

For route resolution and target ID prefixes, see VPC routing and BGP.

Scope

Region. Route tables are Regional resources. One cannot be used in another Region.
Availability Zone. Route tables are a VPC-level construct, but because subnets are zonal, the table associated with a subnet governs traffic in that zone. Zone-specific routing — pointing each zone’s private subnets at the NAT gateway in their own zone — is done by associating a different route table with each zone’s subnets.
VPN. Route tables can hold routes to a virtual private gateway, but are not associated with a VPN connection.

Reaching an on-premises network

Add a route for the on-premises prefix pointing at the virtual private gateway attached to the VPN connection, or at the transit gateway if the VPN terminates there:

192.168.0.0/16 → vgw-0123456789abcdef0

Route propagation

Rather than entering on-premises prefixes by hand, enable route propagation on a route table. The attached virtual private gateway then installs the routes it learns over BGP automatically, and withdraws them when the BGP session drops.

This is what makes VPN and Direct Connect failover work without manual intervention. Note two things about it:

A statically entered route always takes precedence over a propagated route for the same destination, so a leftover manual entry silently defeats the failover it was meant to support.
Propagation is per route table. Enabling it on one table and forgetting another produces asymmetric routing that works from some subnets and not others.

Practice

Associate every subnet with an explicit route table rather than relying on the main table.
Use separate route tables for public and private subnets, and per Availability Zone where zonal NAT gateways are in use.
Audit periodically for blackhole routes — entries whose target has been deleted.
Name and tag route tables by role: public-eu-west-2a, private-eu-west-2b.