Landing Zone CIDR Planning: Avoid IP Overlap Before Migration

Title: Landing Zone CIDR Planning: Avoid IP Overlap Before Migration

Before you build an AWS landing zone, allocate one non-overlapping RFC 1918 supernet for the entire estate, carve fixed per-account blocks from it, and reserve headroom for on-premises networks and any second cloud. You cannot resize a VPC CIDR after creation, so the plan you write this week is the one you live with for years. Landing zone CIDR planning is a one-time decision with a long tail of consequences, and it is worth an afternoon of arithmetic before anyone runs terraform apply.

This matters most right before a migration. The moment you connect on-premises to AWS over Direct Connect, a VPN, or Transit Gateway, two address spaces that were previously independent have to coexist on the same routing domain. If they overlap, some traffic simply will not route, and you find out during cutover instead of during design.

What to check first before you allocate anything

Do not open the AWS console yet. Build an inventory of every private range already in use anywhere that will eventually be reachable from AWS.

That includes on-premises data centres and offices, existing cloud accounts, VPN concentrators, partner networks you route to, and any SaaS or managed service that injects its own routes. AWS Well-Architected guidance is blunt about the requirement: the IP ranges of your VPCs must not overlap when peered, connected via Transit Gateway, or connected over VPN, and you must also avoid conflicts with on-premises environments and other cloud providers.

Two traps show up repeatedly at this stage:

• The default landing zone range. If you provisioned accounts through AWS Control Tower, every VPC it created carries the same default CIDR. To peer them you have to change the range in the Account Factory settings so addresses do not overlap, so an estate built over time can already contain duplicates before you have made a single deliberate decision.
• Ranges AWS uses internally. Some AWS services sit on 172.17.0.0/16. The VPC documentation calls out Cloud9 and SageMaker specifically and tells you not to build a VPC on that range, because you will get conflicts when those services are in play.

Write the inventory down as a table of range, owner, and location. If you cannot produce that table, you are not ready to allocate, and no amount of clever subnetting later will fix an overlap you did not know about.

Landing zone CIDR planning: sizing the supernet

Allocate top-down. Pick one large private supernet for the whole AWS estate, then divide it into predictable, equal-sized blocks per account or per environment. Contiguous, aligned blocks summarise into a handful of routes on your Transit Gateway and Direct Connect, instead of a sprawling prefix list your network team has to hand-maintain.

A VPC CIDR in AWS has hard limits worth memorising. The allowed block size is between a /16 (65,536 addresses) and a /28 (16 addresses), and AWS recommends you draw from the RFC 1918 private ranges. A workable scheme for a mid-size estate carves a /16 per region into /20 blocks:

10.40.0.0/16        AWS, eu-west-1, whole estate
  10.40.0.0/20      prod-account-a      (4,096 addresses)
  10.40.16.0/20     prod-account-b
  10.40.32.0/20     staging-account-a
  10.40.48.0/20     shared-services (TGW, endpoints, DNS)
  10.40.64.0/20 ... reserved for growth

Then split each /20 into subnets across Availability Zones, leaving whole /22 or /23 gaps unallocated. The gaps are the point. They are cheaper than any later remediation.

Reserve deliberately for the things that always appear later: a shared-services VPC for interface endpoints, DNS resolvers and centralised egress; a block that will never be used inside AWS but is held for on-premises summarisation; and a completely separate supernet penciled in for a second region or a second cloud. Keep AWS, Azure and Google Cloud in different top-level supernets from day one so a future interconnect does not collide.

The trade-off: reserve big now, or reclaim later

Here is the honest tension. Reserving generous blocks wastes address space you may never fill. On a single AWS account that feels wasteful. Across an estate connected to a finite on-premises range, private IPv4 is genuinely scarce, and over-allocation on one team's VPC is address starvation for another.

The reason to lean toward reserving anyway is that AWS makes shrinking expensive and growing awkward. You cannot increase or decrease the size of an existing VPC CIDR block. If a /24 VPC fills up, your options are to add a secondary CIDR or rebuild the VPC.

Adding a secondary block is supported: after creation you can associate additional IPv4 CIDR blocks with a VPC, subject to a per-VPC quota and to restrictions on which ranges you can use. That is the escape hatch, but it is not free. A second, non-contiguous block means the VPC no longer summarises cleanly, so it propagates as an extra route everywhere it is advertised, and every route table, security group referencing CIDRs, and firewall rule that assumed one range now has to learn about two. The cost of under-allocating is not paid once; it is paid every time someone reasons about that network for the rest of its life.

So the trade-off is concrete: waste some address space now, or accept permanent routing and operational complexity later. For most estates, err toward reserving, because the wasted /20 costs nothing and the fragmented routing table costs an on-call engineer clarity at 3am.

When you genuinely cannot avoid an overlap

Sometimes the overlap is not yours to fix. You acquire a company, you inherit a partner network, or two legacy 10.0.0.0/16 estates have to talk. AWS does not paper over this. Transit Gateway does not support routing between VPCs with identical CIDRs, and if you attach a VPC whose CIDR matches an already-attached VPC, the new route is simply not propagated into the Transit Gateway route table. The connection appears to succeed and then quietly does not carry the traffic you expect.

Your realistic options, in rough order of preference:

None of these is as good as non-overlapping ranges chosen up front. They exist because the alternative is worse, not because they are pleasant. Reach for them only when re-IPing is genuinely off the table.

Track allocations in a source of truth

A spreadsheet works until two people edit it in the same week. AWS provides Amazon VPC IP Address Manager (IPAM) to plan, allocate and monitor address space across accounts and regions, and the Well-Architected guidance explicitly recommends an IPAM system to automate allocation. Even if you do not adopt the managed service, keep allocations in something versioned and reviewed.

If you drive VPCs with Terraform, encode the plan so the allocation is the code, and add the secondary block only where a VPC really needs it:

resource "aws_vpc" "prod_a" {
  cidr_block           = "10.40.0.0/20"
  enable_dns_hostnames = true
  tags = { Name = "prod-account-a", ipam_pool = "eu-west-1-prod" }
}

# Escape hatch, used sparingly and reviewed
resource "aws_vpc_ipv4_cidr_block_association" "prod_a_extra" {
  vpc_id     = aws_vpc.prod_a.id
  cidr_block = "100.64.0.0/22"
}

Getting the address plan right is the least glamorous part of a landing zone and the one that quietly decides whether your migration cutover is boring or a bad night. If you are shaping this before a data-centre exit, it belongs in the same conversation as the cloud architecture and landing zone design and the cloud migration plan itself, because the addressing decision constrains both.

Frequently asked questions

What size CIDR block should a VPC use in AWS?

Between a /16 and a /28, since that is the full range AWS allows, and drawn from RFC 1918 space. For a production VPC that will hold several AZs and grow, a /20 or /21 is a common starting point. Size for where the workload will be in a few years, not where it is today, because you cannot resize the block afterward.

Can I change a VPC CIDR block after it is created?

No. You cannot increase or decrease the size of an existing VPC CIDR block. Your only in-place option is to associate an additional secondary CIDR block, which works but fragments your routing because the VPC no longer advertises as a single summarised prefix. If a VPC is badly undersized, rebuilding it cleanly is often less painful long term than stacking secondary blocks.

Why does Transit Gateway drop traffic between two VPCs?

If the two VPCs have identical CIDR blocks, Transit Gateway will not route between them and will not propagate the duplicate route. The attachment looks healthy, but the traffic goes nowhere. Check for CIDR overlap first whenever a Transit Gateway path silently fails, before you start debugging route tables and security groups.

How do I connect on-premises to AWS when the ranges already overlap?

The clean fix is to re-IP one side so the ranges no longer collide. When that is impossible, you translate the overlapping range with private NAT or front the specific services with a proxy or PrivateLink, accepting extra hops and obscured source addresses in your logs. These are mitigations for a design mistake, so treat them as a last resort rather than a pattern to reach for by default.

Should I use one big CIDR for the whole estate or many small ones?

Allocate one large supernet and carve equal, contiguous, aligned blocks from it per account or environment. Contiguous blocks summarise into a few routes on Transit Gateway and Direct Connect, which keeps route tables small and firewall rules readable. Reserve unused gaps deliberately, because holding empty address space costs nothing while reclaiming a badly fragmented plan costs real engineering time.