Enterprise IP Address Management (IPAM) — Reference Architecture

1. Purpose and scope

This document defines a single, hierarchical IPv4 addressing scheme and the governance model that keeps it accurate across multiple subsidiaries, three public cloud providers, and on-premises datacenters. Its primary goals are to prevent CIDR overlap (the failure that silently breaks VPC peering, VPNs, interconnects, and post-acquisition merges), to enable clean route summarization at every boundary, and to make IP allocation an enforced, automated process rather than a spreadsheet maintained after the fact.

It covers the addressing plan, per-provider considerations, the interconnect topology at a high level, and the tooling and workflow that act as the system of record.

2. Design principles

The scheme is built on a small number of rules that, applied consistently, remove almost all addressing conflicts before they happen.

• Allocate strictly top-down. Space is delegated from supernet → subsidiary → provider → region → environment → VPC → subnet. No team selects its own CIDR; every block is handed down from the tier above.
• Each tier lands on a clean bit boundary. Every level is a 2-bit subdivision of its parent, so any allocation can be summarized as a single prefix at any tier (all of US-AWS is exactly 10.0.0.0/14). This keeps transit and firewall route tables small and human-readable.
• Leave deliberate headroom. Never pack a tier to 100%. Reserve blocks at every level for growth, new regions, and acquisitions.
• Reserve for M&A up front. Mergers and acquisitions are where overlap pain almost always appears. A large unused block is set aside so an acquired entity can be assigned clean space immediately.
• Avoid provider default and special ranges. Never reuse the ranges clouds hand out by default, and keep CGNAT space (100.64.0.0/10) and container defaults (172.17.0.0/16) out of the routable plan. See §8.
• One source of truth, enforced by automation. A central IPAM is authoritative; infrastructure-as-code requests space from it at creation time, and scheduled reconciliation catches anything provisioned out of band. See §10.

3. Addressing hierarchy (overview)

Seven tiers run from the enterprise supernet down to the individual subnet. Each prefix length below is fixed by convention so the plan stays predictable.

The full tree, with the US subsidiary and its AWS branch expanded to illustrate the pattern that all subsidiaries and providers follow:

10.0.0.0/8                          Enterprise supernet
│
├─ 10.0.0.0/12                      US subsidiary
│   ├─ 10.0.0.0/14                  AWS
│   │   ├─ 10.0.0.0/16              us-east-1
│   │   │   ├─ 10.0.0.0/18          prod
│   │   │   │   ├─ 10.0.0.0/20      VPC-A (prod)
│   │   │   │   │   ├─ 10.0.0.0/24  subnet · public · AZ-a
│   │   │   │   │   ├─ 10.0.1.0/24  subnet · public · AZ-b
│   │   │   │   │   └─ …            (up to 16 × /24 per VPC)
│   │   │   │   └─ 10.0.16.0/20     VPC-B (prod)
│   │   │   ├─ 10.0.64.0/18         staging
│   │   │   ├─ 10.0.128.0/18        dev
│   │   │   └─ 10.0.192.0/18        shared / sandbox
│   │   ├─ 10.1.0.0/16              us-west-2
│   │   ├─ 10.2.0.0/16              DR region
│   │   └─ 10.3.0.0/16              reserved
│   ├─ 10.4.0.0/14                  GCP
│   ├─ 10.8.0.0/14                  Azure
│   └─ 10.12.0.0/14                 On-prem datacenter
│
├─ 10.16.0.0/12                     Japan subsidiary   (mirrors US)
├─ 10.32.0.0/12                     UK subsidiary      (mirrors US)
├─ 10.48.0.0/12 … 10.224.0.0/12     Reserved — M&A / future subsidiaries (12 × /12)
└─ 10.240.0.0/12                    Shared services / transit / management

4. Tier 1 — Subsidiary allocation

The /8 supernet divides into sixteen /12 blocks. Three are assigned to current subsidiaries, twelve are held in reserve, and one is dedicated to shared transit and management.

Each subsidiary is treated as its own routing domain. Routes are summarized at the /12 boundary between subsidiaries, so internal renumbering inside one subsidiary never ripples outward.

5. Tier 2 — Per-provider allocation

Each subsidiary /12 divides into four /14 blocks — one per cloud provider plus on-premises. The full matrix:

A /14 provides 262,144 addresses per provider per subsidiary — enough for four regions of 65,536 addresses each, with each region further split by environment.

6. Tier 3+ — Provider drill-down

Inside any provider /14, the same 2-bit subdivision continues. The worked example below is US-AWS (10.0.0.0/14); every other provider block follows the identical structure within its own range.

Tier 3 — Regions (/16)

Tier 4 — Environments (/18), within us-east-1

Tier 5 — VPCs / VNets (/20), within prod

Each environment /18 holds up to four /20 VPCs (4,096 addresses each): for example 10.0.0.0/20, 10.0.16.0/20, 10.0.32.0/20, 10.0.48.0/20.

Tier 6 — Subnets (/24)

Each /20 VPC holds up to sixteen /24 subnets (256 addresses each), typically allocated one or more per tier per availability zone. A representative layout inside VPC 10.0.0.0/20:

Note on usable hosts: clouds reserve addresses per subnet — AWS and Azure reserve 5, GCP reserves 4 — so a /24 yields ~251–252 assignable addresses. Size subnets with this in mind.

7. Reserved and shared-services blocks

Two categories of space are intentionally never used for ordinary subsidiary workloads:

• 10.48.0.0/12 – 10.224.0.0/12 — twelve free /12 blocks reserved for future subsidiaries and acquisitions. When an entity is acquired, it is assigned the next free /12 and either renumbered or NAT'd off any overlapping legacy ranges before interconnect.
• 10.240.0.0/12 — shared services, transit, and management. This hosts the transit/inspection VPCs, VPN and interconnect endpoints, shared DNS/AD, and management tooling. Keeping it in its own /12 guarantees the connectivity layer never collides with workload space in any subsidiary.

8. Cloud-provider-specific considerations

The hierarchy applies uniformly, but each platform has quirks that must be respected:

• AWS — A VPC is regional. Subnets reserve 5 addresses each. Use a dedicated secondary range from 100.64.0.0/10 (CGNAT) for EKS pod networking and transit overlays rather than routable RFC 1918 space. Avoid the default-VPC range 172.31.0.0/16.
• Azure — A VNet is regional. Subnets reserve 5 addresses each. Several addresses are platform-reserved (e.g. 168.63.129.16, link-local 169.254.0.0/16); do not plan around them.
• GCP — A VPC is global while subnets are regional, so the per-region /16 applies to subnets even though the VPC spans regions. Subnets reserve 4 addresses each. Allocate GKE pod/service alias ranges from a dedicated secondary range (carved from the provider /14 or from 100.64.0.0/10), not the primary subnet range.
• All platforms — Avoid 172.17.0.0/16 (Docker default bridge) and broad use of 192.168.0.0/16. Never let 100.64.0.0/10 enter the routable plan; reserve it exclusively for container/overlay use.

9. Connectivity architecture

The objective is to interconnect three clouds, three subsidiaries, and on-prem without re-creating overlap or building an unmanageable mesh.

• Regional hub per cloud. Each cloud uses its native hub construct as the regional aggregation point: AWS Transit Gateway, Azure Virtual WAN hub, GCP Network Connectivity Center. Spokes (VPCs/VNets) attach to the regional hub rather than peering directly with one another.
• Global backbone. Cross-cloud and cross-subsidiary traffic rides a backbone built on a colocation fabric (e.g. Megaport, Equinix Fabric) or SD-WAN, interconnecting the regional hubs.
• On-prem attachment. Datacenters connect to each cloud via the dedicated private circuits: Direct Connect (AWS), ExpressRoute (Azure), Cloud Interconnect / Partner Interconnect (GCP).
• Routing domains and summarization. Each subsidiary is a distinct routing domain; advertise only the summarized /12 between subsidiaries. Within a subsidiary, summarize at the /14 provider boundary where possible. The clean hierarchy is what makes this summarization lossless.
• Centralized egress and inspection live in the shared-services /12, so security and NAT are addressed from space that cannot collide with any workload.

10. Governance, tooling, and allocation workflow

The plan is only as good as its enforcement. The model below makes allocation an automated, auditable process.

10.1 System of record

NetBox is the authoritative global source of truth. Model the full hierarchy as nested prefixes, with one tenant per subsidiary (US, Japan, UK) so ownership and delegation are explicit. Every prefix from /8 down to assigned /24s lives here, including the reserved and shared blocks.

10.2 Per-cloud IPAM, mirrored from the plan

Mirror the hierarchy into each cloud's native IPAM so allocation can be enforced at provisioning time. AWS VPC IP Address Manager pools map directly onto this tree:

IPAM (private scope)
└─ Pool: enterprise              10.0.0.0/8
   ├─ Pool: us-subsidiary        10.0.0.0/12
   │   ├─ Pool: us-aws           10.0.0.0/14
   │   │   ├─ Pool: us-aws-use1  10.0.0.0/16      → auto-allocates VPC CIDRs
   │   │   ├─ Pool: us-aws-usw2  10.1.0.0/16
   │   │   └─ …
   │   ├─ Pool: us-gcp           10.4.0.0/14      (planning / visibility)
   │   ├─ Pool: us-azure         10.8.0.0/14      (planning / visibility)
   │   └─ Pool: us-onprem        10.12.0.0/14     (planning / visibility)
   ├─ Pool: jp-subsidiary        10.16.0.0/12
   ├─ Pool: uk-subsidiary        10.32.0.0/12
   └─ Pool: shared-transit       10.240.0.0/12

Azure (IPAM via Azure Virtual Network Manager / pools) and GCP have equivalents. Each cloud's IPAM owns automated allocation within its own branch; the non-native branches are tracked for planning and visibility. All of it reconciles back to NetBox.

10.3 Infrastructure-as-code enforcement

Make Terraform pull the next free CIDR from IPAM at creation time rather than hardcoding ranges. Terraform integrates with both NetBox and AWS IPAM directly, so the act of allocating and the act of provisioning become one operation — the most reliable way to prevent overlap at scale.

10.4 Reconciliation and drift detection

Run scheduled discovery against each cloud's inventory APIs (AWS Config / VPC describe, Azure Resource Graph, GCP asset inventory) plus on-prem sources, then diff actual state against the plan in NetBox. Drift is inevitable; the goal is to catch and flag it, not prevent every manual change.

10.5 Allocation rules

1. All space is delegated top-down. No team self-selects a CIDR.
2. Request a block from IPAM/NetBox before creating any VPC, VNet, or subnet.
3. Honor the minimum block size per tier and leave growth headroom — do not pack a tier.
4. Never use cloud default ranges, container defaults, or 100.64.0.0/10 for routable space.
5. Reconcile quarterly; reclaim idle or abandoned blocks back to the parent pool.
6. M&A: assign the acquired entity a free /12; renumber or NAT overlaps before any interconnect.

11. Naming and tagging conventions

Use a consistent identifier across NetBox, cloud resources, and IaC so a block's place in the hierarchy is readable at a glance:

{subsidiary}-{provider}-{region}-{env}-{tier}
example: us-aws-use1-prod-app

Tag every cloud network resource with at least: subsidiary, provider, region, environment, owner, and the source ipam-pool-id. This makes reconciliation and reclamation deterministic.

Appendix A — Quick-reference: subsidiary × provider matrix

Appendix B — Prefix size cheat sheet