Amazon VPC: 6 Networking Concepts Every AWS Beginner Must Get Right

When I first launched an EC2 instance, I just clicked through the VPC wizard and accepted every default. It worked — right up until I tried to connect a database and nothing could talk to anything. VPC networking felt like alphabet soup: subnets, route tables, NACLs, security groups, gateways. Here are the six concepts that actually matter, in the order I wish I'd learned them.

1. Your CIDR block is a one-way decision

Every VPC gets a primary IPv4 CIDR range, typically 10.0.0.0/16, giving you 65,536 private addresses. Pick carefully: if you later peer this VPC with another one — say, connecting dev and staging — overlapping CIDR blocks will break peering. I've seen teams standardize on 10.0.0.0/16 for prod, 10.1.0.0/16 for staging, 10.2.0.0/16 for dev. Simple scheme, zero collisions.

2. Public vs private subnets is about the route table, not the name

A subnet is "public" only because its route table sends traffic to an internet gateway. That's it — naming a subnet "public" changes nothing. My rule of thumb: run ALBs and bastion hosts in public subnets; everything else (app servers, databases, internal APIs) in private subnets. The default VPC from the wizard puts everything public, which is convenient for a demo and dangerous for anything real.

3. Route tables are the traffic cops

Every subnet is associated with exactly one route table, and the routes decide where packets go: 10.0.0.0/16 → local (inside the VPC), 0.0.0.0/0 → internet gateway (the whole internet), or 0.0.0.0/0 → NAT gateway (outbound internet only). When two resources can't reach each other, the route table is the first place I look — nine times out of ten, the fix is a missing or wrong route.

4. Security groups and NACLs are different tools

This trips up everyone. Security groups attach to resources (really, to their network interfaces) and are stateful — allow inbound port 443 and the return traffic flows back automatically. Network ACLs attach to subnets and are stateless — you must explicitly allow both directions. I treat security groups as my real access control and NACLs as a coarse subnet-level guardrail. Lock down the security groups first; that's where mistakes actually bite.

5. NAT Gateway gives private subnets safe outbound access

Private subnets have no internet route, but your app servers still need to pull packages, call external APIs, and push logs. That's what a NAT Gateway does: it sits in a public subnet and lets private resources initiate outbound connections while staying unreachable from the outside. One watch-out: NAT Gateways charge per hour plus per GB processed, so monitor the data processing line item if you're moving a lot of traffic.

6. VPC endpoints cut the middleman (and the cost)

Instead of routing S3 or DynamoDB traffic through a NAT Gateway, VPC endpoints keep it on the AWS network. Gateway endpoints for S3 and DynamoDB are free — no reason not to use them. Interface endpoints (powered by PrivateLink) cover most other services and keep traffic off the public internet entirely. I add gateway endpoints to every new VPC by default; it's a five-minute change that lowers both cost and attack surface.

Key takeaways

- Plan your CIDR scheme before creating VPCs; collisions break peering later.
- Default to private subnets; only load balancers and bastions earn a public subnet.
- When connectivity breaks, check the route table first.
- Security groups for resources (stateful), NACLs for subnets (stateless) — don't mix up their jobs.
- NAT Gateways enable outbound-only internet for private resources; watch the data-processing cost.
- VPC endpoints route AWS-service traffic privately and cheaply.

Get these six right and 90% of VPC networking confusion disappears. The remaining 10% — transit gateways, VPC sharing, IPv6 — can wait until you actually need them.