VPC Route Table: What It Is and When to Use It
Definition
A VPC Route Table contains a set of rules, called routes, that determine where network traffic from your subnets or gateways is directed. It functions as the virtual router for your Amazon Virtual Private Cloud (VPC), controlling the flow of traffic between subnets and to destinations outside the VPC, such as the internet or on-premises networks.
How It Works
A VPC Route Table is a fundamental component of Amazon VPC that dictates the path of network packets. Each VPC you create comes with an implicit router and a main route table to control traffic.
Core Components of a Route:
- Destination: The range of IP addresses (in CIDR notation, like
10.0.0.0/16or0.0.0.0/0) where you want traffic to go. - Target: The gateway, network interface, or connection through which to send the traffic for the specified destination. Common targets include an Internet Gateway (IGW), NAT Gateway, Virtual Private Gateway (VGW), VPC Peering Connection, Transit Gateway, or a specific EC2 instance's Elastic Network Interface (ENI).
When traffic originates from a subnet, AWS consults the associated route table to find the most specific matching route for the destination IP address. This is known as the "longest prefix match." For example, a route to 172.31.50.0/24 would be chosen over a route to 172.31.0.0/16 for traffic destined to 172.31.50.10.
Types of Route Tables:
- Main Route Table: Every VPC is created with a main route table by default. Any subnet that is not explicitly associated with another route table is implicitly associated with the main one. A best practice is to leave the main route table in its default state (with only the
localroute) and create custom route tables for all subnets to ensure explicit control over routing. - Custom Route Table: These are route tables you create for your VPC. Associating a subnet with a custom route table overrides its association with the main table, providing granular control over its traffic flow.
Every route table, whether main or custom, contains a default, non-modifiable local route that enables communication between all resources within the VPC.
Subnet and Gateway Associations:
- Subnet Association: Each subnet must be associated with exactly one route table. However, a single route table can be associated with multiple subnets.
- Edge Association: You can also associate a route table with an Internet Gateway or a Virtual Private Gateway. This is called a gateway route table and is used to control traffic entering the VPC.
Key Features and Limits
- Routes per Route Table: The default quota is 500 non-propagated routes per route table. This can be increased to a maximum of 1,000, though network performance might be impacted. This quota is applied separately for IPv4 and IPv6 routes.
- Route Tables per VPC: You can have up to 200 route tables per VPC (this is an adjustable quota).
- Local Route: Every route table automatically includes a
localroute for the VPC's CIDR block(s), enabling internal communication. This route cannot be deleted. - Route Propagation: For connections via a Virtual Private Gateway (to AWS Site-to-Site VPN or AWS Direct Connect), you can enable route propagation. This feature automatically adds routes from your on-premises network to your route table, simplifying network management.
- Supported Targets: Routes can target a wide array of resources, including Internet Gateways, NAT Gateways, Virtual Private Gateways, Egress-Only Internet Gateways, VPC Peering Connections, Transit Gateways, VPC Endpoints (Gateway and Interface), and specific Network Interfaces.
Common Use Cases
- Creating Public Subnets: To make a subnet public, you associate it with a route table that has a route for
0.0.0.0/0(all IPv4 internet traffic) pointing to an Internet Gateway (IGW). This allows resources like web servers to have direct inbound and outbound internet access. - Creating Private Subnets with Outbound Internet: For resources like application servers or databases that need to download updates but should not be directly reachable from the internet, you create a private subnet. Its route table will have a
0.0.0.0/0route pointing to a NAT Gateway located in a public subnet. - Creating Isolated Subnets: For maximum security, such as for a highly sensitive database, a subnet can be associated with a route table that only contains the
localroute. This permits communication within the VPC but provides no path to the internet or on-premises networks. - Hybrid Cloud Connectivity: When connecting a VPC to an on-premises data center via AWS Direct Connect or a VPN, route tables are configured (often with route propagation) to direct traffic destined for the on-premises IP ranges to a Virtual Private Gateway (VGW).
- Centralized Traffic Inspection: In advanced architectures using AWS Network Firewall or a third-party appliance, route tables are modified to direct traffic through the firewall's VPC endpoint for inspection before it proceeds to its final destination, such as an Internet Gateway or another subnet.
Pricing Model
VPC Route Tables themselves are free of charge. There is no cost for creating route tables or for the number of routes you add.
However, you are billed for the AWS resources that your routes target. For example:
- NAT Gateways: Charged per hour of availability and per gigabyte of data processed.
- Interface VPC Endpoints (AWS PrivateLink): Charged per hour and per gigabyte of data processed.
- Data Transfer: Standard AWS data transfer charges apply for traffic that leaves the AWS network via an Internet Gateway or crosses regions via VPC Peering or a Transit Gateway.
Gateway VPC Endpoints for Amazon S3 and Amazon DynamoDB are a notable exception and are completely free, making them a significant cost optimization tool.
Pros and Cons
Pros:
- Granular Traffic Control: Provides precise, subnet-level control over the flow of network traffic.
- Foundation of Network Security: Essential for creating network segmentation (e.g., public vs. private tiers) and implementing a defense-in-depth security posture.
- No Direct Cost: The feature itself is free, allowing for complex routing architectures without direct charges.
- High Availability: As a core managed component of the VPC, it is inherently scalable and highly available.
Cons:
- Configuration Complexity: Managing many route tables across a large number of VPCs can become complex and prone to error.
- Potential for Misconfiguration: A single incorrect route can lead to a network "blackhole," causing connectivity loss that can be difficult to troubleshoot.
- Subnet Limitation: A subnet can only be associated with one route table at a time, which requires careful planning for subnets with mixed routing needs.
Comparison with Alternatives
Route Tables are often discussed alongside Security Groups and Network ACLs (NACLs), but they serve distinct purposes:
-
Route Table vs. Network ACL (NACL):
- Function: A Route Table directs traffic (like a road sign). A NACL filters traffic at the subnet boundary (like a security checkpoint for a neighborhood).
- Scope: Route Tables are associated with subnets. NACLs are also associated with subnets.
- State: Route Tables are inherently stateless in their operation, simply forwarding packets. NACLs are stateless firewalls, meaning you must define explicit rules for both inbound and outbound return traffic.
-
Route Table vs. Security Group (SG):
- Function: A Route Table directs traffic at the subnet level. A Security Group filters traffic at the resource level (e.g., an EC2 instance's network interface).
- Scope: Route Tables apply to an entire subnet. Security Groups apply to a network interface.
- State: Security Groups are stateful firewalls. If you allow an inbound request, the outbound response is automatically permitted, regardless of outbound rules.
These three components work together in order: Route Table -> Network ACL -> Security Group for inbound traffic.
Exam Relevance
VPC Route Tables are a critical topic for several AWS certifications, especially:
- AWS Certified Solutions Architect - Associate (SAA-C03)
- AWS Certified SysOps Administrator - Associate (SOA-C02)
- AWS Certified Advanced Networking - Specialty (ANS-C01)
Key exam topics include:
- Differentiating between a public and private subnet based on the route table's target for the
0.0.0.0/0route (IGW vs. NAT Gateway). - Understanding the difference between the main route table and custom route tables.
- Knowing the distinct functions of Route Tables, Security Groups, and Network ACLs.
- Configuring routes for various targets like NAT Gateways, Internet Gateways, and Virtual Private Gateways.
- The concept of "longest prefix match" for route prioritization.
Frequently Asked Questions
Q: What is the difference between a main route table and a custom route table?
A: Every VPC has one main route table created by default. Any new subnet is automatically associated with the main route table unless you specify a different one. A custom route table is any other route table you create. The best practice is to explicitly associate all subnets with custom route tables you've configured for their specific purpose (e.g., a 'public-rtb' or 'private-rtb') and leave the main route table unmodified. This prevents accidental routing changes for newly created subnets.
Q: My EC2 instance in a private subnet can't connect to the internet. What should I check in the route table?
A: First, check the route table associated with the instance's subnet. It must have a route for the destination 0.0.0.0/0 with the target set to a NAT Gateway. Second, verify that the NAT Gateway itself is placed in a public subnet. Finally, ensure the public subnet's route table has its own 0.0.0.0/0 route pointing to an Internet Gateway.
Q: Can a subnet have more than one route table?
A: No, a subnet can be associated with only one route table at any given time. However, you can associate a single route table with multiple subnets, which is a common pattern for applying the same routing rules to all subnets within a particular tier (e.g., all private application subnets).
This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.