Most teams create their first virtual network in a hurry. Someone accepts the default range, launches a few instances, and moves on. Eighteen months later that same network needs to peer with another account, connect to an office or a data centre, and fit three times as many workloads, and the address space turns out to be the one thing you cannot cheaply change.

Network layout is one of the few cloud decisions that is genuinely hard to reverse. Compute can be resized in minutes. A VPC’s primary address range usually means building a new network and migrating into it. So it is worth an hour of planning up front.

Start With the Whole Address Plan, Not One VPC

A common trap is sizing a VPC by asking how many servers you have today. The better question is how many networks your organisation will ever need to connect, and whether any of them will overlap.

Private address ranges (the RFC 1918 blocks) are finite and shared by everyone you might connect to: other cloud accounts, partner networks, VPN users, on-premises sites. Two networks with overlapping ranges cannot be peered or routed together without translation tricks that nobody enjoys operating.

So before creating anything, write down a single allocation plan. Even a spreadsheet works. Give each environment and region a non-overlapping block, and reserve space you are not using yet. Treat it like a shared resource, because it is.

Choosing a Size

Bigger than you think, within reason. Cloud networks do not charge for unused addresses, so a generous VPC range costs nothing, while a cramped one costs a migration.

Some practical sizing habits:

• Pick a VPC block large enough that you could split it into many subnets across several availability zones without feeling squeezed.
• Remember that container platforms can consume addresses fast. Some Kubernetes networking modes assign a VPC address to every pod, so a cluster can exhaust a small subnet surprisingly quickly. Check your platform’s current documentation for how it allocates addresses.
• Remember that each subnet loses a handful of addresses to the provider’s own use. Very small subnets waste proportionally more.
• Leave unallocated gaps at both the VPC and the plan level.

Subnet Tiers and What Belongs in Each

Splitting a VPC by role, then repeating that split in every availability zone, gives you a layout that is easy to reason about and easy to secure.

Tier	Typical contents	Internet exposure	Routing notes
Public	Load balancers, NAT gateways, bastion alternatives	Direct inbound path via internet gateway	Default route to internet gateway
Private application	App servers, container nodes	None inbound; outbound through NAT	Default route to NAT gateway
Private data	Databases, caches, queues	None	No default route, or tightly restricted
Management or shared	CI runners, internal tooling, endpoints for cloud services	None	Routes to peering or transit as needed

The point of the tiers is not ceremony. It lets you express rules like “only the load balancer tier can reach the application tier” in a way that survives staff turnover. When a new engineer asks where to put a service, the answer is obvious.

One subnet per tier per availability zone is the usual pattern. Resist the urge to put everything in one big subnet per zone because it is easier on day one.

Routing and Egress

Each subnet is associated with a route table, and that table is what actually makes a subnet public or private. A subnet is public only if it routes to an internet gateway. Naming alone does nothing.

Egress deserves its own thought. Private workloads usually still need to reach package repositories, container registries and third-party APIs. A NAT gateway per availability zone avoids cross-zone dependencies, though it also means more gateways to pay for and monitor. For traffic to the provider’s own services, private endpoints keep that traffic off the public internet and often reduce NAT traffic. Check the provider’s current documentation and pricing page for how each option is billed, since this changes.

If you are connecting many networks, a hub-and-spoke model with a transit gateway or equivalent scales better than a mesh of individual peering connections. Peering is non-transitive in most clouds, so a full mesh of ten networks needs a lot of links.

A Realistic Example

Imagine a team with three environments (dev, staging, production) in two regions, and a data centre they expect to connect within a year. They decide to carve a large private block into per-environment, per-region chunks, leaving roughly half the block unassigned. Production in the first region gets the largest chunk, since it will run the container platform.

Inside that chunk they define three tiers across three zones. Public subnets are small, since only load balancers and NAT live there. Application subnets are the largest, because pods will draw addresses from them. Data subnets are mid-sized.

A year later the data centre link arrives and its range does not collide with anything. When a new region is needed, a pre-reserved block is already waiting. Nobody renumbers anything. That is the entire payoff, and it is invisible, which is why this work is easy to skip.

Mistakes Worth Avoiding

• Accepting defaults in every account. Default ranges are identical across accounts, which guarantees overlap the moment you try to connect two of them.
• Allocating by headcount of servers today. Growth, containers and managed services all consume addresses.
• Making everything public “temporarily”. Temporary public exposure tends to become permanent. Start private and open specific paths deliberately.
• Forgetting IPv6 and dual-stack questions. Decide consciously whether you need them, rather than discovering it later. Requirements vary by provider and workload.
• Undocumented allocations. If the plan lives in one engineer’s head, overlap is only a matter of time.

Frequently Asked Questions

Can I change a VPC’s CIDR range after creating it? Providers vary. Many let you add secondary ranges, which helps with growth, but replacing the primary range typically means building a new network. Check your provider’s current documentation, and plan as though changing it will be painful.

How many subnets should I create per availability zone? One per tier is a sound starting point, so three or four per zone. Add more only when a real isolation or routing need appears, such as a separate subnet for a specific compliance boundary.

Do I need a separate VPC per environment? Often yes, at least between production and everything else. Separate networks, ideally separate accounts, limit blast radius and make permissions simpler. Smaller teams sometimes share one network for non-production environments.

Is a NAT gateway required for private subnets? Only if private workloads need outbound internet access. If they only talk to provider services, private endpoints may be enough, and some workloads need neither.

What if I already have overlapping ranges? You have options, such as address translation, proxying through a shared service, or migrating one side. Each adds complexity, so prevention is far cheaper. Treat the allocation plan as mandatory for any new network.

Next Step

Open a document today and list every network you run or expect to connect: cloud accounts, regions, offices, VPN pools. Mark the ranges each one uses, find any overlaps, and reserve a block for each environment you expect to add. Do this before the next VPC gets created.