How would you plan IP addressing for a company moving to the cloud?
Show the answer
Say this first
I treat cloud ranges as part of the corporate plan, not separate. I reserve a large block per cloud and region, give each VPC a non-overlapping range sized for growth, keep it unique against on-prem, partners and other VPCs, and track it all in an IPAM. I avoid ranges that collide with common defaults like 172.17.0.0/16 for Docker and 10.0.0.0/16 for every tutorial.
Go deeper
Principles
- Unique everywhere. Anything that may ever be peered, routed over a transit hub or reached from on-prem must not overlap. Overlap is cheap to avoid on day one and very expensive to fix later.
- Hierarchical. For example
10.64.0.0/10for AWS, split by region (10.64.0.0/13us-east-1,10.72.0.0/13eu-west-1), then a/16to/20per VPC. Summaries per region keep the on-prem and transit route tables short. - Size for growth. Kubernetes and serverless consume IPs quickly. A
/16VPC is not wasteful if the block is planned; a/24VPC that has to be rebuilt is. - Leave room in each VPC. Do not carve the whole VPC into subnets on day one. You can add subnets but you cannot resize existing ones.
- Use a tool. AWS VPC IPAM or NetBox as the source of truth, so teams request ranges instead of guessing.
Ranges to avoid
| Range | Why |
|---|---|
172.17.0.0/16 | Docker's default bridge. Hosts running Docker cannot reach it. |
10.0.0.0/16, 192.168.0.0/24, 192.168.1.0/24 | Defaults everywhere, including home routers of VPN users. |
100.64.0.0/10 | Carrier-grade NAT space; often reused for Kubernetes pods. Plan it explicitly. |
169.254.0.0/16 | Link-local; used by metadata services and VPN tunnel inside addresses. |
Kubernetes ranges count too
Pod and service CIDRs that are not VPC addresses still must not overlap anything pods need to reach.
EKS, for example, picks 10.100.0.0/16 or 172.20.0.0/16 for services if you do not set one.
They will ask next
Can you grow a VPC later?
In AWS you can add secondary CIDR blocks, with some restrictions on which ranges combine. In Azure you can add address ranges to a VNet. Neither lets you resize an existing subnet.
Would you use IPv6 to avoid all this?
IPv6 removes the scarcity problem and helps with the public IPv4 charge, but most enterprises still need IPv4 for on-prem and partners, so you plan both. Dual stack is the usual step.
Traps
- Letting every team pick 10.0.0.0/16 because it is the console default.
- Forgetting partner networks and acquisitions when checking for overlap.