How to plan IP addresses for a multi-cloud network

Why this matters

IP addresses are the hardest thing to change in a multi-cloud network. Subnet ranges end up in security groups, firewall policies, DNS zones, load balancer rules and monitoring queries. A bad choice at the start turns into a renumbering project later, and renumbering a live VPC usually means rebuilding it.

The usual break is overlap. Two VPCs both using 10.0.0.0/16 cannot reach each other through a peering, a transit gateway or a VPN. Cloud routers do not translate addresses for you. The packet gets dropped, or sent to a local resource that happens to hold the same address. Fixing that means moving workloads, not editing a config file.

A written plan also keeps route tables small. If each region sits inside one block you can summarize, a single route covers it. If ranges are scattered, you end up with hundreds of /24 entries and a change window every time a team adds a subnet.

Before you start

Gather what already exists. On-prem data centers, client VPN pools, home routers, partner links, systems inherited from an acquisition. Export the ranges from each cloud account: describe-vpcs in AWS, az network vnet list in Azure, gcloud compute networks subnets list in Google Cloud. Put every CIDR in one sheet before you allocate anything new.

Know the limits. AWS VPCs take /16 to /28, Azure VNets take /2 to /29, and Google Cloud subnet ranges have their own bounds. Each provider also holds back addresses in every subnet: five in AWS, five in Azure, four in Google Cloud. A /29 in Azure leaves three usable addresses, not eight. Size subnets with that in mind.

Decide where the plan lives. One register, one owner, kept in version control. Cloud native IPAM works if you are mostly on one provider, and AWS VPC IPAM or Azure Virtual Network Manager IPAM will both track allocations and flag overlaps. NetBox and phpIPAM work across providers. Choose now whether you reserve IPv6 blocks in the same pass, because retrofitting them is a second round of edits on every subnet.

How to do it

The steps below show how to plan IP addresses for a multi-cloud network from a blank page. Work top down. Carve 10.0.0.0/8 into /12 blocks by purpose: production, non-production, shared services, transit, partner and acquisition space, then a large reserve. Inside each /12, give every cloud and region its own /16. AWS us-east-1 might sit on 10.16.0.0/16 and Azure East US on 10.17.0.0/16. The mapping matters more than the exact numbers, because it lets every route summarize.

Then carve subnets by tier inside each /16. Public subnets for load balancers and NAT gateways, private subnets for applications, separate subnets for data, one of each per availability zone. Leave gaps in the numbering, so a team can add a subnet without renumbering its neighbors. Keep the same layout in every region, and a firewall rule or runbook will work anywhere.

Record the rule, not only the result. Write down that this block is production US, that one is staging EU, and who may allocate from each. Add the blocks to internal DNS as reverse zones. Put the CIDRs in a variable file that your pipeline reads, so nobody types a range from memory into a console.

1. Inventory every existing range. Pull CIDRs from each cloud account, from on-prem, from client VPN pools and from partner links. Put them in one sheet and name an owner for each entry. Anything you miss here becomes an overlap later.
2. Reserve large blocks by purpose. Split 10.0.0.0/8 into /12 blocks for production, non-production, shared services and transit, then keep a large reserve. The reserve is what lets you absorb an acquisition or a new region without touching the rest of the plan.
3. Assign a /16 per cloud per region. Give each provider and region its own /16, such as AWS us-east-1 on 10.16.0.0/16 and Azure East US on 10.17.0.0/16. Write the mapping down before anyone builds a VPC or VNet. The exact numbers matter less than the pattern, because the pattern is what makes routes summarizable.
4. Size subnets with reserved addresses in mind. Count the addresses each cloud holds back in every subnet, then add headroom for autoscaling and load balancers. /20 and /24 subnets grow more easily than /28s. Number subnets in steps of four so a new one can slot in without renumbering its neighbors.
5. Keep shared services in their own block. Put DNS forwarders, monitoring, transit and jump hosts in a dedicated block. That keeps test workloads out of production routes and makes firewall rules easier to name and review.
6. Keep one register with owners. Record block, cloud, region, environment, owner and date for every allocation. Review the register when a team asks for a new range, and reject anything that overlaps a live block or a VPN pool.
7. Reserve IPv6 blocks in the same pass. Take a /56 per VPC in AWS and the equivalent from each provider, and reuse your region mapping. Reserving now costs a line in the register. Adding IPv6 later touches every subnet and firewall rule.
8. Test in a sandbox before rollout. Build one small network per cloud, connect them and push a little traffic. You learn each provider's route limits and firewall defaults without putting production at risk.

How to check it worked

Run an overlap check. A short script that parses every CIDR and tests for containment catches the one mistake that hurts. Run it in CI when someone adds a subnet, and run it against on-prem and VPN ranges too, not only cloud ranges.

Build the first region in each cloud exactly as planned and connect them. From a host in one cloud, ping or curl a host in another. Check that DNS resolves names and that reverse lookups return the zones you planned. Test a path that should fail as well, such as traffic between production and non-production that a rule blocks.

Read the route tables. If one region needs more than a couple of routes on a transit gateway, the addressing is not summarizing and something drifted. Check that the IPAM tool and the register agree, and that tags and firewall rule names follow the scheme, so the next engineer can trace an address back to an owner.

Mistakes to avoid

The default 10.0.0.0/16 in every new account. It is the first option in the console, and it is the reason two regions can never talk. The same goes for 192.168.0.0/16, which collides with home routers and client VPN pools, and for 100.64.0.0/10, which other services may already use for their own traffic.

Sizing subnets to today's needs. A /28 looks tidy until autoscaling or a load balancer needs addresses, and the reserved addresses make it tighter. Leaving gaps between blocks costs nothing. Letting each team pick its own range costs you a renumbering project.

Skipping IPv6 because there is no pressure yet. When you finally add it, you run the whole allocation exercise again and touch every subnet and rule. Reserve the blocks now even if you deploy later.

If you want a second opinion on the scheme before you build, one option is the Expert architecture session from Cloudverg, $450 one-time. That is 90 minutes with a senior architect, a pre-read of your diagrams and a written summary with ranked recommendations. Useful when the plan is still a spreadsheet and the first deployment is weeks away.

Frequently asked questions