AWS VPC routing tables are one of the most important components of cloud networking. They determine where network traffic goes after it leaves a subnet and help control communication between EC2 instances, databases, private services, on-premises networks, and the internet.
A routing table can look simple, but a single missing or incorrect route can cause major production problems. Applications may become unreachable, private servers may lose internet access, or traffic may unexpectedly take a different network path.
Understanding routing tables through real production scenarios makes troubleshooting much easier.
What Is an AWS VPC Routing Table?
A route table contains rules that determine where traffic destined for a particular IP address should be sent.
A typical route table might look like this:
Destination Target
10.0.0.0/16 local
0.0.0.0/0 igw-xxxxxxxx
The 10.0.0.0/16 route allows communication within the VPC, while 0.0.0.0/0 represents all IPv4 destinations not covered by a more specific route.
The target could be an Internet Gateway, NAT Gateway, Transit Gateway, VPC peering connection, virtual private gateway, or another supported networking component.
AWS uses longest-prefix matching when multiple routes could apply. In simple terms, the most specific matching route takes precedence.
For example:
10.0.0.0/16 → Target A
10.0.5.0/24 → Target B
Traffic destined for 10.0.5.20 follows the /24 route because it is more specific.
Production Problem 1: Public EC2 Instance Cannot Reach the Internet
Imagine an EC2 instance is deployed in a subnet and has a public IPv4 address. Administrators expect it to access the internet, but outbound connections fail.
The first assumption might be that the security group is blocking traffic. However, the route table may be the actual problem.
A public subnet normally requires a default route similar to:
Destination Target
0.0.0.0/0 Internet Gateway
If the default route is missing, the instance has no route for external IPv4 destinations.
The troubleshooting process should therefore verify:
- The subnet’s route table.
- The default route.
- The Internet Gateway attachment.
- The instance’s public addressing.
- Security group and network ACL rules.
Having a public IP address alone does not guarantee internet connectivity. Routing must also provide a path to the Internet Gateway.
Production Problem 2: Private EC2 Instance Cannot Download Updates
Private subnets commonly contain application servers and databases that should not accept direct inbound internet traffic.
Suppose a private EC2 instance suddenly cannot download operating system updates or contact an external API.
A typical design is:
Private EC2
↓
Private Route Table
↓
NAT Gateway
↓
Public Route Table
↓
Internet Gateway
↓
Internet
The private subnet needs a default route such as:
0.0.0.0/0 → NAT Gateway
If that route is missing or points to the wrong NAT Gateway, outbound internet connectivity will fail.
The NAT Gateway’s own subnet must also have a route to the Internet Gateway.
This creates an important troubleshooting principle: checking only the source subnet is not always enough. Follow the complete path through every network component.
Production Problem 3: Application Servers Cannot Reach a Database
Consider a three-tier architecture:
Internet
↓
Load Balancer
↓
Application Subnet
↓
Database Subnet
The application servers suddenly cannot connect to the database.
Security groups are checked and appear correct. The next step is to inspect routing.
If both subnets belong to the same VPC, their route tables normally contain the VPC’s local route:
10.0.0.0/16 → local
This route allows resources within the VPC to communicate according to the applicable security controls.
If the database is actually located in another VPC, however, a local route is not sufficient. The environment may require VPC peering or Transit Gateway connectivity, along with appropriate routes on both sides.
For VPC peering, for example, the relevant CIDR must be routed through the peering connection.
Production Problem 4: VPC Peering Works in One Direction Only
One of the most common routing mistakes in connected VPC environments is configuring only one side.
Suppose:
- VPC A = 10.10.0.0/16
- VPC B = 10.20.0.0/16
If VPC A needs to communicate with VPC B, the route table used by the source subnet in VPC A needs a route similar to:
10.20.0.0/16 → VPC Peering Connection
The corresponding route must also exist in VPC B:
10.10.0.0/16 → VPC Peering Connection
Routing is directional in terms of configuration. A route on one side does not automatically create a route on the other side.
When troubleshooting VPC peering, always inspect the route tables associated with the actual source and destination subnets.
Production Problem 5: On-Premises Network Cannot Reach AWS
Organizations frequently connect AWS environments to corporate networks using Site-to-Site VPN or AWS Direct Connect.
Suppose an on-premises server needs to access an EC2 instance in AWS.
A route might look like:
10.50.0.0/16 → Virtual Private Gateway
where 10.50.0.0/16 represents the corporate network.
But the return path is equally important. The AWS subnet needs a route toward the on-premises CIDR, and the on-premises network must know how to reach the AWS CIDR.
If only one side has the required route, the connection may fail or appear intermittent.
This is why production network troubleshooting should always examine forward and return paths.
Production Problem 6: More Specific Route Sends Traffic to the Wrong Destination
Consider a route table containing:
10.0.0.0/8 → Transit Gateway
10.20.0.0/16 → VPC Peering Connection
Traffic destined for 10.20.5.10 matches both routes.
AWS selects the more specific /16 route rather than the /8 route.
This can create unexpected behavior after a new connection or network expansion is introduced.
When troubleshooting routing conflicts, look for overlapping CIDRs and more-specific routes. A route that appears correct at first glance may not actually be the route AWS uses.
Production Problem 7: Subnet Was Associated With the Wrong Route Table
Another practical issue occurs when a subnet is accidentally associated with an unintended route table.
For example, administrators may create a new private route table but forget to associate the application subnet with it.
The subnet may continue using the previous route table, resulting in unexpected internet access or a missing route to internal services.
Always verify the actual route table association rather than assuming that the intended table is being used.
How to Troubleshoot Routing Problems
When production connectivity fails, use a consistent process:
1. Identify the source and destination
Determine the exact source IP, destination IP, subnet, and VPC.
2. Identify the subnet
Find which subnet contains the source resource and determine its associated route table.
3. Check the matching route
Look for the destination CIDR and determine which route AWS will select.
4. Validate the target
Confirm that the Internet Gateway, NAT Gateway, Transit Gateway, VPN, or peering connection is available and correctly configured.
5. Check the return path
Make sure the destination has a route back to the source network.
6. Check security controls
Once routing is confirmed, investigate security groups and network ACLs.
7. Use AWS troubleshooting tools
VPC Flow Logs and Reachability Analyzer can provide additional visibility into traffic paths and rejected connections.
Conclusion
AWS VPC routing tables play a critical role in maintaining reliable communication between cloud resources, external networks, and internet-facing services. Even a small routing configuration error can disrupt production applications, prevent private instances from accessing external services, or interrupt communication between connected VPCs.
Effective troubleshooting requires more than checking whether a route exists. Start by identifying the source and destination, verify the subnet’s actual route table association, and determine which route AWS selects using longest-prefix matching. Then validate the target, inspect forward and return paths, and review security groups and Network ACLs to identify additional restrictions.
Tools such as VPC Flow Logs and Reachability Analyzer can provide valuable visibility into network behavior and help narrow down connectivity issues. Regularly reviewing route tables, documenting network changes, and validating configurations after deployments can also reduce unexpected outages.
By following a structured approach, administrators can identify routing failures more accurately, minimize unnecessary configuration changes, and maintain dependable connectivity across AWS environments.
Facing issues?
Our technical support
engineers can solve it.
