Subnets and CIDR in the Cloud

The RFC 1918 private ranges

VPC CIDRs come from the IPv4 private address ranges defined in RFC 1918:

Any subset of these can be used for your VPC. The cloud provider does not care which; the routing implications come from peering.

VPC sizing

Common VPC CIDR sizes:

A /16 is the standard recommendation for production VPCs. The addresses cost nothing and the headroom is invaluable when you later need to add subnets, peer additional VPCs, or migrate to dual-stack IPv6.

Subnet layout by availability zone

Cloud VPCs span multiple availability zones; each subnet belongs to exactly one AZ. A reasonable layout for a 3-AZ region using a /16 VPC:

VPC: 10.50.0.0/16

AZ-A:
  Public:   10.50.0.0/24   (251 addresses)
  Private:  10.50.16.0/20  (4091 addresses)
  Database: 10.50.32.0/24

AZ-B:
  Public:   10.50.1.0/24
  Private:  10.50.48.0/20
  Database: 10.50.33.0/24

AZ-C:
  Public:   10.50.2.0/24
  Private:  10.50.64.0/20
  Database: 10.50.34.0/24

Reserved for growth: 10.50.80.0 - 10.50.255.255

The pattern: small public subnets for load balancers and NAT gateways, large private subnets for application workloads, separate small subnets per AZ for stateful services like RDS. Symmetric layouts across AZs make routing rules and Terraform/CloudFormation templates simpler.

Public vs private subnets

A subnet is "public" or "private" based on its route table:

• Public subnet — has a default route (0.0.0.0/0) pointing to the internet gateway. Resources in public subnets can have public IPs and can be reached directly from the internet.
• Private subnet — has a default route pointing to a NAT gateway (for outbound only) or no internet route at all. Resources can reach the internet for outbound (via NAT) but cannot be reached inbound from the internet.

The separation is a security boundary. Public resources are load balancers, bastion hosts, and NAT gateways. Everything else — application servers, databases, caches — lives in private subnets. See NAT gateway vs internet gateway for the routing detail.

Reserved addresses per subnet

Cloud providers reserve a few addresses in every subnet:

A /24 advertises 256 addresses; 251 are usable. A /28 advertises 16; 11 are usable. The small-subnet tax matters more as subnets get smaller — /28 loses 31% of capacity to reservations.

CIDR overlap and peering

Two networks cannot have any overlapping CIDR if you want to peer them. Common overlap causes:

• Default VPC CIDRs (often 172.31.0.0/16 in AWS). Two default VPCs from different accounts conflict.
• Home/office networks using 192.168.0.0/16. A VPN to the office breaks if the VPC overlaps.
• Acquired companies whose existing networks use the same range.
• Multi-cloud setups where each cloud's default CIDR overlaps.

The fix is always painful — readdressing a live network is disruptive. The cheap preventive measure is to pick a non-obvious CIDR up front. 10.42.0.0/16 or 10.117.0.0/16 is far less likely to overlap than 10.0.0.0/16.

Planning for growth

A reasonable allocation strategy reserves space:

• Allocate a regional /16 even if you only need a /20 today.
• Within the /16, use only a /18 for current subnets; reserve the rest.
• Keep a documented address plan showing what's allocated and what's reserved.
• For multi-region deployments, allocate non-overlapping /16s per region (e.g., 10.50.0.0/16 us-east-1, 10.60.0.0/16 us-west-2).

IPv6 in the same VPC

Cloud providers support dual-stack VPCs: IPv4 RFC 1918 private addresses plus IPv6 globally-unique addresses, on the same subnets. IPv6 in cloud has no scarcity concern — you get a /56 or /48 prefix from the provider and have effectively unlimited subnets. The IPv4 CIDR planning still matters because IPv4 is what most cross-account, cross-cloud, and on-prem peering uses today.

See IPv6 in cloud for the dual-stack details.

Subnet sizing for common services

Kubernetes is the most common reason subnets run out of addresses. Pod-per-IP networking models can consume hundreds of IPs per node. Size pod subnets aggressively.

Frequently Asked Questions

What CIDR should I pick for my VPC?

Use one of the private ranges from RFC 1918 — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Pick a non-overlapping subset large enough for your needs and any future peerings. A /16 (65,536 addresses) is a common default and gives plenty of room. Avoid the obvious ranges (10.0.0.0/16, 192.168.0.0/24) if you might peer with networks that already use them.

How many addresses does a /24 give me?

256 total addresses, but the cloud provider typically reserves 5 of them (network, gateway, DNS, future use, broadcast equivalent), leaving 251 usable. A /24 in AWS or Azure usable size is 251. A /28 gives you 11 usable addresses. Always plan for the reserved overhead.

Should public and private workloads share a subnet?

No. Public subnets (with a route to the internet gateway) and private subnets (no direct internet route) should be separate. Put load balancers, NAT gateways, and bastion hosts in public subnets. Put application servers and databases in private subnets. The separation makes routing rules and security groups much clearer and prevents accidental public exposure.

What is CIDR overlap and why does it matter?

Two networks have overlapping CIDR ranges if their address spaces share any IPs. Peered networks, VPN connections to on-prem, and inter-cloud links all require non-overlapping CIDRs — the routing logic cannot determine which network a packet should go to. Plan ahead: pick a VPC CIDR that won't conflict with future peers, including networks you don't yet know about.

Can I expand a VPC CIDR later?

Yes, all major clouds support adding secondary CIDR blocks to an existing VPC. But it is painful — routing rules, security groups, and peering relationships may all need updating, and applications using hardcoded ranges break. Plan for growth on day one rather than relying on later expansion.