Route Tables as Security Controls

A route table is a set of rules that decides where network traffic from a subnet is directed. Beyond connectivity, route tables are a security control: by controlling which destinations a subnet can reach, you decide what is even possible before any firewall rule is consulted.

Each route maps a destination CIDR to a target such as an internet gateway, NAT gateway, peering connection, or transit gateway. AWS uses the most specific matching route for each packet. The local route for the VPC CIDR is always present and cannot be removed.

The presence or absence of a route to the internet gateway is what makes a subnet public or private. Removing that route instantly turns a subnet private. This is why route tables, not subnet settings, are the true determinant of internet exposure.

Each subnet is associated with exactly one route table, though a route table can serve many subnets. Subnets without an explicit association use the VPC main route table. Keeping public and private subnets on separate route tables makes their access rules clear and auditable.

To isolate a data subnet, give it a route table with no internet or NAT route at all, only the local VPC route. Such a subnet can communicate within the VPC but has no path to the internet in either direction, enforcing isolation structurally rather than relying solely on firewall rules.

When you create a gateway VPC endpoint for S3 or DynamoDB, AWS adds a route to the endpoint in the relevant route tables. This directs that AWS-service traffic over the private endpoint instead of the internet, a routing change that both enables and secures private access.

Route tables can force traffic through an inspection appliance or AWS Network Firewall before it leaves the VPC. By routing a subnet egress to a firewall endpoint rather than directly to NAT, you guarantee every outbound packet is inspected. Routing thus enforces where security checks happen.

To reach another VPC, a route must point to a peering connection or transit gateway. Omitting that route keeps networks separate. Adding overly broad routes can unintentionally open paths between environments, so route entries should be as specific as the connectivity you truly intend.

An overly permissive route, such as sending 0.0.0.0/0 to an internet gateway in a tier that should be private, silently makes that tier public. Auditing route tables for unexpected internet or cross-VPC routes is an important part of securing a VPC.

Combine routing with NACLs and security groups: route tables decide what paths exist, NACLs and security groups decide what traffic is allowed on those paths. A destination with no route is unreachable regardless of firewall rules, making routing the outermost layer of network control.

Treat route tables as a deliberate security boundary. Use them to define public versus private, isolate sensitive subnets, steer traffic through inspection, and control cross-VPC reach. Reviewing routes for unintended paths is as important as reviewing firewall rules.

Apply route-table security reasoning.

Route tables map destination CIDRs to targets and use the most specific match; the local VPC route is always present. They define public versus private via the internet-gateway route, isolate sensitive subnets (local route only), direct traffic to VPC endpoints or inspection firewalls, and control cross-VPC reach through peering or transit routes. Audit for unintended internet or cross-VPC paths.