AWS Route Tables: The Traffic Controllers of your VPC
In the world of AWS Networking, a Route Table is a set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed. Think of it as the GPS system for every data packet entering or leaving a subnet.
The Real-World Analogy
Imagine a large office building (the VPC). Each floor (Subnet) has a Receptionist (Route Table). When a delivery person (Data Packet) wants to leave the floor, they ask the receptionist. The receptionist looks at their clipboard (Routing Rules) and says: “If you’re looking for the Breakroom, go to Door A. If you’re looking for the Outside World, go to the Main Lobby Elevator.” Without the receptionist, the delivery person wouldn’t know which door leads where.
Core Concepts & Configuration
1. The Local Route
Every route table contains a default rule for communication within the VPC. This is known as the Local Route. It matches the CIDR block of your VPC and allows all subnets within that VPC to talk to each other. Important: You cannot delete or modify this route.
2. Main vs. Custom Route Tables
- Main Route Table: The table that automatically comes with your VPC. It controls the routing for all subnets that are not explicitly associated with any other route table.
- Custom Route Table: A table you create manually. It is best practice to leave the Main Route Table in its original state and create Custom Route Tables for specific needs (e.g., Public vs. Private subnets).
3. Subnet Association
A subnet must be associated with exactly one route table at a time. However, you can associate multiple subnets with the same route table.
Public vs. Private Subnet Comparison
| Feature | Public Subnet | Private Subnet |
|---|---|---|
| Default Route (0.0.0.0/0) | Points to an Internet Gateway (IGW) | Points to a NAT Gateway or nothing |
| Direct Internet Access | Yes (Inbound & Outbound) | Outbound only (via NAT) or None |
| Public IP Requirement | Instances need Public/Elastic IPs | Instances use Private IPs only |
| Common Use Case | Load Balancers, Bastion Hosts | Databases, Application Servers |
Decision Matrix: If–Then Guide
- If you need a subnet to access the public internet directly Then add a route
0.0.0.0/0targeting anigw-xxxxxxxx. - If your private instances need to download updates from the internet Then add a route
0.0.0.0/0targeting anat-xxxxxxxx. - If you need to connect two VPCs Then add a route for the peer VPC CIDR targeting a
pcx-xxxxxxxx(VPC Peering). - If you are connecting to an On-Premise data center Then target a
vgw-xxxxxxxx(Virtual Private Gateway) ortgw-xxxxxxxx(Transit Gateway). - If you want to access S3/DynamoDB without leaving the AWS network Then use a Gateway Endpoint and the route table will be updated automatically.
Exam Tips and Gotchas
- Longest Prefix Match: If a route table has overlapping routes, AWS uses the most specific route (the one with the longest prefix/smallest CIDR). For example,
10.0.1.0/24is preferred over10.0.0.0/16. - Implicit Association: If you don’t manually associate a subnet with a table, it defaults to the Main Route Table. Exam Tip: Avoid using the Main table for sensitive routing to prevent accidental exposure.
- Edge Associations: You can now attach route tables to Internet Gateways and Virtual Private Gateways to redirect incoming traffic to security appliances (Ingress Routing).
- Target Limits: You cannot target a Network Interface (ENI) that is in a different VPC unless it’s via a Peering/Transit Gateway connection.
Topics covered:
Summary of key subtopics covered in this guide:
- Local Routes and CIDR priorities
- Main vs. Custom Route Table differences
- Internet Gateway (IGW) vs. NAT Gateway routing
- VPC Peering and Transit Gateway targets
- Gateway Load Balancer (GWLB) endpoints
- The “Longest Prefix Match” rule
Route Table Architecture Infographic
Integrations: Works seamlessly with Direct Connect, VPN, and VPC Endpoints. Route propagation can be enabled for BGP routes from VGW.
Speed: Routing happens at the SDN layer with no latency penalty. Limits: 50 non-propagated routes per table (adjustable to 100).
Pricing: Route tables are free. However, the targets they point to (NAT Gateways, Transit Gateways) often incur hourly and data-processing costs.
Production Use Case: Hub-and-Spoke
In a multi-account setup, a Transit Gateway acts as a central hub. Each “Spoke” VPC has a route table entry pointing traffic destined for other VPCs or On-Premise to the Transit Gateway ID (tgw-xxxx). This centralizes management and reduces the complexity of full-mesh peering.