VPCs were the first thing in SAA that made me actually stop and go back to the beginning. Not because they're impossible, they're not, but everything builds on top of everything else. If one layer doesn't click, the next one won't either.

So here are my actual notes. Not textbook stuff, just the things I kept having to re-read until they finally made sense.

// Start with the big picture

A VPC is just your own private network inside AWS. Nothing gets in or out unless you say so. You pick the IP range, you split it into subnets, you control all of it. Every AWS account gets a default VPC already set up in each region, and it works fine out of the box. But for anything real you build your own.

// Public vs private subnets

This tripped me up at first because I thought there was some special "make public" setting. There isn't. A subnet is public because it has a route to an Internet Gateway in its route table. That's the whole thing. If the route exists, traffic can get out to the internet and inbound connections are possible. If it doesn't, it's private.

Private subnets can still reach the internet if they need to, like to pull updates or call an external API. They do it through a NAT Gateway sitting in a public subnet. The NAT handles the outbound request on their behalf. Nothing can initiate a connection inbound to the private subnet though. That's the point.

// Route tables

Every subnet has a route table. It's just a list of rules: traffic going to X, send it to Y. The two you'll see constantly are the local route (traffic stays inside the VPC) and whatever you've added for internet access. One gotcha: a subnet with no explicit route table association falls back to the main route table. Worth knowing so you don't accidentally expose something.

// Security groups vs NACLs

Two layers, two different tools. Security groups attach to individual resources and are stateful. Allow port 443 inbound and the response traffic is automatically allowed back out, you don't write a separate rule for it. They only support allow rules.

NACLs sit at the subnet level. They're stateless, so you need explicit inbound and outbound rules for both directions. They support deny rules too, which security groups don't. Most of the time security groups are what you're thinking about. NACLs are useful when you want to block something across an entire subnet.

// Still working through

VPC peering, Transit Gateway, VPC endpoints and PrivateLink are next. The interconnection patterns between VPCs are where it gets more interesting. More notes coming as I go.