Subnets

Imagine a hospital where every room, operating theaters, waiting rooms, server closets, cafeteria, was connected to the same hallway with the same access card. A cafeteria visitor could wander into surgery. A patient could stumble into the server room.

That's what a flat network looks like. Every device can talk to every other device. No boundaries. No segmentation. A single compromised machine can scan and attack everything on the network.

Subnets solve this. They divide a large network into smaller, isolated segments. Your web servers live in one subnet. Your databases in another. Your internal tools in a third. Traffic between subnets passes through a router or firewall where you can enforce rules, who can talk to whom, on which ports, in which direction.

In cloud infrastructure, subnets are the fundamental building block. Every EC2 instance, RDS database, Lambda function, and load balancer lives inside a subnet. Public subnets face the internet. Private subnets are hidden behind NAT. Understanding how to carve a VPC into subnets is the single most practical networking skill in cloud engineering.

A subnet is a range of IP addresses within a larger network (the VPC). You create subnets by subdividing your VPC's CIDR block into smaller CIDR blocks.

Example: Your VPC has CIDR 10.0.0.0/16 (65,536 addresses). You might divide it like this:

Public vs Private:

• A public subnet has a route to an Internet Gateway. Instances can get public IPs and be reached from the internet.
• A private subnet has no direct internet route. Instances use a NAT Gateway for outbound-only access.

Why spread across Availability Zones: If AZ-a goes down (hardware failure, power outage), your application keeps running in AZ-b. This is the foundation of high availability in the cloud.