Understanding AWS Networking: A Guide to Route Tables and Gateways

AWS VPC routing is the set of route table rules and gateway targets that decides where traffic goes inside a Virtual Private Cloud (VPC). If a subnet cannot reach the internet, a private API, or another VPC, the cause is usually in the route table, gateway attachment, or subnet design. Understanding this flow is the difference between a secure architecture and a broken one.

Primary concept	AWS VPC routing
Core components	VPCs, subnets, route tables, Internet Gateways, NAT Gateways, endpoints
Public subnet rule	Route to the internet via an Internet Gateway as of July 2026
Private subnet rule	Route outbound traffic through a NAT Gateway as of July 2026
Key risk	Confusing routing with security controls as of July 2026
Typical use cases	EC2, load balancers, databases, bastion hosts, hybrid connectivity

AWS Networking Basics: How VPCs, Subnets, and CIDR Blocks Fit Together

A Virtual Private Cloud (VPC) is the isolated network boundary for AWS resources. It is the starting point for every routing decision because nothing inside the VPC can talk to anything outside it unless you explicitly define a path.

A subnet is a smaller network range carved out of the VPC. Subnets are usually placed in specific Availability Zones to improve resilience and keep workloads close to the resources they depend on.

Why CIDR Planning Matters

CIDR is the addressing scheme that defines the IP range for your VPC and subnets. Good planning prevents overlap, avoids exhaustion, and keeps room for future growth. Bad planning creates a mess later when you need new subnets for databases, container clusters, or a migration project.

For example, a VPC built with a /24 range can disappear quickly once you split it into public and private subnets across multiple Availability Zones. A larger block, such as /16, gives more breathing room for expansion, hybrid routing, and environment separation.

Public Versus Private Is About Routing

A subnet is not public because someone named it “public.” It is public only when its route table sends internet-bound traffic to an Internet Gateway and resources inside it have public addressing where needed.

• Public subnet: has a route to the Internet Gateway for 0.0.0.0/0.
• Private subnet: does not send traffic directly to the internet; outbound traffic usually goes through a NAT Gateway.
• Local subnet traffic: stays inside the VPC by default through the local route.

This distinction matters for workloads like EC2 instances, Application Load Balancers, RDS databases, and bastion hosts. Web servers can live in public subnets, while databases almost always belong in private subnets.

Subnet placement is not an administrative detail. It is one of the main controls that decides whether a workload is reachable from the internet, reachable only from internal networks, or reachable only through controlled outbound paths.

For deeper network and security planning, the AWS documentation on Amazon VPC and the NIST guidance in NIST SP 800-204 are useful references for segmentation and service design.

How Does AWS VPC Routing Work?

AWS VPC routing works by matching the destination IP address of a packet to a route table entry and then sending the traffic to the configured target. The route table does not inspect application data, and it does not block traffic on its own.

1. A packet leaves a subnet. An EC2 instance, container task, or appliance generates traffic for an IP destination.
2. AWS checks the subnet’s route table. The table is evaluated for the most specific match to the destination CIDR.
3. The target is selected. That target may be an Internet Gateway, NAT Gateway, Transit Gateway, VPC peering connection, VPN, Direct Connect gateway, or the local route.
4. Security controls are applied separately. Security groups and network ACLs may still block the flow even if the route exists.
5. The packet follows the next hop. The selected target forwards traffic if the rest of the design allows it.

Route Tables Are Decision Makers, Not Firewalls

A route table is the decision-making layer of AWS networking. It says where traffic should go, not whether it should be allowed. That job belongs to Security groups and network ACLs.

That separation is why troubleshooting has to start with routing. If the subnet does not have the right route, it does not matter how open the security group is. Traffic still cannot reach the target.

The official AWS VPC route table documentation explains route priorities and targets in more detail at AWS Route Tables. For workload design, the Cisco and AWS routing model is similar in one important way: match the destination first, then forward to the next hop.

What Is an Internet Gateway in AWS?

An Internet Gateway is the AWS-managed target that lets resources in a VPC communicate with the public internet. Without it, a subnet cannot be public, no matter how many public IPs you assign.

To make a subnet internet-facing, you need two things: the route table must send 0.0.0.0/0 to the Internet Gateway, and the instance or load balancer must be reachable with appropriate public addressing and security rules. In practice, this is how public web servers, bastion hosts, and public Application Load Balancers are exposed.

What Makes a Subnet Public

People often assume a subnet is public because the VPC has an Internet Gateway attached. That is not enough. The subnet becomes public only when its route table points default internet traffic to that gateway.

• Internet Gateway attached to VPC: necessary, but not sufficient.
• Default route to the gateway: required for outbound and return internet paths.
• Public IP or Elastic IP: usually required for inbound reachability to EC2 instances.

An Elastic IP can make sense for a stable bastion host or a legacy service that needs a fixed address. For modern architectures, an Application Load Balancer is often a better public entry point because it gives you scaling, health checks, and cleaner separation from instances.

See the official AWS guidance at AWS Internet Gateways. If you are building public-facing systems, review the OWASP guidance on exposure reduction at OWASP Top 10 as part of your security review.

What Is a NAT Gateway and Why Do Private Subnets Use It?

A NAT Gateway is a managed AWS service that allows instances in a private subnet to initiate outbound internet traffic without allowing unsolicited inbound connections from the internet. That is the standard pattern when servers need package updates, external API access, or software downloads but should not be directly exposed.

In a typical setup, the NAT Gateway sits in a public subnet. That public subnet has a route to the Internet Gateway, while the private subnet sends 0.0.0.0/0 to the NAT Gateway. The private instance reaches the internet through the NAT, but no external system can start a session back to that private instance.

How the Traffic Flow Works

Think of it as a controlled outbound exit. The instance in the private subnet sends a request, the NAT Gateway translates the source, and the response comes back through the same established path.

• Private subnet instance starts an outbound connection.
• NAT Gateway rewrites the source address for outbound traffic.
• Internet Gateway carries the traffic to public destinations.
• Return traffic comes back through the NAT because the session already exists.

Real-world uses include Linux patching, pulling container images, contacting payment APIs, and reaching public package repositories. This is also where cost control matters. NAT Gateways are convenient, but they are not free, and large outbound data transfer patterns can become expensive quickly.

For the latest service behavior and pricing context, use the AWS official pages: AWS NAT Gateway and AWS VPC Pricing. If you are building secure private connectivity patterns, the CompTIA Pentest+ course material aligns well with the mindset of identifying exposed paths and reducing attack surface.

How Do Local Routes, VPC Peering, and Internal Traffic Flow Work?

Local routing is the default route that allows traffic to move between subnets inside the same VPC. AWS creates this route automatically, and it is why two instances in different subnets can still communicate without sending traffic through the internet.

That internal path is important for application tiers, shared services, and management networks. A frontend instance in one subnet can talk to a database in another subnet as long as the route, security group, and network ACL rules allow it.

VPC Peering Extends That Pattern

VPC peering is a private routing relationship between two VPCs. It is not internet traffic. It is not NAT. It is a direct private link between routing domains, and both sides must add route table entries for the peer CIDR ranges.

• Shared services: central logging, authentication, or inspection VPCs.
• Application separation: dev, test, and prod in different VPCs.
• Cross-account communication: business units that need private connectivity without exposing services publicly.

Routing through peering is usually simple but easy to miss during setup. If VPC A can see VPC B but B cannot reply, the missing route entry is often the problem. The traffic path must be defined in both directions where needed.

Review the official AWS peering documentation at AWS VPC Peering. For a broader governance view, NIST and AWS both emphasize segmentation as a core control in shared environments.

How Does Hybrid Connectivity Extend AWS Networking to On-Premises Networks?

Hybrid connectivity connects AWS to on-premises networks through VPN or AWS Direct Connect. Route tables then send selected CIDR ranges toward that connection instead of sending the traffic to the internet.

This is the right choice when a company is migrating gradually, needs private connectivity to a data center, or must keep certain traffic off the public internet for policy or compliance reasons. It is also useful for branch offices and centralized shared services that still live outside AWS.

VPN Versus Direct Connect

A VPN is usually faster to deploy and rides over the public internet with encryption. AWS Direct Connect is a dedicated private network connection that can provide more consistent performance and more predictable routing for enterprise workloads.

VPN	Best for quick setup, temporary migration paths, or lower-cost hybrid access
Direct Connect	Best for steady throughput, private transport, and enterprise network integration

In both cases, route tables decide which on-premises destinations go to the hybrid link. That is why hybrid routing is a routing design problem first and a connectivity service second. AWS documents the options at AWS Site-to-Site VPN and AWS Direct Connect.

The Hybrid Routing glossary term fits this model well: some destinations stay in AWS, some go on-premises, and the route table decides which path each packet follows.

What Are AWS Endpoints and Why Use Them Instead of the Internet?

AWS endpoints provide private access to AWS services without requiring Internet Gateway or NAT Gateway traversal. That reduces exposure, limits outbound dependency, and often cuts cost.

There are two common forms. A gateway endpoint is used for services like Amazon S3 and Amazon DynamoDB. An interface endpoint uses Elastic Network Interfaces in your subnets and works with many other AWS services.

Why Endpoints Change Route Design

When you use endpoints, the route table may direct service-bound traffic to the endpoint instead of the internet. That means instances can reach AWS-managed services privately, even if they live in private subnets with no general internet route.

• Security benefit: traffic stays on the AWS network path.
• Cost benefit: less dependence on NAT data processing.
• Operational benefit: fewer moving parts for service access.

Common examples include private S3 access for application logs, interface endpoints for AWS Systems Manager, and private API access for services used during automation. That is often the cleaner choice for workloads that do not need broad outbound internet access.

See AWS VPC Endpoints and the AWS service-specific documentation for implementation details. In security reviews, endpoint adoption is one of the simplest ways to reduce unnecessary exposure while preserving functionality.

What Do Real AWS Networking Designs Look Like?

Real environments usually follow a few repeatable patterns. The difference between a good design and a fragile one is how cleanly routing supports the workload without exposing more than necessary.

Two-Tier Pattern

A two-tier architecture usually puts the web layer in a public subnet and the application or data layer in a private subnet. The web tier receives internet traffic through an Internet Gateway. The private tier uses internal routing or NAT only when it needs outbound access.

• Public subnet: web servers, public load balancers, bastion hosts.
• Private subnet: application servers, databases, internal services.
• Routing design: internet access only where it is truly needed.

Three-Tier Pattern

A three-tier architecture adds a separate application layer between the web and database layers. That extra layer lets you enforce tighter controls, use internal load balancing, and keep database traffic isolated from the internet.

For example, an ALB can sit in the public tier, application instances can sit in private subnets across two Availability Zones, and the database can sit in its own private subnets with no direct internet route at all. This pattern is common because it scales, it is easier to secure, and it is easier to troubleshoot.

Design Choices That Improve Resilience

In multi-AZ design, you should repeat routing patterns across zones. If one Availability Zone fails, the route behavior in the surviving zone should already be correct. A subnet in one zone should not be the only place where the architecture “makes sense.”

For architecture reviews, this is where foundational AWS networking knowledge overlaps with security training. The same discipline you use in penetration testing and threat modeling applies to route design: reduce exposure, test assumptions, and validate the actual path.

For official AWS architecture guidance, review AWS Well-Architected Framework. The security pillar is especially relevant when deciding what belongs in public versus private subnets.

What Are the Most Common AWS Routing Mistakes?

The most common AWS routing mistake is assuming a subnet is public just because the VPC has an Internet Gateway. That is wrong more often than people expect, and it leads to “it should work” troubleshooting sessions that go nowhere.

Frequent Failures

• Missing default route to NAT: private instances lose outbound access to updates and APIs.
• Wrong route table association: the subnet is attached to a table that does not match the intended design.
• No public IP assignment: even a correctly routed public subnet cannot be reached inbound if the instance has no address that the internet can target.
• CIDR overlap: overlapping ranges break clean routing and make future peering or hybrid expansion painful.
• Confusing routing with security: an open security group cannot fix a missing route.

These errors are easy to prevent if you document the intended path before deployment. Ask three questions for every subnet: where can it send traffic, what can initiate traffic into it, and what service dependencies does it need?

Most AWS networking failures are not mysterious. They are usually the result of a route table, target, or subnet association that does not match the architecture diagram.

If you want to align troubleshooting with broader security operations, the AWS docs on VPC security and the MITRE ATT&CK framework at MITRE ATT&CK are useful references for thinking about paths, exposure, and lateral movement.

How Do You Troubleshoot AWS Connectivity Issues Step by Step?

The fastest way to troubleshoot AWS connectivity is to start with the source subnet, the destination, and the expected path. If you do not know which path the traffic should take, you will end up guessing.

1. Identify the source subnet. Confirm which subnet the instance, task, or appliance is using.
2. Check the subnet’s route table association. Make sure the subnet is attached to the correct table.
3. Verify the route entry. Look for the correct destination and target, such as 0.0.0.0/0 to an Internet Gateway or NAT Gateway.
4. Confirm the gateway attachment. Verify that the Internet Gateway, NAT Gateway, or peering target is actually in place.
5. Test security rules only after routing looks correct. Review security groups and network ACLs once the path exists.
6. Use instance-level tests. Run curl, ping, traceroute, or application-specific health checks where appropriate.

For example, if an instance in a private subnet cannot download updates, the likely causes are a missing NAT route, a broken NAT Gateway setup, or an endpoint-based path that was never configured. If a bastion host cannot be reached, look at the public subnet route table, public IP assignment, and security group first.

Amazon’s own troubleshooting and VPC behavior documentation is the best place to confirm route evaluation details: AWS VPC Troubleshooting. If you are building hands-on security skills, this is the same kind of path analysis used in real assessment work, which is why it pairs naturally with the CompTIA Pentest+ mindset.

How Should You Design for Security, Reliability, and Cost?

Good AWS networking design reduces attack surface without making operations miserable. The goal is not to make everything private at all costs. The goal is to expose only the paths you actually need.

Security improves when public exposure is limited to load balancers, bastion hosts, or specific entry points. Private subnets, NAT Gateways, and AWS endpoints keep most workloads away from direct inbound access.

Reliability and Cost Tradeoffs

Reliability means planning for failure points. A single NAT Gateway can become a bottleneck or a single point of failure if you build the rest of the design around it. In multi-AZ architectures, it is common to place one NAT Gateway per AZ and route each private subnet to the local zone’s gateway.

• NAT Gateway: simplest outbound design, but can create cost and resilience concerns.
• AWS endpoints: often cheaper and more secure for AWS service access.
• Internet Gateway: appropriate only when public exposure is intentional.

Cost control starts with traffic analysis. If most outbound traffic is going to S3, Systems Manager, or a handful of AWS services, endpoints may be a better choice than pushing everything through NAT. If you have heavy internet-bound traffic, you should know the data processing cost before it becomes a surprise on the bill.

For governance and risk framing, the CISA Secure by Design guidance is a strong match for this topic. It reinforces the same principle AWS architects use: reduce unnecessary exposure and make secure paths the default.

For workforce context, the U.S. Bureau of Labor Statistics continues to show strong demand across networking and security roles, which is why practical AWS networking skills matter for architects, operations teams, and defenders alike.

When Should You Use AWS VPC Routing, and When Should You Avoid Overcomplicating It?

You should use AWS VPC routing any time traffic needs to cross a boundary: public internet access, private egress, peering, or hybrid connectivity. You should avoid overcomplicating it when a simpler native path is enough.

Use it when the workload needs controlled access, segmented tiers, private service integration, or private links to other networks. Avoid overengineering it when the system only needs a standard public web entry point and one private backend path.

Good Fit Versus Poor Fit

• Good fit: multi-tier applications, compliance-sensitive systems, shared services, migrations, and segmented environments.
• Poor fit: designs that add peering, NAT, and extra subnets without a clear business or security reason.

Simple designs are easier to secure, easier to monitor, and easier to recover during outages. Complex routing is not a sign of maturity unless it solves a real need.

That is why route tables should be documented like production code. Every route should have a purpose, a business owner, and a reason it exists.

Conclusion

AWS VPC routing is the core logic behind network behavior inside a VPC. Route tables decide where traffic goes, gateways provide the next hop, and subnet design determines what is public, private, internal, or hybrid.

The practical takeaway is simple. Public access requires an Internet Gateway path. Private outbound access usually requires a NAT Gateway or an AWS endpoint. Internal-only communication stays inside the VPC through the local route or extends privately through peering, VPN, or Direct Connect.

If you are building AWS skills for real production work, apply these concepts in labs, architecture reviews, and troubleshooting drills. That is exactly the kind of hands-on network thinking that supports secure administration, cleaner incident response, and stronger cloud design. ITU Online IT Training uses these foundational skills throughout AWS and security-focused learning because they show up in real environments every day.

CompTIA®, AWS®, Cisco®, and Microsoft® are trademarks of their respective owners.