By Yair Knijn · January 22, 2026

The shadow VPCs no cloud network engineer knows about, until they overlap your on-prem space

The cloud network engineer keeps a clean diagram. Three sanctioned VPCs, documented CIDRs, peering drawn with arrows, all reviewed in change control. The diagram is honest about what it shows. It is silent about everything it does not, which is the dozen VPCs that engineering, data, and a contractor's account spun up last quarter without asking anyone.

The wrong assumption is that a VPC has to be approved to exist. In a self-service org it only has to be clicked into being, and the click happens in accounts the network team has never opened.

Default CIDRs: why every new VPC picks the same ranges

Self-service rewards the path of least resistance, and the cloud consoles hand you a default. Spin up a default VPC in AWS and it lands on 172.31.0.0/16. Run a Terraform module a teammate copied from a gist and you inherit whatever 10.0.0.0/16 the author typed once and never thought about again. Nobody is being careless. They are accepting the value the tool offers, and the tool offers the same value to everyone.

The result is dozens of networks that are byte-for-byte identical across accounts and clouds. Two teams running 10.0.0.0/16 in separate AWS accounts feel no pain at all, because nothing routes between them yet. The collision is real the moment both are created. It is just invisible.

Cross-cloud inventory: AWS, Azure, and GCP in one view

The reason it stays invisible is that no console shows you the others. The AWS VPC list shows AWS. Azure VNets live in a different portal under a different identity model. GCP VPCs sit in a third console with their own quirk that a single VPC spans regions. You cannot see 10.0.0.0/16 in three clouds at once because there is no screen that renders all three at once.

An engineer auditing for overlap has to pull from each provider and reconcile by hand. The pieces a real inventory needs are simple to name and tedious to assemble:

• Every VPC, VNet, and subnet CIDR across all accounts and projects, not just the ones in the network team's own subscription.
• The on-prem ranges already routed over the corporate backbone, including the RFC 1918 space carved years ago.
• Who owns each block, so a flagged overlap has a name attached and not just a question mark.

The interconnect surprise: collisions you can't route around

The day the overlap stops being theoretical is the day someone files a ticket to connect two of these networks. AWS does not let you peer two VPCs with overlapping CIDRs. The request is rejected outright, not degraded. A Transit Gateway will not install a route for a destination that already matches another attachment, so one network simply becomes unreachable through it. A site-to-site VPN back to the data center hits the same wall when the cloud range shadows an on-prem subnet.

At that point the cheap fix is gone. You are choosing between renumbering a live VPC, which means new subnets, new route tables, and a maintenance window for every workload in it, or bolting on NAT to translate one side into a borrowed range, which adds latency and a layer nobody will remember in a year. Both are the bill for an allocation that was free to make and never recorded.

A CIDR registry that spans every account and on-prem

The fix is structural, not heroic. There has to be one place that knows every CIDR before it is assigned, spanning all three clouds and the physical network, so a new VPC is checked against the registry at request time instead of at interconnect time. A registry that only the network team writes to, while teams self-serve elsewhere, drifts the same day it is published. The registry has to be where the allocation happens.

Spot IPAM keeps that single source across every cloud account and on-prem range in one Environment, reconciling what each provider actually has against what was planned, and flags an overlap when a block is requested rather than when a route fails. If you want to see your real cross-cloud space in one view, book a demo and bring the account list you think is complete.