VPCs, Subnets & CIDR Planning

In one line

A VPC is your own private network inside an AWS region, defined by a CIDR range; subnets carve that range into per-AZ slices, and a subnet is 'public' or 'private' purely because of its route table — not because of any setting on the subnet itself.

0/4 · 0%

Think of it like this

A VPC is a gated housing society with its own internal street numbering (its CIDR block, like 10.0.0.0/16). Subnets are the individual lanes inside it, each built in one specific block of the society (one AZ). Whether a lane has a gate to the main road isn't about the lane — it's about whether a road was built connecting it (a route).

Key ideas

01
CIDR NOTATION: 10.0.0.0/16 means the first 16 bits are fixed, leaving 16 bits for addresses — 65,536 IPs. A /24 has 256; a /20 has 4,096. Each smaller number = bigger network. VPCs can be from /16 (largest) to /28 (smallest).
02
A SUBNET lives in exactly ONE Availability Zone and takes a slice of the VPC's range. AWS reserves 5 IPs in every subnet (network address, VPC router, DNS, future use, broadcast), so a /24 gives 251 usable addresses.
03
PUBLIC vs PRIVATE: a subnet is public if its route table sends 0.0.0.0/0 to an INTERNET GATEWAY (Topic 3.2); otherwise it's private. The standard layout is public subnets for load balancers and NAT gateways only, and private subnets for app servers and databases — one of each per AZ you use.
04
PLAN CIDRs BEFORE YOU BUILD: VPC ranges can't overlap if you ever want to peer them or connect them to your office network, and resizing later is painful. Give each environment and region its own non-overlapping block (e.g. prod 10.0.0.0/16, staging 10.1.0.0/16), and size subnets generously — EKS in particular assigns a real VPC IP to every pod and exhausts small subnets fast.
05
Every account comes with a DEFAULT VPC in each region where every subnet is public. It's fine for experiments; production workloads should live in a VPC you designed on purpose.

Code & diagrams

vpc-layout.shbash

VPC=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod}]' \
  --query Vpc.VpcId --output text)
aws ec2 modify-vpc-attribute --vpc-id $VPC --enable-dns-hostnames

# Public subnets (for ALB, NAT) — one per AZ
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.0.0/24 --availability-zone ap-south-1a
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.1.0/24 --availability-zone ap-south-1b

# Private app subnets — larger, since this is where the fleet lives
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.16.0/20 --availability-zone ap-south-1a
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.32.0/20 --availability-zone ap-south-1b

# Private data subnets
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.100.0/24 --availability-zone ap-south-1a
aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.101.0/24 --availability-zone ap-south-1b

ThreeTierVpcdiagram

Rendering diagram…

Explain it without notes

What makes a subnet 'public' in AWS?

Why does it matter that your staging and production VPCs use non-overlapping CIDR ranges, even if they're in different accounts?

Practice

How many usable IPs does a /26 subnet have in AWS?

You're planning a VPC for an EKS cluster expected to run ~3,000 pods across 3 AZs. Would three /24 private subnets be enough? Suggest a better layout.

Trade-offs

↔
Big subnets waste address space you might want for future VPCs; small subnets run out at the worst time (during a scale-out) and are hard to grow. Err large for app/pod subnets, small for public and data tiers.

Done when you can

I can calculate the usable IPs in a subnet.
I know a subnet's public/private status comes from its route table.
I can lay out public, app, and data subnets across multiple AZs.
I plan non-overlapping CIDRs across environments before building.