Back to Insights
Platform January 2026

Why IPAM must come before IaC: lessons from multi-cloud network conflicts

IP address conflicts in cloud networks are more common than most organisations realise. When they occur in production, they cause outages. Here is why IPAM must be the first step in any cloud deployment workflow.

SV
Subbareddy Vundela
Senior DevOps Cloud Architect

IP address conflicts in cloud environments are, in theory, easy to avoid. In practice, they occur with surprising frequency in organisations managing cloud estates across multiple accounts, multiple cloud providers and multiple teams.

The mechanism

Team A deploys a VNet with CIDR 10.1.0.0/16 in Azure Subscription 1. Team B, working independently in AWS Account 2, deploys a VPC with CIDR 10.1.0.0/16. Neither team is aware of the other's allocation. Both deployments succeed because each cloud provider validates the CIDR range only within its own account — not across accounts or cloud providers.

Six months later, the organisation needs to peer these networks. The peering fails. The conflict is discovered. The resolution requires network redesign, resource redeployment and downtime. The engineering time cost is measured in weeks.

In regulated environments, the compliance implication is additional. An unplanned network outage caused by a configuration conflict may constitute an ICT incident under DORA, requiring incident reporting. The root cause — lack of IPAM governance — becomes a finding in the post-incident review.

The conventional approach and why it fails

The conventional approach to IPAM is a spreadsheet. The network team maintains a list of allocated CIDR ranges. Engineers are expected to consult the list before deploying. In practice, the spreadsheet is not maintained, engineers do not consult it and conflicts occur when networks that should have been peered eventually are.

How ZAP IPAM solves this structurally

ZAP IPAM solves this structurally, not procedurally. The engineer does not choose a CIDR range. ZAP assigns one. The engineer cannot choose a conflicting range, because ZAP does not give them the option.

Every VNet, subnet and VLAN across all connected cloud accounts — Azure, AWS and GCP — is registered in the ZAP IPAM registry. When a new landing zone is requested, ZAP IPAM scans the full registry and assigns a conflict-free CIDR range automatically. This is step one of the ZAP landing zone pipeline — before any Terraform is generated.

The multi-cloud dimension

Most IPAM tools operate within a single cloud provider or a single account. ZAP IPAM covers all connected cloud accounts across Azure, AWS and GCP simultaneously. The registry is unified. The conflict detection is comprehensive.

The organisations that have experienced IP address conflicts in production understand immediately why IPAM must come first. The organisations that have not experienced conflicts yet are the ones most at risk — because the conflicts are there, waiting for the network peering requirement that will expose them.


See ZAP live

Book a 30-minute session with the Zentej team. We show you ZAP live on our instance — landing zone, compliance scan, evidence generation, ZAP AI. No commitment.

Book a session
More insights
Next
Evidence packs in seconds: what it actually takes to generate compliance evidence on demand
Read next