This content originally appeared on DEV Community and was authored by Irfan Satrio
Exploring how traffic moves inside a VPC can make AWS networking feel much more approachable. Route tables and Internet Gateways (IGWs) quietly influence how your subnets function across your network. In this article, we’ll walk through them step by step so the concepts stay clear and grounded.
The Role of Route Tables in a VPC
Route tables are essentially instruction sets that guide traffic within your VPC. Each subnet connects to exactly one route table, which determines what that subnet can reach. The default local route (for example, 10.0.0.0/16 local) lets all subnets talk to each other without extra configuration. Anything beyond that depends on the routes you add.
Think of routes like road signs: “If traffic wants to go to X, send it to Y.”
For instance, a 0.0.0.0/0 route pointing to an IGW makes a subnet public. Pointing the same destination to a NAT Gateway makes it private with controlled outbound access. The logic is simple, but the design impact is significant.
Route tables also become more interesting in multi-VPC environments. You might add a route to another VPC via peering or a route to an on-premises network through a VPN. Without clear routes, traffic may fail to reach its destination or take inefficient paths.
Public Subnets and Internet Gateways
An Internet Gateway provides a path between your VPC and the internet. It doesn’t automatically expose your resources; the route table determines traffic flow, and instances need public IPs or Elastic IPs. Without those, the IGW sits idle.
Only subnets explicitly configured with routes to the IGW and instances with public IPs become public. Everything else remains internal by default.
Example: Your web server subnet is public, allowing external traffic. Meanwhile, your backend API or database subnet remains private and unreachable from the internet.
This separation ensures intentional design and helps prevent accidental exposure of internal systems. It also means you can confidently design hybrid architectures without worrying about default internet access.
Private Subnets and Controlled Outbound Traffic
Private subnets typically route outbound traffic through a NAT Gateway or sometimes VPC endpoints. Their route tables may have a 0.0.0.0/0 → NAT route, allowing them to reach the internet without being reachable from outside.
Subnets can also remain fully isolated. If the route table only contains the local VPC route, they cannot leave the VPC. This is common for internal services, like database layers or batch processing workloads, where internet access isn’t needed.
You can even mix private subnets: some with NAT access for updates or API calls, and some fully isolated for sensitive workloads. This flexibility is one of the reasons AWS networking scales well for different application needs.
How Traffic Flows End-to-End
Understanding route tables in isolation is useful, but seeing the end-to-end traffic flow makes networking clearer. For example:
- A client requests data from a public web server in your VPC.
- The server’s subnet route table directs traffic through the IGW.
- Responses travel back via the IGW to the client.
For a private subnet:
- An internal application needs to call an external API.
- Traffic goes to the NAT Gateway.
- The NAT translates the private IP and sends the request out.
- Responses return via the NAT, preserving internal IP addresses.
Visualizing these flows—either in a diagram or with mental models—makes it easier to predict how changes in routes affect the network.
Route Table Patterns That Keep Things Predictable
As VPCs grow, predictable routing becomes essential. Some patterns to follow:
- Separate route tables for public and private subnets.
- Avoid mixing IGW and NAT routes unnecessarily.
- Keep routes minimal and descriptive.
- Consider how peering, Transit Gateway, or multi-account architectures will interact with your tables.
Another useful approach is documenting all route table associations in a simple table or spreadsheet. When you add subnets or connect new accounts, this reference helps avoid misconfigurations.
These habits reduce mistakes and make debugging easier as the network grows.
How IGWs Fit Into Larger Architectures
In hybrid setups, shared services, or multi-account designs, IGWs maintain their role as the gateway to the internet. The route table determines which traffic exits through the IGW versus staying internal through Direct Connect or VPNs. AWS doesn’t forward traffic between these paths automatically, so each destination needs a clear route.
Large architectures benefit from keeping IGW routes simple. Complex configurations can introduce unexpected routing loops or unintended internet exposure. Even small changes—like adding an IGW route to a newly created subnet—can have cascading effects if not planned.
Common VPC Routing Scenarios
Here are a few typical scenarios you might encounter:
- Web server on a public subnet: Requires a route to the Internet Gateway and a public IP to be reachable from the internet.
- Backend API on a private subnet: Uses a NAT Gateway for outbound internet access while remaining unreachable from the public internet.
- Database server: Remains isolated, with the route table only including local routes.
- Hybrid access scenario: Some subnets connect to on-prem via VPN or Direct Connect, while others use the IGW for internet access.
These patterns are commonly seen in practice and help illustrate how routing and subnet design affect connectivity across the VPC.
Operational Considerations
Routing decisions impact both operations and cost:
- NAT Gateways incur charges, so overuse in private subnets can increase costs.
- Public subnets reduce NAT reliance but require careful security configurations.
- Troubleshooting connectivity issues often begins by checking route tables and subnet associations.
Clear labeling of route tables and consistent patterns make ongoing management simpler. Over time, this makes scaling, auditing, and monitoring much more manageable.
Conclusion
Route tables and Internet Gateways define how your VPC connects to the outside world and how your subnets behave internally. Once you understand how a single default route can shift a subnet’s role, AWS networking starts to feel much more manageable. And once that idea becomes clear, it’s easier to reason about how everything in your VPC fits together.
This content originally appeared on DEV Community and was authored by Irfan Satrio
Irfan Satrio | Sciencx (2025-11-19T22:11:03+00:00) A Simple Guide to Route Tables and Internet Gateways in AWS. Retrieved from https://www.scien.cx/2025/11/19/a-simple-guide-to-route-tables-and-internet-gateways-in-aws/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.