IP Address Management for Multi-Cloud and Hybrid Networks
Most companies running production infrastructure have it in more than one place. An AWS (Amazon Web Services) account handles the customer-facing application. An Azure subscription runs internal tools. A physical data center in the office hosts legacy systems and build servers. A colocation facility, where you rent rack space in someone else's data center, handles the database tier. Each of these environments has its own network, its own address space, and its own way of showing you what's in it. Keeping track of all that address space from one place is the core challenge of hybrid and multi-cloud IPAM (IP Address Management).
Every cloud provider gives you a way to create isolated virtual networks. AWS calls them VPCs (Virtual Private Clouds). Azure calls them VNets (Virtual Networks). Google Cloud calls them VPC networks. In each case, you pick a private IP address range, typically from the blocks defined by RFC 1918, a standard that reserves certain ranges for internal use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The cloud provider builds a logically isolated network around whatever range you choose. Your on-premises data center uses those same private ranges, and so does the colocation facility. Each environment works perfectly on its own. The trouble starts when you try to see all of them together.
Typical hybrid infrastructure with overlapping address space
┌─────────────────────┐ ┌─────────────────────┐
│ AWS Production │ │ Azure Internal │
│ │ │ │
│ VPC 10.0.0.0/16 │ │ VNet 10.0.0.0/16 │
│ 10.0.1.0/24 web │ │ 10.0.1.0/24 app │
│ 10.0.2.0/24 app │ │ 10.0.2.0/24 db │
│ 10.0.3.0/24 db │ │ 10.0.3.0/24 mgmt │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
169.254.1.0/30 169.254.2.0/30
VPN tunnel VPN tunnel
│ │
┌──────────┴────────────────────────┴──────────┐
│ On-Premises │
│ │
│ Core network 10.0.0.0/8 │
│ 10.0.0.0/24 servers │
│ 10.1.0.0/24 workstations │
│ 10.2.0.0/24 voice/video │
└──────────────────────┬───────────────────────┘
│
172.16.0.0/30
dedicated circuit
│
┌───────────┴───────────┐
│ Colocation Facility │
│ │
│ 10.10.0.0/16 │
│ 10.10.1.0/24 db │
│ 10.10.2.0/24 cache │
└───────────────────────┘
Three environments use ranges within 10.0.0.0/8.
AWS and Azure chose the same /16 independently.The most common headache is address overlap. When your AWS team set up the production VPC three years ago, they picked 10.0.0.0/16. When the Azure team created their environment a year later, they also picked 10.0.0.0/16. It was a reasonable default both times, and since the two networks weren't connected, there was no technical conflict. Your on-premises network has been using 10.0.0.0/8 since before either cloud account existed. Now you have three environments that all contain addresses in the 10.0.x.x range, and a spreadsheet with three rows labeled "10.0.0.0/16" and no way to distinguish which belongs to which environment.
This is the same overlapping address space problem that VRFs (Virtual Routing and Forwarding instances) solve at the network layer. We covered VRFs in detail in a previous post, but the short version is that a VRF lets a single router maintain separate routing tables so the same IP range can exist in multiple isolated contexts without conflict. Multi-cloud infrastructure creates the same situation at a higher level of abstraction: each environment is its own routing domain, and the same CIDR (Classless Inter-Domain Routing) block can legitimately appear in several of them. Your tracking system needs to understand this. If it treats every IP address as globally unique, it will either reject valid overlapping configurations or create duplicate rows that look like data-entry mistakes.
Overlap becomes a real engineering problem the moment you try to connect these environments. A VPN (Virtual Private Network) tunnel between your AWS VPC and your on-premises data center requires a routable path between them, which means the address ranges on each end need to be distinct. If both sides use 10.0.1.0/24 for their application tier, the router has no way to tell whether a packet destined for 10.0.1.15 should go to AWS or stay on-premises. The typical fix is NAT (Network Address Translation), where one side's addresses are remapped to a different range before traffic crosses the tunnel. NAT solves the routing ambiguity, but it adds a layer of address indirection that has to be documented somewhere: the "real" address on one side, the translated address on the other, and which NAT rule maps between them. If that mapping lives only in the VPN gateway's configuration and nowhere else, troubleshooting connectivity issues across environments becomes a guessing game.
The interconnects themselves consume address space that's easy to overlook. A VPN tunnel between two sites needs a transit subnet, usually a small /30 (four addresses, two usable) or /31 (two addresses, both usable) block, to carry traffic between the two endpoints. A dedicated circuit to a colocation facility has its own transit subnet. If you peer with a partner organization or a managed service provider, there's another small block for that connection. A moderately complex hybrid setup might have ten or fifteen transit subnets scattered across VPN configurations, router interfaces, and cloud gateway settings. These addresses belong to none of the environments individually, but they're critical to how the environments talk to each other. Losing track of a transit subnet is how you end up troubleshooting a routing loop at 3 a.m. because the addresses involved aren't documented anywhere your team thinks to look.
Transit subnets are small but easy to lose track of
# Interconnect address space for a four-site hybrid network
AWS ↔ On-Prem VPN
Tunnel 1: 169.254.1.0/30 (.1 = on-prem, .2 = AWS VGW)
Tunnel 2: 169.254.1.4/30 (redundant path)
Azure ↔ On-Prem VPN
Tunnel 1: 169.254.2.0/30 (.1 = on-prem, .2 = Azure VNG)
On-Prem ↔ Colo dedicated circuit
Transit: 172.16.0.0/30 (.1 = on-prem, .2 = colo router)
AWS ↔ Azure VNet peering
No transit subnet needed (cloud-native peering)
But ranges must not overlap!
Total: 5 transit subnets, 14 addresses
None of these appear in any environment's "subnet list"NAT gateways add another category of addresses that needs tracking. Cloud environments frequently use NAT gateways to give private resources access to the internet through a small pool of public IP addresses. Those public IPs matter for firewall rules, DNS records, and allowlists maintained by partners and vendors. If your organization has five NAT gateways across three cloud providers, each with one or two elastic public IPs, that's up to ten addresses that need to be documented separately from the private ranges they sit in front of. When a partner asks "what IPs should we allowlist for your API calls?" you need to answer with confidence, not by logging into three cloud consoles and hoping you find them all.
The documentation problem in a hybrid environment is fundamentally one of fragmentation. AWS shows you your VPCs and subnets in the AWS console. Azure shows you VNets and address spaces in the Azure portal. Your on-premises network might be documented in a spreadsheet, a wiki page last edited in 2024, or the memory of a senior engineer who set it up. When a new project needs a /24 block that doesn't conflict with anything in any environment, answering that question means checking three or four different systems, cross-referencing by hand, and trusting that nothing has changed since the last time someone looked. The larger the infrastructure, the longer this takes and the more likely it is that someone skips a system and creates a conflict that doesn't surface until traffic starts flowing.
An IPAM tool designed for this kind of environment gives you a single place to record everything. The organizing principle is simple: every subnet in every environment goes into one system, structured in a way that mirrors your actual infrastructure. You might create a top-level folder for each environment and nest subnets under them. Overlapping ranges are handled through VRFs, so your three separate 10.0.0.0/16 blocks coexist in the system without confusion, each tagged with the routing context it belongs to. Transit subnets get their own section. Public NAT addresses get documented alongside the private ranges they serve. Custom fields let you attach cloud-specific metadata, like an AWS VPC ID or an Azure resource group, so the record in your IPAM tool links back to the resource it describes.
Organizing multi-cloud address space in IPCraft
Folders
├── AWS Production VRF: aws-prod
│ ├── 10.0.0.0/16 VPC vpc-0abc123
│ │ ├── 10.0.1.0/24 web tier (us-east-1a)
│ │ ├── 10.0.2.0/24 app tier (us-east-1b)
│ │ └── 10.0.3.0/24 database (us-east-1a)
│ └── 10.1.0.0/16 VPC vpc-0def456 (staging)
│
├── Azure Internal VRF: azure-internal
│ └── 10.0.0.0/16 VNet internal-tools
│ ├── 10.0.1.0/24 internal apps
│ ├── 10.0.2.0/24 databases
│ └── 10.0.3.0/24 management
│
├── On-Premises VRF: on-prem
│ └── 10.0.0.0/8 core allocation
│ ├── 10.0.0.0/24 servers
│ ├── 10.1.0.0/24 workstations
│ └── 10.2.0.0/24 voice/video
│
├── Colocation VRF: colo-dal
│ └── 10.10.0.0/16 Dallas facility
│ ├── 10.10.1.0/24 primary database
│ └── 10.10.2.0/24 cache cluster
│
└── Transit / Interconnect VRF: global
├── 169.254.1.0/30 AWS ↔ On-Prem tunnel 1
├── 169.254.1.4/30 AWS ↔ On-Prem tunnel 2
├── 169.254.2.0/30 Azure ↔ On-Prem tunnel
└── 172.16.0.0/30 On-Prem ↔ Colo circuitThe other half of making this work is automation. Cloud infrastructure is provisioned through tools like Terraform, CloudFormation, and Ansible, and those tools need IP addresses at provisioning time. If the IPAM tool has an API (a way for software to request information over HTTP, the same protocol your web browser uses), the provisioning pipeline can query for the next available address in a specific subnet and VRF, register it, and move on. The allocation is recorded the moment it happens, in the same system that everyone else checks before making changes. There's no window where a manually updated spreadsheet lags behind reality and allows a conflict to form.
Terraform — allocate from the correct VRF before provisioning
# Ask IPCraft for the next free IP in the AWS web tier subnet
data "http" "next_ip" {
url = "https://api.ipcraft.io/api/v1/subnets/${var.web_subnet_id}/first-free"
request_headers = {
Authorization = "Bearer ${var.ipcraft_api_key}"
}
}
# Use that IP when creating the instance
resource "aws_instance" "web_server" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.medium"
subnet_id = var.aws_subnet_id
private_ip = jsondecode(data.http.next_ip.response_body).ip
}
# The address is now registered in IPCraft and visible to the whole team.
# No spreadsheet update needed. No drift between systems.Utilization visibility across environments is where a centralized tool pays off most quickly. Knowing that your AWS production VPC is 62% utilized while your colocation /16 is only at 11% gives you immediate insight into where new workloads should land and where you have room to grow. Calculating that by hand across four environments, each with its own console and its own way of displaying address data, is an afternoon project. In a unified IPAM tool, it's a glance at the dashboard. The same goes for capacity planning: when the web tier subnet in AWS is approaching 85% utilization, you can see that before the on-call engineer discovers it at 2 a.m. by trying to launch a new instance and getting an "insufficient IP addresses" error.
The more distributed your infrastructure becomes, the more valuable a central address registry is. A single cloud account with ten subnets is manageable in a spreadsheet. Three cloud accounts, two data centers, a colocation facility, and a dozen VPN tunnels connecting them is a fundamentally different problem. The teams that handle multi-cloud networking well tend to share one habit: they invested early in a single source of truth for their address space, before the sprawl made it painful. Getting started doesn't require migrating everything at once. Documenting your transit and interconnect subnets alone is often the highest-value first step, since those are the addresses most likely to be undocumented and most likely to cause an outage when they conflict. From there, folding in each cloud environment and your on-premises space is incremental. If you're ready to try it, IPCraft's free tier covers up to 100 subnets and supports VRFs out of the box, which is enough to map your hybrid footprint and see whether a unified view fits your workflow.