03 — VPC: Drawing My Own Network in AWS

"The boring network bit you click through at setup" was how I filed the VPC, until a routing mistake cost me a night of debugging. The model that stuck: a VPC is a network I draw. I pick an IP range, carve it into subnets, wire up route tables to decide where packets go, and hang firewalls on the edges [1]. Once I saw it as a sketch rather than a wizard, the public/private subnet distinction, the NAT gateway, and the security group all snapped into place as just parts of the drawing.

The VPC: a logically isolated network

A VPC — Virtual Private Cloud — is a private network I define inside AWS, into which I launch resources [1]. "Isolated" is doing real work: by default, nothing in my VPC is reachable from the internet unless I explicitly open a path. The default VPC AWS hands new accounts is wide open, which is convenient for tutorials and terrible for production — so the first real architectural act is almost always building a custom VPC from scratch.

The drawing has one big boundary first: a CIDR block — the total IP range the VPC can use.

CIDR blocks: the address budget

CIDR — Classless Inter-Domain Routing — is just a compact way to write a range of IP addresses [2]. 10.0.0.0/16 means "everything from 10.0.0.0 to 10.0.255.255," which is 65,536 addresses. /28 is the smallest AWS allows (16 addresses); /16 is the largest for a VPC. The number after the slash is how many bits are fixed — bigger slash, fewer addresses.

Two rules I treat as law:

• Pick a non-overlapping range. The VPC's CIDR must not collide with my office network, a peered VPC, or an on-prem datacenter I might later connect. Overlap is a painful, late-discovered bug.
• The CIDR cannot be resized after creation. I can add secondary CIDRs later, but the primary is permanent. So I leave headroom: a /16 is usually a safe default even when I think I need a /24.

The shorthand that makes CIDR readable: /24 ≈ 256 addresses, /25 ≈ 128, /26 ≈ 64, /27 ≈ 32, /28 ≈ 16. Each bit halves the pool.

Subnets: carving up the budget

A subnet is a slice of the VPC's CIDR, and each one lives in exactly one Availability Zone [3]. The thing that finally made subnets click: public versus private is not a subnet property — it's a route-table property. A subnet becomes "public" because the route table attached to it points at the Internet Gateway; it becomes "private" because it does not.

• Public subnet — its route table sends 0.0.0.0/0 to the Internet Gateway, so instances in it can reach and be reached from the internet (subject to security groups) [5].
• Private subnet — no route to the Internet Gateway. Instances here have no direct internet path, which is exactly what I want for databases and internal services.

AWS reserves the first four and last IP of every subnet (network, VPC router, DNS, broadcast), so a /28 gives me only 11 usable addresses. Subnet sizing is less generous than the raw CIDR suggests.

Route tables: the routing logic

A route table is the set of rules that says "traffic destined for X goes to Y" [4]. Each subnet is associated with exactly one route table. The main rules I keep drawing:

• Local route — every route table has an automatic entry sending VPC-internal traffic (10.0.0.0/16, say) to local. This is why any two instances in the VPC can talk regardless of subnet.
• Internet Gateway route — 0.0.0.0/0 → igw-xxx. Adding this makes the subnet public.
• NAT Gateway route — 0.0.0.0/0 → nat-xxx. Used in private subnet tables so instances can reach out without being reachable.

The mental shortcut: the route table is the subnet's posture toward the internet.

Internet Gateway and NAT Gateway

These two confused me until I separated their jobs.

An Internet Gateway (IGW) is the VPC's bi-directional door to the public internet [7]. It does NAT for instances that have a public IP, and it's what lets inbound traffic reach a public-subnet instance. Without an IGW attached to the VPC, nothing in the VPC touches the internet, full stop.

A NAT Gateway is a managed, single-AZ appliance that gives private-subnet instances outbound-only internet access [8]. They can pull patches, reach external APIs, download packages — but nothing outside can initiate a connection to them. NAT is one-way by design.

The pattern I draw every time: public subnets on top, private below, NAT in the public subnet, traffic from private goes up through NAT and out the IGW. That's a two-tier architecture in one sketch.

Security groups: stateful per-instance firewalls

A security group is a virtual firewall attached to an instance's network interface [6]. The details that distinguish it from a traditional firewall:

• Stateful. If I allow outbound on port 443, the reply traffic is allowed back in automatically. I never write return rules.
• Allow rules only. I cannot write "deny this IP"; I can only whitelist. The default security group denies all inbound and allows all outbound.
• Per-instance. I attach up to five security groups to each instance, and they cumulatively allow.

The cross-subnet implication trips people up: if instance A in subnet 1 needs to talk to instance B in subnet 2, I must allow it on B's inbound security group (the route table's local route already handles the path). The security group is the gate; the route table is the road.

How I use this

VPC design is now a sketching exercise before any clicking. I draw the VPC boundary, drop in at least two AZs, put public-facing things (load balancers, bastions) in public subnets, everything else in private, and give each private subnet a route to a NAT Gateway in a public subnet of the same AZ (NAT is AZ-scoped — cross-AZ NAT works but pays for cross-AZ data transfer). Security groups are locked to least-privilege, and "0.0.0.0/0 on port 22" is treated as a smell. The drawing, not the console, is where the architecture lives.

References

[1] Amazon Web Services, "Amazon Virtual Private Cloud," 2024. [Online]. Available: https://aws.amazon.com/vpc/

[2] Amazon Web Services, "VPC CIDR blocks," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html

[3] Amazon Web Services, "Subnets for your VPC," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html

[4] Amazon Web Services, "Route tables for your VPC," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html

[5] Amazon Web Services, "Public subnet," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html

[6] Amazon Web Services, "Security groups for your VPC," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html

[7] Amazon Web Services, "Internet gateways for your VPC," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html

[8] Amazon Web Services, "NAT gateways," VPC User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html