AWS Route Tables Explained: Routing Traffic Inside a VPC

Quick Answer

An AWS route table is a collection of routing rules, known as routes, that determine where network traffic from your VPC subnets is directed. Every subnet in your VPC must be associated with a route table—either a custom table or the VPC's default main route table. Each rule pairs a destination IP address range (CIDR block) with a target gateway, network interface, or virtual appliance. When a packet leaves an EC2 instance or container, AWS checks the subnet's associated route table for the most specific matching CIDR block and forwards the packet to the specified target. If no specific match is found, the packet follows the default route or is dropped.

What Is a Route Table?

At its core, an AWS route table is a logical construct living inside your VPC that maps destination CIDR blocks to network targets. When you spin up a fresh VPC, Amazon automatically provisions a main route table for you. This table dictates traffic flow for any subnet that is not explicitly linked to a custom route table.

Think of a route table as a smart intersection controller. When traffic packets are generated by compute resources such as Amazon EC2 instances, containers running on Amazon ECS or EKS, or database nodes, those packets hit the virtual network layer. The network layer references the active route table associated with the subnet to decide whether the traffic stays internal, gets pushed out to an internet gateway, or routes through a virtual private gateway toward an on-premises data center via an AWS Direct Connect or VPN connection.

Managing these tables effectively requires tracking which subnets map to which routing rules. Misconfigurations here are among the most frequent causes of unreachable services, failed database migrations, and broken application deployments in cloud environments.

Routes and Targets

Every entry inside a route table consists of two fundamental pieces of data: a destination and a target. The destination specifies the IP address range—expressed in CIDR notation—that the rule applies to. The target is the physical or virtual appliance that handles traffic matching that destination range.

Local route

Every route table created within an AWS VPC automatically includes a default local route. This local route typically covers your VPC's entire IPv4 CIDR block and points to a target designated as local. It enables seamless communication between all resources inside the VPC, allowing instances across different subnets to talk to each other without needing external routing mechanisms or gateways.

0.0.0.0/0

Often referred to as the default route, the 0.0.0.0/0 destination CIDR block matches all IPv4 traffic that does not match any other more specific route in the table. When mapped to an Internet Gateway or NAT Gateway, it acts as a catch-all route for internet-bound traffic. Because it opens pathways to the wider internet, handling 0.0.0.0/0 requires strict security group policies and network access control lists to prevent unauthorized inbound exposure.

IGW

An Internet Gateway, or IGW, serves as a horizontally scaled, redundant VPC component that permits communication between instances in your VPC and the public internet. When used as a target in a route table entry for the 0.0.0.0/0 destination, it translates private IP addresses to public IPs for outbound traffic and routes incoming public requests back to the correct instances.

NAT

Network Address Translation (NAT) gateways or NAT instances allow resources located in private subnets to initiate outbound connections to the internet—such as downloading software patches or pulling container images—while blocking any unsolicited inbound traffic connections originating from external sources.

Route association

Route association defines the explicit link between a specific subnet and a designated route table. While every subnet must belong to a route table, understanding whether that association is explicit or handled by the default main route table is vital for maintaining predictable network behaviors as your cloud infrastructure scales.

Subnet Associations

To make a route table active for a given part of your architecture, you must associate it with one or more subnets. A single route table can be associated with multiple subnets, meaning all those subnets will share the exact same routing rules. However, a single subnet can never be associated with more than one route table at a time.

When a subnet is created, if you do not explicitly assign a custom route table to it, AWS automatically hooks it up to the VPC's main route table. While convenient for simple setups, relying entirely on the main route table in complex production environments is a recipe for accidental misconfigurations. Best practices dictate creating custom route tables for public and private tiers, leaving the main route table as an empty or highly restricted fallback.

Explicit associations override implicit ones. If you explicitly associate Subnet A with Route Table Custom-1, any changes you make to the main route table will no longer affect Subnet A. This gives engineers precise, granular control over network traffic per subnet tier.

Public Routing

A public subnet is characterized by a route table that directs internet-bound traffic directly to an Internet Gateway. For a subnet to be considered truly public, its associated route table must contain a route where the destination 0.0.0.0/0 points directly to an IGW ID (e.g., igw-0123456789abcdef0).

When an EC2 instance inside a public subnet sends a packet destined for an external IP address, the routing engine identifies the 0.0.0.0/0 match, forwards the packet to the Internet Gateway, and egresses the traffic onto the public internet. For inbound traffic to succeed, the instance must also possess a public IPv4 address or Elastic IP, and the associated security groups and network ACLs must permit the inbound port traffic.

Security considerations for public routing require constant vigilance. Never place databases, backend processing workers, or internal caching layers inside a public subnet. Keep public subnets strictly reserved for public-facing load balancers, bastion hosts, or edge proxy instances.

Private Routing

Private subnets host workloads that require internal connectivity or outbound internet access without being exposed to inbound attacks from the public internet. This includes application servers, backend microservices, and relational databases.

To allow these private resources to reach out to the internet—such as fetching OS updates or communicating with third-party APIs—you configure a private route table. In this table, the 0.0.0.0/0 destination points to a NAT Gateway or a NAT instance deployed in a separate public subnet, rather than directly to an Internet Gateway.

Traffic flows seamlessly out through the NAT Gateway, which translates the private instance IP to its own public IP address and manages the return trip statefully. External entities on the internet cannot initiate connections back to your private instances because the NAT Gateway only allows responses to traffic initiated from within the private subnet.

Troubleshooting

Network troubleshooting in AWS often starts and ends at the route table. When traffic fails to flow between subnets or out to the internet, engineers frequently encounter a few common pitfalls.

One common mistake is missing return paths for asymmetric traffic flows or VPC peering connections. If Server A in Subnet 1 pings Server B in Subnet 2, but Subnet 2's route table lacks a route back to Subnet 1's CIDR, the packets will arrive but responses will vanish. Another frequent issue is overly broad routing definitions or typos in destination CIDR blocks that inadvertently black-hole traffic.

To troubleshoot effectively, use the AWS VPC Reachability Analyzer or test connectivity using standard tools like traceroute or nc from bastion hosts. Always verify that your subnet association is pointing to the exact route table you edited, as it is very common to update a custom route table while forgetting that the target subnet is still implicitly bound to the main route table.

Verification Examples

Validating your routing configuration can be performed quickly using the AWS Command Line Interface (CLI). To inspect the route tables associated with your VPC, run the following command:

aws ec2 describe-route-tables \
    --filters "Name=vpc-id,Values=vpc-0123456789abcdef0"

To view explicit subnet associations and verify that your public subnets point to your Internet Gateway, review the Routes and Associations arrays in the JSON response. You can also test active routing paths from an instance using networking diagnostics:

# Check outbound internet connectivity path
traceroute -n -m 15 8.8.8.8

By systematically verifying route entries against your architecture diagrams, you can catch misconfigured targets before they impact production workloads.