Cloud IPAM: Managing IPs Across AWS, Azure, and GCP

Private IPv4 space is one of the few resources your workloads share across every environment, yet none of the major clouds treats it the same way. AWS ships a mature IPAM service with automatic discovery and a paid advanced tier. Azure added its own IPAM to Virtual Network Manager, a younger service with real limitations. GCP offers building blocks instead of a console, leaving allocation planning to whoever writes the Terraform. The result for a team running workloads in two or three clouds is the same in every combination: each provider sees only its own slice of your address space, and the overlaps, conflicts, and wasted ranges live in the gap between them.

This guide compares the three approaches on the dimensions that matter when you actually operate across clouds: how each one models address space, what it discovers automatically, what it enforces, what it costs, and where its view stops. It then maps the blind spots that all three share and argues for the piece most multi cloud teams are missing, a single neutral ledger that tracks AWS, Azure, and GCP space next to your on premises ranges. The table below gives the quick landscape, and the sections that follow go into the detail behind it.

At a Glance: Cloud IPAM Options

Why Per Provider IPAM Is a Trap

The trap starts with how the three clouds divide your space. Assume an organization holds 10.0.0.0/16. AWS gets a slice for its VPCs, Azure gets another for its virtual networks, GCP gets a third, and the on premises network keeps whatever is left, and each slice gets tracked by a different tool with different rules. AWS IPAM will happily report that its slice is healthy and conflict free, Azure IPAM will say the same about its own, and nobody’s tool can tell you that the same /24 is now active on both sides of a future peering link.

The deeper problem is that provider IPAMs are designed to answer provider questions: how much of this region pool is used, which account holds this CIDR, when was this VPC allocated. Those are useful questions, but they are all scoped to one cloud. As soon as your architecture spans two clouds, or one cloud plus a data center, you need answers that cut across scopes, and the moment you need a cross cloud answer you are back to copying numbers out of three consoles. That is the point where per provider IPAM quietly stops being IPAM and becomes three separate spreadsheets with better APIs. For teams in that situation, a multi-site network view that includes every environment is what actually prevents the classic overlap incidents.

What AWS VPC IPAM Actually Gives You

AWS built the most complete native IPAM of the three, and it shows. VPC IP Address Manager runs as a top level IPAM resource with two built-in scopes, one for private space and one for public, and under those scopes you build pools: regional pools, business unit pools, pools for specific environments. CIDRs flow down the tree, and when you create a VPC you allocate from a pool rather than typing a range by hand. IPAM automatically discovers VPCs across the accounts in your organization, so existing infrastructure shows up without an opt in step, and it records the history of every allocation, which turns “who owns this range” from a conversation into a query.

The cost model is where AWS earns its reputation for pragmatism. The free tier covers a single account and single region, and it includes BYOIP, public IP insights, and IPv6 handling, but not private IPv4 management or pool sharing. The advanced tier unlocks private IPv4 management, cross account and cross region operation through AWS Organizations, and allocation history, and it bills per active IP at a rate that works out to roughly $0.20 per IP per month. AWS’s own example of 7,000 active IPs for a month lands near $1,360, and for a large organization that number is trivial next to the labor it replaces. The tiered model is still worth understanding before you roll it out, because the free tier silently stops covering you the moment you leave a single account.

Azure IPAM: Centralized, With Caveats

Azure’s answer arrived later and is younger. IPAM in Azure runs inside Azure Virtual Network Manager, and it centers on a pool hierarchy: a root pool, then child pools nested up to seven levels deep, with static reservations you can place for on premises ranges so the allocator never hands them out. When you create a virtual network you attach it to a pool and specify how many addresses you need, and IPAM assigns a non overlapping block, with IPv4 and IPv6 both supported. You can even pair it with Azure Policy to deny any virtual network that lacks an IPAM allocation, which is the most direct enforcement mechanism of the three clouds.

The caveats matter. Azure IPAM does not discover existing virtual networks: anything created before IPAM exists must be migrated in by hand, which for established subscriptions means a retrofit project rather than a flip of a switch. It manages private space only, it will not remove address space once a network is under IPAM management, and the price is steep: $0.005 per active IP per hour, about $3.60 per IP per month, roughly 18 times the AWS advanced tier. The billing is per active IP, so it scales with every network interface in your fleet rather than with the size of your address space. If you are evaluating it purely as a way to stop duplicate allocations in a few subscriptions, run the monthly number before you commit, because a serious deployment can cost more than a source of truth that also covers the rest of your infrastructure.

GCP: A Toolbox Instead of a Service

Google Cloud is the honest outlier: there is no GCP IPAM console, and Google’s own answer to the question is a set of building blocks. VPC networks are global, subnets are regional, and each subnet carries a primary range for VM addresses plus optional secondary ranges used for alias IPs, which is how GKE pods and services get their space. The internal ranges API, launched in 2024, lets you reserve blocks of internal address space and protect them from allocation, including ranges that belong to on premises or other clouds, so Terraform can allocate subnets from a known pool instead of guessing. Subnets can be expanded in place without downtime, and GKE Auto IPAM, still in preview, handles pod range allocation dynamically.

What GCP lacks is the thing the other two provide: a product that tracks what you planned versus what exists. Nothing in the console shows your whole address plan, checks a proposed range against every other environment, or keeps a history of who allocated what and why. In practice GCP teams end up with the allocation plan living in Terraform state, a wiki, or a spreadsheet, and the gap between those artifacts is where duplicate ranges quietly appear. GCP does not charge for IPAM, but the absence of a charge is not the same as free: you pay in engineering time spent reconciling ranges that a console in another cloud would track automatically. Reserving internal ranges is the right first step on GCP, but the cross environment picture still has to live somewhere else.

Where the Blind Spots Overlap

Put the three side by side and the shared gaps are easy to see. Each product sees only its own cloud: AWS IPAM has no idea what Azure allocated, Azure IPAM cannot see GCP secondary ranges, and nothing in any of the three knows about your on premises or colocation space except as a manually typed reservation. Overlap detection, the feature teams assume exists everywhere, actually runs only inside each provider’s own world, and only for resources that have opted in. The moment the same /24 exists in two clouds, every provider dashboard will report zero conflicts, right up until a peering link or site to site VPN fails to come up.

The other shared gap is scope of what counts as an address. Cloud IPAMs track the ranges they hand out, but a real fleet also has public addresses, BYOIP blocks, VPN tunnel endpoints, load balancer IPs, and on premises VLANs, and each of those lives in a different system with a different notion of “in use”. Utilization reports are per cloud and per pool, allocation history is per cloud, and nothing produces a single answer to the simplest question an engineer asks during an incident: which of my things is using this address, and what changed around it recently? Teams that try to hold all of it in one cloud’s IPAM eventually discover they are maintaining the same spreadsheet they replaced, just with a steeper learning curve. A neutral IPAM layer that accepts ranges from every source is what closes that gap.

One Address Ledger Across Every Cloud

Obelinf approaches this as a single neutral ledger for address space from every source: AWS subnets, Azure virtual networks, GCP ranges, and on premises VLANs all sit in the same hierarchy, under the same sites, with the same IP address management rules applied to all of them. When an engineer proposes a new range, conflict detection runs across the entire organization rather than inside one provider, so the duplicate that would have surfaced during a peering outage is caught at planning time. Every subnet and IP carries its utilization, its VLAN and VRF context, and its links to the devices and interfaces that use it, and every allocation or change lands in an audit trail that spans all three clouds.

The view you get is the one the provider tools cannot produce: a network topology that draws your clouds and on premises sites together, device inventory tied to addresses, and utilization across everything, queried from one place instead of three consoles. Because it is a source of truth rather than a discovery tool, it also documents the things clouds never see: reserved blocks, planned ranges, and the on premises space that carries traffic between environments. For teams whose address space spans AWS, Azure, and GCP, the practical choice is not which cloud’s IPAM to adopt. It is whether to keep maintaining three partial ledgers or adopt one that holds the whole picture.