VPC for Beginners: Subnets, Route Tables, and How Traffic Actually Flows

A VPC is where your cloud networking lives, and it is the topic beginners avoid until something will not connect and they are forced to learn it under pressure. That is the worst time to learn it. Let me walk through the VPC the calm way: what each piece is, and how a packet actually travels from the internet to your server and back, because once you can trace that path, VPC troubleshooting stops being guesswork.

What a VPC is

A VPC (Virtual Private Cloud) is your own private, isolated network inside AWS. You get an IP address range (a CIDR block like 10.0.0.0/16), and everything you run lives at some address inside it. Nothing outside can reach in, and nothing inside can reach out, unless you explicitly set up a path. That "explicitly set up a path" is the whole job.

The pieces, and what each one does

Subnets: slices of your VPC. You divide your VPC's IP range into subnets, each in one Availability Zone. The key distinction:

• Public subnet: can reach the internet (has a route to an internet gateway). Put things here that need to be reachable from outside, like a load balancer.
• Private subnet: no direct internet route. Put things here that should not be exposed, like databases and app servers.

There is nothing magic about "public" and "private," a subnet is public only because its route table sends internet-bound traffic to an internet gateway. Change the routing and its nature changes.

Route tables: the signposts. A route table is a list of rules that says "traffic for this destination goes this way." Each subnet is associated with a route table. This is where public/private is actually decided:

• A route 0.0.0.0/0 -> internet gateway makes a subnet public (all internet traffic goes to the internet gateway).
• No such route (or 0.0.0.0/0 -> NAT gateway) keeps it private.

Internet gateway: the door to the internet. One per VPC. It is the thing that lets public subnets talk to the internet, both directions. No internet gateway, no internet.

NAT gateway: one-way door for private subnets. A private subnet has no internet route, but sometimes a private server needs to reach out (to download updates, call an API) without being reachable in. A NAT gateway, placed in a public subnet, lets private instances initiate outbound connections while staying unreachable from outside. (It also costs money per hour and per GB, worth knowing.)

Security groups and NACLs: the guards.

• Security group: a firewall attached to a resource (like an instance). Stateful, if you allow traffic in, the response is automatically allowed out. This is your main, everyday control.
• NACL (Network ACL): a firewall at the subnet level. Stateless, you must allow both directions explicitly. Most people leave NACLs open and rely on security groups.

How traffic actually flows (trace one packet)

Here is a request from a user on the internet to your app, which is the mental model that makes everything click.

1. A user hits your load balancer, which lives in a public subnet.
2. The packet arrives at the VPC through the internet gateway (because the public subnet's route table sends internet traffic there).
3. The load balancer's security group checks: is inbound traffic on port 443 allowed? If yes, in it goes.
4. The load balancer forwards to your app server in a private subnet. This is internal VPC traffic, no internet gateway needed.
5. The app server's security group checks: is traffic from the load balancer allowed? If yes, the app handles it.
6. The response travels back the same path. Because security groups are stateful, the return traffic is automatically allowed.

Now the reverse case that trips people up: the app server needs to call an external API.

1. Its packet is bound for the internet, but it is in a private subnet with no internet gateway route.
2. The route table sends 0.0.0.0/0 to a NAT gateway in the public subnet.
3. The NAT gateway forwards it out through the internet gateway, and the response comes back to the app, but nobody outside could have initiated a connection to the app.

Why "it will not connect" is usually easy to diagnose

Almost every VPC connectivity problem is one of these, checked in order:

1. Route table: does the subnet have a route to where the traffic needs to go (internet gateway for public, NAT for private outbound)?
2. Security group: does it allow the port and source?
3. NACL: is the subnet-level ACL blocking it (rare, but check)?
4. Public IP: does the resource even have a public IP if it needs to be reached directly?

Trace the packet's intended path and check each hop. The problem is almost always a missing route or a closed security group.

The take

A VPC is your private network, and everything in it comes down to slicing it into public and private subnets, using route tables to decide where traffic goes, and using security groups to decide what is allowed. Public means "has a route to the internet gateway," private means "does not." Learn to trace one packet from the internet to your server and back, and VPC stops being the scary part of AWS and becomes the part you reason about calmly.

What VPC concept finally made networking click for you? For me it was realizing "public subnet" is not a setting, it is just a route table with a path to the internet gateway.