Amazon VPC Explained: Subnets, Route Tables, NAT Gateways, and Network Security

Amazon VPC is the network boundary you design inside an AWS Region. If you get the subnets, route tables, NAT gateways, and network security controls wrong, your application may still run, but it will be exposed, unreliable, or painful to troubleshoot.

The clean pattern is simple: public entry points in public subnets, application and data tiers in private subnets, explicit route tables, controlled egress through NAT, and layered security with security groups and network ACLs. Simple does not mean casual. A single 0.0.0.0/0 route in the wrong table can turn a private workload into a public one.

What Is Amazon VPC?

An Amazon Virtual Private Cloud is a logically isolated, software-defined network in AWS. You choose the IP address ranges, create subnets, attach gateways, and define how traffic moves. AWS describes VPC as the place where you launch resources into a virtual network that you control.

Think of it as your cloud data center network, but without racks, switches, and cable labels. You still make the same design decisions:

• Which IP ranges should the environment use?
• Which workloads need internet access?
• Which systems should never receive inbound public traffic?
• Where should inspection, logging, and segmentation happen?

A common production VPC uses multiple Availability Zones, public subnets for load balancers, private subnets for applications, and isolated private subnets for databases. That pattern maps well to compliance reviews because the trust boundaries are visible.

Subnets: Your First Security Boundary

Subnets divide the VPC CIDR block into smaller IP ranges. Each subnet belongs to one Availability Zone. That detail matters. If you want high availability across two Availability Zones, you need separate subnets in each zone.

Public Subnets

A public subnet has a route to an internet gateway. Resources in that subnet can communicate directly with the internet if they have a public IPv4 address or equivalent public connectivity. Typical public subnet resources include:

• Application Load Balancers
• Bastion hosts, if your organization still permits them
• NAT gateways in traditional designs
• Public-facing web servers, though load balancers are usually preferred

Do not put databases in public subnets. To be blunt, that mistake still appears in real audits. A security group can block inbound traffic, but the subnet design is already telling the wrong story.

Private Subnets

A private subnet has no direct route to an internet gateway. Instances inside it can still reach the internet through a NAT gateway, but unsolicited inbound internet traffic cannot initiate a connection to them.

Use private subnets for:

• Application servers
• Databases
• Internal APIs
• Batch workers
• Container nodes that should not be publicly reachable

A small operational detail trips up beginners: in Terraform, aws_subnet keeps map_public_ip_on_launch at false unless you set it. In the AWS console, subnet auto-assign public IPv4 settings are easy to miss. When an EC2 instance in a supposedly public subnet cannot reach the internet, check that setting before blaming the route table.

Route Tables: The Traffic Rules That Matter

Every subnet must be associated with one route table. A subnet can use only one route table at a time, but one route table can serve many subnets. AWS creates a main route table with the VPC. Best practice is to leave the main route table as local-only and explicitly associate custom route tables with each subnet.

Why? Because accidental inheritance is dangerous. If someone later adds an internet route to the main table, any subnet without an explicit association may become more exposed than intended.

Local Route

Every VPC route table includes a local route for traffic inside the VPC CIDR. For example, if your VPC is 10.0.0.0/16, the route table includes a local route for that range. You cannot remove it.

Public Route Table

A public route table normally includes:

• 10.0.0.0/16 to local
• 0.0.0.0/0 to an internet gateway

Associate this route table only with public subnets. A load balancer subnet belongs here. A database subnet does not.

Private Route Table

A private route table often includes:

• 10.0.0.0/16 to local
• 0.0.0.0/0 to a NAT gateway

This lets private resources download patches, pull container images, or call external APIs without accepting inbound internet connections.

When debugging, remember that routing is not the only requirement. I have seen teams lose an hour because the route table was correct, but the security group egress rule allowed only TCP 443 while the package manager was trying to reach a repository over TCP 80 during redirect handling. Check routes, security groups, NACLs, and DNS. In that order.

NAT Gateways: Outbound Access Without Public Exposure

A NAT gateway performs network address translation so private resources can initiate outbound connections. In the traditional architecture, you place a NAT gateway in a public subnet and point private subnet default routes to it.

The flow looks like this:

1. An EC2 instance in a private subnet sends traffic to an external endpoint.
2. The private route table sends 0.0.0.0/0 traffic to the NAT gateway.
3. The NAT gateway uses the internet gateway to reach the destination.
4. Return traffic comes back through the NAT gateway to the private instance.

That last part is stateful. The outside service can respond to a request, but it cannot start a new connection into the private instance.

Regional NAT Gateway and Capacity Planning

AWS has introduced a Regional NAT Gateway availability mode that operates at the VPC level rather than requiring separate NAT gateways per Availability Zone. AWS networking guidance describes it as a way to reduce per-zone NAT management, reuse the same route table and Regional NAT Gateway ID when expanding, and integrate with VPC IPAM for governed address allocation.

The capacity number worth remembering is 55,000 concurrent connections per IP address to a unique destination, where destination means destination IP, destination port, and protocol. If many workers connect to the same external API endpoint, that limit can matter. Regional NAT Gateway can associate additional IP addresses automatically when more ports are needed, which lowers port exhaustion risk.

Still, NAT is not free magic. Heavy egress through NAT gateways can become expensive, and it can hide source identity if you do not log carefully. Use VPC endpoints for AWS services such as S3, DynamoDB, ECR, and CloudWatch where practical. It cuts NAT traffic and keeps service access on AWS private paths.

Private NAT Gateways

Private NAT gateways solve a different problem. They are useful when traffic must appear from a specific private IP range, often for hybrid connectivity. For example, an on-premises firewall may allow only a narrow source range. You can associate that range with the VPC, deploy a private NAT gateway in a subnet from that range, and route on-premises-bound traffic through it.

This pattern also shows up in multi-VPC networks where one VPC uses non-routable or overlapping ranges and another requires traffic from a routable range through a transit gateway.

Network Security: Security Groups, NACLs, and Inspection

Security Groups

Security groups are stateful firewalls attached to resources such as EC2 instances, ENIs, and load balancers. They control inbound and outbound traffic. Because they are stateful, return traffic for an allowed request is automatically allowed.

Use security groups for precise rules:

• Allow HTTPS from the internet to the load balancer security group.
• Allow application traffic only from the load balancer security group to the app tier.
• Allow database traffic only from the app tier security group to the database.

Prefer security group references over hard-coded private IPs when possible. This survives scaling events and replacement instances.

Network ACLs

Network ACLs operate at the subnet level and are stateless. You must account for both inbound and outbound rules, including ephemeral ports for return traffic. They are useful for broad controls, such as blocking known hostile CIDR ranges or enforcing subnet-wide restrictions.

Do not try to express every application rule in NACLs. You will create brittle networking. Use security groups for workload-level control and NACLs for coarse subnet guardrails.

Gateway Route Tables and Security Appliances

AWS also supports gateway route tables associated with an internet gateway or virtual private gateway. These can steer inbound traffic through a middlebox appliance, such as an IDS, IPS, or firewall, before it reaches application subnets.

This is valuable for regulated environments, but it adds routing complexity. Watch for asymmetric routing. If inbound traffic goes through an appliance but outbound traffic returns directly through another path, inspection can fail and sessions may drop.

A Practical Amazon VPC Design Pattern

For a standard web application, start with this layout:

• Two or three Availability Zones for resilience.
• Public subnets for Application Load Balancers and, if needed, NAT gateways.
• Private application subnets for EC2, ECS, EKS worker nodes, or internal services.
• Private database subnets with no default internet route.
• Public route table with 0.0.0.0/0 to an internet gateway.
• Private route table with default egress through NAT or VPC endpoints.
• Security groups that allow only tier-to-tier traffic.
• NACLs for subnet-level deny rules where required.

If you are learning AWS networking for production work, pair this topic with Global Tech Council's cloud computing, cybersecurity, and DevOps learning paths as internal study routes. VPC design sits at the intersection of cloud architecture and security engineering.

Common Mistakes to Avoid

• Using the main route table for everything. Create explicit route tables per subnet role.
• Putting private workloads in public subnets. A restrictive security group does not fix poor segmentation.
• Forgetting multi-AZ design. One subnet in one Availability Zone is a lab, not a resilient production design.
• Routing all AWS service traffic through NAT. Use VPC endpoints where they fit.
• Ignoring NACL stateless behavior. Missing ephemeral port rules can break return traffic.
• Skipping flow logs. VPC Flow Logs are often the fastest way to prove whether traffic is reaching an ENI and being accepted or rejected.

Next Step

Build a small Amazon VPC by hand before automating it. Create two public subnets, two private subnets, separate route tables, an internet gateway, NAT egress, and security groups for a load balancer and app server. Then turn on VPC Flow Logs and break one route on purpose. You will learn more from that failure than from another diagram.

After that, move the same design into infrastructure as code and connect it to your broader AWS certification plan through Global Tech Council's cloud and cybersecurity training resources.