Cloud Subnets: Your Virtual Network's Neighborhoods

WHY IT EXISTS: Cloud providers give you a large, private network space called a Virtual Private Cloud (VPC). Placing all your resources—web servers, databases, caches—into one giant, flat network is a security and management nightmare. Subnets were created to partition this large network into smaller, manageable, and isolated segments. This allows for logical grouping, security boundaries, and controlled traffic flow.

THE MENTAL MODEL: A subnet is a neighborhood within your virtual city (the VPC). Your VPC has a main address range, like 10.0.0.0/16, and you carve out smaller blocks for your neighborhoods. The web-server-subnet might get 10.0.1.0/24, and the database-subnet gets 10.0.2.0/24. Machines in the same subnet can typically talk to each other easily, while communication between subnets requires explicit routing and firewall rules, like needing to take a specific highway to get from one neighborhood to another.

HOW IT WORKS: When you create a subnet, you define its IP address range in CIDR notation (e.g., 192.168.1.0/24) within a specific VPC. This CIDR block determines how many IP addresses are available. For a /24 range, that's 256 total addresses, though the cloud provider always reserves a few for its own networking purposes. Any resource, like a virtual machine, launched into this subnet gets assigned an available IP address from this range. Subnets are also tied to a specific region or availability zone, linking your virtual network segment to a physical datacenter location.

WHEN TO USE IT: Use subnets to organize any non-trivial cloud deployment. A classic use case is a three-tier application: a public subnet for web servers that accept internet traffic, a private subnet for application servers, and another private subnet for databases. This creates strong security boundaries by restricting traffic flow between tiers. You also use them to separate environments, like a dev-subnet and a prod-subnet, within the same VPC.

WHEN NOT TO USE IT: You almost always need at least one subnet. The only time you might not actively create one is for simple tutorials where the cloud provider provisions a default subnet for you. For any real application, avoiding a planned subnet layout leads to a flat, insecure, and unmanageable network. The question isn't if you should use them, but how you should plan their sizes and boundaries.

ONE CANONICAL EXAMPLE: A common setup involves a VPC with the address space 10.20.0.0/16. You create a public subnet with the CIDR 10.20.1.0/24 for your load balancer and web servers. This subnet is attached to an Internet Gateway. You then create a private subnet with CIDR 10.20.2.0/24 for your application servers. Finally, a second private subnet, 10.20.3.0/24, houses your databases, with firewall rules allowing access only from the application subnet.