Subnet Example: Splitting a Cloud VPC Into Public and Private Subnets

Dividing a cloud network into subnets uses the same arithmetic as reading one block, applied to several laid end to end. A team creates a VPC (virtual private cloud), a private network in a cloud account, with the range 10.0.0.0/16, and needs four subnets: a public and a private one in each of two availability zones, the separate data centres a region is built from.

Public subnets hold what the internet must reach, such as load balancers; private subnets hold application servers and databases. The team chooses /24 for each, 256 addresses, which leaves room in the /16 for many more subnets later.

Three things are worth noticing.

The blocks never overlap. Each /24 starts where it can divide evenly, at a multiple of 256 addresses, and ends before the next begins. A /16 holds 256 such /24 blocks, from 10.0.0.0 to 10.0.255.0, and this plan uses four.

The gap is deliberate. The private subnets start at 10.0.10.0 rather than 10.0.2.0, so the public subnets can grow into 10.0.2.0 to 10.0.9.255 later without renumbering anything. Planned gaps are cheap; moving a running database to another subnet is not.

Each subnet holds 251 usable addresses, not 254. AWS reserves five in every subnet: the network address, the next three for its router, its DNS server and future use, and the last address. The count from the prefix is still the starting point.

The same layout fits any cloud provider. What changes is how many addresses each reserves.