Understanding AWS Networking: A Guide to Route Tables and Gateways

AWS networking is where cloud design stops being abstract and starts affecting uptime, security, and cost. If a workload cannot reach an update repository, if a bastion host is exposed by mistake, or if a private app tier suddenly loses outbound access, the root cause is often in the same place: route tables, gateways, and subnet design. These are not background details. They decide where traffic can go, where it cannot go, and which paths are considered valid inside a Virtual Private Cloud (VPC).

This guide breaks that down in practical terms. You will see how route tables, internet gateways, NAT gateways, and other routing options fit together, and how they shape the difference between public and private subnets. The goal is not just to explain the theory. The goal is to help you design cleaner VPCs, spot common mistakes faster, and troubleshoot routing problems without guessing. If you work in cloud operations, architecture, security, or platform engineering, these are the concepts you use every day whether you notice them or not.

We will connect the model to real implementation patterns, including three-tier architectures, hybrid connectivity, and private access to AWS services. If you are studying AWS networking through ITU Online IT Training, this is the kind of foundation that pays off immediately in labs, production reviews, and incident response.

AWS Networking Fundamentals

The VPC is the isolated network boundary for your AWS resources. Think of it as your own logically separated network inside AWS, with control over IP ranges, subnets, routing, and external connectivity. Every EC2 instance, load balancer, database, or endpoint you place inside a VPC depends on that network design to communicate safely and predictably.

A VPC is divided into subnets, which are smaller network segments tied to a specific Availability Zone. Subnets are how you separate workloads into public and private zones. A public subnet usually has a route to the internet, while a private subnet does not. That distinction matters because it determines whether a resource can be reached directly from outside the VPC or only through controlled paths.

CIDR blocks define the IP ranges available to the VPC and its subnets. For example, a VPC might use 10.0.0.0/16, while subnets use smaller ranges such as 10.0.1.0/24 and 10.0.2.0/24. The size of the CIDR block affects how many private IP addresses you can allocate, and poor planning here becomes painful later when you need to expand.

Routing is the process that decides where network traffic should go. In AWS, the route table is the rule set that performs that decision. It does not filter traffic like a firewall. It simply says, “If traffic is headed for this destination, send it to that target.”

That distinction is easy to confuse with security groups and network ACLs. Security groups are stateful instance-level firewalls. Network ACLs are stateless subnet-level filters. Route tables do neither job. They control direction, not permission. If traffic cannot leave a subnet, the route table may be the reason. If traffic reaches the subnet but is blocked, the security group or NACL may be the issue.

• VPC: the isolated AWS network boundary.
• Subnet: a segment of the VPC tied to an Availability Zone.
• CIDR block: the IP range assigned to the VPC or subnet.
• Route table: the traffic direction map.
• Security group/NACL: traffic filtering controls.

Route Tables Explained

A route table is the set of rules that tells AWS where to send traffic from a subnet. Each route entry has two parts: a destination and a target. The destination is the IP range the rule applies to. The target is the next hop AWS should use.

For example, a route entry might send 10.0.0.0/16 to local. That means all traffic inside the VPC stays inside the VPC. Another route might send 0.0.0.0/0 to an internet gateway, which means all traffic not matched by a more specific route goes out to the internet path.

Every subnet is associated with exactly one route table at a time. If you do nothing, the subnet uses the main route table for the VPC. That main table often contains the local route by default. In practice, many teams create explicit public and private route tables instead of relying on the main table, because that makes the design easier to read and audit.

Common route targets include:

• local: traffic within the VPC CIDR.
• Internet Gateway: internet-bound traffic for public subnets.
• NAT Gateway: outbound internet access for private subnets.
• Virtual Private Gateway: hybrid connectivity to on-premises networks.
• Transit Gateway: centralized routing across multiple VPCs and networks.

A critical rule is longest prefix match. If two routes could match the same traffic, AWS uses the most specific destination. For example, a route to 10.0.1.0/24 will win over a route to 10.0.0.0/16 for traffic to 10.0.1.25. That is how you override broad routes with more precise ones.

Route tables do not “allow” traffic. They determine the next hop. If the next hop is wrong, the packet never reaches the right network path.

That matters in real environments. A route table can contain a default route to a NAT gateway, but a more specific route to an internal network through a transit gateway will still take precedence. Understanding that behavior prevents accidental black holes and unexpected traffic paths.

Public Subnets and Internet Access

A subnet is considered public when its route table contains a path to the internet through an internet gateway. In AWS terms, the usual marker is a route for 0.0.0.0/0 pointing to the Internet Gateway. Without that route, the subnet is not public, even if the VPC has an internet gateway attached elsewhere.

That point causes frequent confusion. An internet gateway attached to the VPC does not automatically make every subnet public. The route table associated with the subnet must point default traffic to that gateway. Then the resource inside the subnet also needs a public IPv4 address or Elastic IP to be reachable from the internet.

Outbound access and inbound reachability are related but not identical. A resource with a public IP can send and receive internet traffic if the route table, gateway attachment, security group, and NACL all align. A resource without a public IP can still initiate outbound traffic if another component, such as a NAT gateway, handles egress.

Typical workloads in public subnets include:

• Bastion hosts for controlled administrative access.
• Application load balancers that must receive internet traffic.
• NAT gateways that provide outbound access for private subnets.
• Public-facing reverse proxies or edge services.

A common mistake is placing an EC2 instance in a subnet with an internet gateway somewhere in the VPC and assuming it is reachable. If the subnet route table does not send 0.0.0.0/0 to the gateway, the instance is still isolated. Another mistake is assigning a public IP but leaving the security group closed to inbound traffic. That looks like a routing issue from the outside, but it is really a filtering issue.

Internet Gateways in AWS

An internet gateway is the VPC component that enables communication between resources in the VPC and the public internet. It is a managed, horizontally scaled AWS service. You do not size it, patch it, or deploy it across Availability Zones. AWS handles the infrastructure side.

When configured correctly, outbound traffic from a public subnet follows the route table to the internet gateway and then out to the internet. Inbound traffic from the internet follows the reverse path, but only if the destination resource has a public IP or Elastic IP and the security controls permit it.

There is one hard requirement: the internet gateway must be attached to the VPC before any route table can use it. You can create the gateway first, but it is not functional for your VPC until attachment is complete. That attachment is what makes the gateway part of the VPC’s routing fabric.

Typical troubleshooting scenarios include:

• The route table is missing a 0.0.0.0/0 entry to the internet gateway.
• The subnet is associated with the wrong route table.
• The instance does not have a public IP or Elastic IP.
• The security group blocks inbound or outbound traffic.
• The network ACL denies the traffic at the subnet boundary.

If you are validating internet access from an EC2 instance, start with the route table, then confirm the public IP assignment, then check security groups and NACLs. That order mirrors the packet’s path and saves time. AWS documentation on internet gateways makes the attachment and route relationship explicit, and that is the anchor point for your troubleshooting flow.

NAT Gateways and Private Subnet Egress

A NAT gateway allows instances in private subnets to initiate outbound internet connections without being directly reachable from the internet. That is the standard pattern for patching systems, downloading packages, calling external APIs, and reaching software repositories from workloads that should not accept inbound internet traffic.

Private subnet route tables usually send 0.0.0.0/0 to a NAT gateway instead of an internet gateway. The NAT gateway sits in a public subnet, uses a public IP, and translates private source addresses into a public source for outbound traffic. Return traffic comes back through the NAT gateway, but unsolicited inbound traffic from the internet does not get forwarded to the private instance.

Compared with a NAT instance, the managed NAT gateway is operationally simpler. You do not manage operating system updates, scaling, or failover logic in the same way you would with an EC2-based NAT instance. That simplicity is why NAT gateways are the default choice in many production AWS designs.

Common use cases include:

• Operating system updates for private Linux or Windows instances.
• Package downloads from public repositories.
• Outbound API calls to SaaS platforms.
• Container image pulls from external registries.
• Automation jobs that need temporary internet access.

Design matters here. NAT gateways should be placed in public subnets, and resilient designs usually deploy one NAT gateway per Availability Zone. That avoids a single point of failure and reduces cross-AZ traffic charges. If private subnets in one AZ send egress through a NAT gateway in another AZ, you may create an unnecessary dependency and extra cost.

One subtle point: a NAT gateway is for outbound initiated connections only. It is not a general-purpose internet router. If a service must be reachable from the internet, use an internet gateway and a public subnet design instead.

Other Gateway and Routing Options

Not every network path in AWS uses an internet gateway or NAT gateway. A virtual private gateway connects a VPC to on-premises networks through Site-to-Site VPN or AWS Direct Connect. This is the standard choice when you need hybrid connectivity and want traffic to flow between AWS and your data center or corporate network.

A Transit Gateway acts as a hub for connecting multiple VPCs and external networks at scale. Instead of building many point-to-point connections, you attach VPCs, VPNs, or Direct Connect gateways to the transit gateway and manage routing centrally. This becomes valuable when network sprawl starts to make peering hard to maintain.

VPC peering is a simpler one-to-one connection between two VPCs. It can work well for small numbers of VPCs, but route tables must be updated on both sides, and peering does not support transitive routing. If VPC A peers with VPC B and VPC B peers with VPC C, A cannot automatically reach C through B.

Gateway endpoints and interface endpoints provide private access to AWS services without traversing the public internet. Gateway endpoints are commonly used for Amazon S3 and DynamoDB. Interface endpoints use AWS PrivateLink and support many other services. These are useful when you want to keep traffic inside the AWS network and reduce exposure.

Option	Best Fit
Internet Gateway	Public internet access for public subnets
NAT Gateway	Outbound internet access for private subnets
Virtual Private Gateway	Hybrid VPN or Direct Connect connectivity
Transit Gateway	Large-scale multi-VPC and hybrid routing
VPC Peering	Simple point-to-point VPC connectivity
Gateway/Interface Endpoints	Private access to AWS services

Choose based on scale, security, cost, and operational overhead. For a small environment, peering may be enough. For a growing enterprise, transit gateway often becomes the cleaner long-term model. For private access to S3, a gateway endpoint is usually more efficient than sending traffic out through NAT.

Designing Route Tables for Real-World Architectures

A common three-tier AWS design uses public, application, and database subnets. Public subnets hold internet-facing components such as load balancers and NAT gateways. Application subnets hold app servers or containers. Database subnets hold RDS instances or other data stores with the tightest access controls.

In that layout, public subnets typically share a route table with a default route to the internet gateway. Application subnets often share a private route table with a default route to a NAT gateway. Database subnets may use a more restrictive route table with only local VPC routes and perhaps routes to on-premises systems if absolutely required.

Which subnets should share route tables? Subnets with the same traffic pattern usually can. Which should get dedicated route tables? Subnets with special requirements, such as database tiers, inspection subnets, or environments with different hybrid routes, should usually be separated. That reduces blast radius and makes intent easier to understand.

For multi-AZ deployments, duplicate the subnet pattern across Availability Zones. That means public, application, and database subnets in each AZ, with route tables designed for resilience. If you deploy a NAT gateway in each AZ, private subnets in that AZ should route to the local NAT gateway. If you use a transit gateway, ensure route propagation and attachments are planned deliberately.

Segmentation improves least privilege and troubleshooting. When each tier has a clear route path, you can prove where traffic should go before you look at security groups or application logs. That shortens incident response and reduces accidental exposure.

Troubleshooting Route Tables and Gateways

When traffic is not flowing, verify the path in order. Start with the subnet association. Confirm the subnet is attached to the route table you expect. Then inspect the route entries. Then confirm the gateway attachment. This sequence matches how AWS evaluates network forwarding.

The AWS console is useful for quick visual checks. The CLI is better when you need precision. For example, commands such as describe-route-tables, describe-subnets, and describe-internet-gateways help you verify associations and targets quickly. For complex paths, VPC Reachability Analyzer can trace the route between a source and destination and identify where the path breaks.

Common issues include:

• Overlapping CIDR blocks that create ambiguous routing.
• Missing default routes in public or private subnets.
• Incorrect target types, such as pointing to the wrong gateway.
• Subnet associations that reference the wrong route table.
• Security groups or NACLs that block traffic after routing succeeds.
• DNS settings that make a service appear unreachable even when routing works.

A useful troubleshooting approach for outbound connectivity is: confirm IP addressing, confirm route table association, confirm default route, confirm NAT or internet gateway attachment, then test security group and NACL rules. For inbound connectivity, start with public IP assignment, then route table, then internet gateway, then security controls. If the app uses DNS names, verify that the name resolves to the expected IP before assuming routing is broken.

One real-world pattern: an application server can reach the internet by IP but not by hostname. That is rarely a route table problem. It is usually DNS resolution, resolver settings, or security policy tied to name-based access. Another pattern: a private instance cannot download updates, but the NAT gateway is healthy. The route table may still be pointing to the wrong NAT gateway or the wrong AZ.

Best Practices for AWS Network Routing

Keep route tables simple, intentional, and documented. A route table should tell a clear story about where traffic goes. If someone has to inspect five different entries to understand basic behavior, the design is too complicated.

Use separate route tables for public and private subnets. Name them clearly. A route table labeled rtb-public-az1 is easier to operate than one with a generic or inherited name. Good naming reduces mistakes during incident response and makes audits faster.

High availability should be built into egress design. Avoid a single NAT gateway for all private subnets if your architecture depends on continuous outbound access. If the NAT gateway fails or the AZ becomes unavailable, private workloads may lose connectivity. The same logic applies to hybrid connectivity and transit designs.

Audit route tables, gateway attachments, and subnet associations regularly. Drift happens when teams create temporary fixes, copy old templates, or move workloads without updating the network layer. Periodic reviews catch stale routes before they become outages.

Infrastructure as code is the best way to keep routing repeatable. CloudFormation, Terraform, and CDK let you define route tables, gateway attachments, subnet associations, and endpoint policies in a version-controlled way. That gives you change history, peer review, and consistent deployments across environments.

• Document the purpose of each route table.
• Separate public, private, and special-purpose routing.
• Deploy NAT gateways with AZ awareness.
• Review routes after every network change.
• Use infrastructure as code for repeatability.

Conclusion

Route tables control traffic direction. Gateways provide the paths that traffic can use to leave or enter a VPC. That is the core model to keep in mind when you design AWS networks or troubleshoot connectivity. Once you understand that public subnets need a route to an internet gateway, and private subnets usually need a route to a NAT gateway or other controlled target, the rest of the architecture becomes much easier to reason about.

The practical difference between public and private subnets is not just a label. It is a combination of route table behavior, IP addressing, and gateway choice. A subnet is public only when its route table sends internet-bound traffic to an internet gateway and the resources inside it are configured for public reachability. A private subnet stays private when its default route points elsewhere, such as to a NAT gateway or internal network path.

Apply these concepts to your own VPCs. Review your route tables. Check subnet associations. Confirm gateway attachments. Look for unnecessary complexity, missing default routes, and designs that depend on a single point of failure. If you want a structured way to strengthen your AWS networking skills, ITU Online IT Training can help you build that foundation with practical, job-ready learning.

Make the next step concrete: open your current VPC configuration and inspect every route table and gateway relationship. If the purpose of a route is not obvious, fix the design or document it now. That small review can prevent a major outage later.