Planning CIDR for AWS VPC (and Any Cloud)
Cloud networks are built on the same CIDR and subnetting rules as everything else, but a few cloud-specific habits save you from painful re-addressing later.
Start from the whole estate, not one VPC
Pick a single large private block (from RFC 1918 space) for your organization, then carve VPCs out of it. If every team independently grabs 10.0.0.0/16, you can never peer those VPCs or connect them to on-prem — overlapping ranges cannot be routed together.
| Scope | Suggested size | Holds |
|---|---|---|
| Whole org | 10.0.0.0/8 |
everything |
| Region/account | 10.20.0.0/16 |
~256 subnets |
| VPC | 10.20.0.0/20 |
16 × /24 subnets |
| Subnet (AZ) | 10.20.1.0/24 |
256 addresses |
Cloud gotchas
- The provider reserves addresses in each subnet. AWS takes the first four and the last one, so a
/24gives 251 usable, not 254. - Leave headroom. You cannot easily shrink or renumber a busy VPC; size up front.
- Avoid popular defaults like
10.0.0.0/24and192.168.0.0/24if you will ever VPN to offices that use them.
Use our CIDR tools to test membership and split a block into subnets, and the subnet calculator for exact host counts. For IPv6, providers assign a /56 or /64 per VPC/subnet — no NAT required.
Note: Document your allocation plan in one place. The cheapest subnet mistake to fix is the one you never made because you wrote the plan down first.