Cloud Sandbox
All writing

IPAM: when address management becomes architecture

IP address management becomes an architectural concern once CIDR allocations span accounts, Regions, environments and network trust boundaries. Amazon VPC IPAM can encode allocation hierarchy, organisational ownership, compliance rules, overlap detection and capacity monitoring.

about 25 minutes min read

The first VPC receives:

10.64.0.0/16

I record it in a spreadsheet.

The second receives 10.65.0.0/16. Development, staging and production receive their own ranges. The spreadsheet still feels adequate.

Then bfstore, the fictional organisation used throughout this series, acquires:

  • several AWS accounts and Regions
  • multiple trust boundaries
  • shared services and observability
  • IPv6
  • Azure and Google Cloud implementations
  • temporary environments
  • future networks not yet designed

The spreadsheet grows columns for owner, account, Region, environment, status, route summary, intended use, actual use and lifecycle.

At some point, it stops being a list of addresses.

It becomes an informal architecture database maintained through coloured cells and collective optimism.

CIDR register
     │
     ├── Who owns this network?
     ├── Which routes may advertise it?
     ├── Can it connect to another network?
     ├── Does it overlap anything?
     ├── How much remains free?
     └── What happens when it is released?

Those are architectural questions.

Amazon VPC IP Address Manager, usually shortened to VPC IPAM, provides central planning, allocation, monitoring and history for public and private IP address space used by AWS resources. It can organise space into routing and security domains, allocate CIDRs according to business rules, monitor utilisation and compliance, detect overlaps and retain address history.

IPAM becomes architecture when address allocation stops being a local subnetting decision and starts determining the shape, ownership and future connectivity of the platform.

IPAM does not replace CIDR understanding.

It gives the arithmetic an organisational memory.

An address plan is a topology plan

Consider two VPCs:

bfstore-prod
10.64.0.0/16

bfstore-observability
10.80.0.0/16

The decision to allocate non-overlapping ranges creates future options.

The VPCs can later communicate through:

  • Transit Gateway
  • VPC peering
  • Cloud WAN
  • a VPN
  • another routed network

Now consider:

bfstore-prod
10.64.0.0/16

bfstore-observability
10.64.0.0/16

Each VPC works independently.

The overlap becomes painful when they need ordinary routed connectivity.

A route for:

10.64.0.0/16

cannot distinguish between two destinations occupying the same range.

The original allocation made an architectural decision long before anyone created the connection.

CIDR ALLOCATION
       │
       ▼
FUTURE ROUTING OPTIONS
       │
       ▼
CONNECTIVITY ARCHITECTURE

An address plan also influences:

  • route aggregation
  • firewall-policy scope
  • network observability
  • DNS design
  • incident investigation
  • migration effort
  • cross-cloud connectivity
  • acquisition or partner integration

Allocating a VPC CIDR is not merely finding an unused rectangle.

It is deciding where that network will live in the organisation’s routing universe.

IPAM manages blocks, not every interface address

The name IP Address Manager can create the impression that IPAM assigns every individual address to every interface.

That is not its main role.

VPC IPAM manages and monitors CIDR allocations and supported AWS resource address usage. It can allocate a CIDR from a pool to a VPC, track resource CIDRs and report utilisation, compliance and overlap. AWS distinguishes resources IPAM manages from resources it discovers and monitors.

The hierarchy is closer to:

ADDRESS SPACE

10.0.0.0/8
     │
     ▼
REGIONAL POOL

10.64.0.0/10
     │
     ▼
ENVIRONMENT POOL

10.80.0.0/12
     │
     ▼
VPC ALLOCATION

10.80.0.0/18
     │
     ▼
VPC SUBNETS

application
data
public entry

Inside a subnet, the VPC and consuming services handle individual interface addresses.

IPAM governs the blocks from which those subnets and networks are built.

This matters because expensive architectural mistakes usually occur before an individual address is selected.

The common failure is not:

The interface should have received .48
instead of .49.

It is:

Two networks that now need to connect
were allocated the same /16.

Scopes represent separate routing universes

When an IPAM is created, AWS creates:

  • one default private scope
  • one default public scope

A scope is IPAM’s highest-level container. Each scope represents the address space of one network. AWS permits additional private scopes, but only one public scope.

The important phrase is:

one network

A scope is not simply a folder called:

production

or:

Europe

Those divisions usually belong in pools.

An additional private scope is appropriate when genuinely disconnected networks intentionally reuse the same addresses.

PRIVATE SCOPE A

Corporate routed network
10.0.0.0/8


PRIVATE SCOPE B

Isolated training estate
10.0.0.0/8

The overlap is acceptable only while the networks remain disconnected.

If they may later connect, separate scopes can hide a future problem rather than solve it.

Private resource CIDRs discovered by IPAM initially appear in the default private scope. Creating another private scope does not automatically move matching resources into it. VPC CIDRs must be deliberately moved into the intended private scope.

For bfstore, I would begin with one private scope covering the routed AWS estate.

Development, staging, production, network services, observability and shared services would use different pools inside that scope.

They are different control environments.

They are not separate universes.

A new scope should represent deliberate address reuse across disconnected networks, not discomfort with seeing several environments in one hierarchy.

Pools encode the architecture

Inside a scope, IPAM uses pools.

A pool contains one or more CIDRs and may contain child pools. CIDRs can be allocated from a pool to a child pool, a supported AWS resource or a manual reservation.

A useful hierarchy might be:

BFSTORE PRIVATE SCOPE
│
└── bfstore-aws-private
    │
    └── eu-west-2
        │
        ├── workloads-production
        ├── workloads-non-production
        ├── network-services
        ├── shared-services
        ├── observability
        ├── backup-and-recovery
        ├── sandbox
        └── reserved

I would not create a pool for every account automatically.

The pool hierarchy should follow allocation, routing and security policy.

Several accounts may consume one pool when they share:

  • Region
  • environment treatment
  • VPC size rules
  • route summary
  • lifecycle expectations

The account boundary remains visible through:

  • RAM sharing
  • resource ownership
  • tags
  • allocation records

A pool level should answer a useful question.

Region

Which Region may consume the address space?

Routing domain

Should networks beneath this pool be summarised or advertised together?

Environment

Does production need different allocation rules from non-production?

Workload type

Do network services and application VPCs require different block sizes?

Lifecycle

Is the space allocatable now or deliberately reserved?

Each additional hierarchy level spends operational complexity.

Its purpose should be visible in allocation rules, ownership, routing, sharing or reporting.

Provisioning and allocation are different actions

AWS IPAM uses two terms that are easy to blur.

Provision

A CIDR is added to a pool.

Top-level pool

provision:
    10.64.0.0/10

The pool now owns address space from which allocations may be made.

Allocate

Part of that space is assigned to:

  • a child pool
  • a VPC
  • another supported resource
  • a manual reservation
Production pool

allocate:
    10.80.0.0/18

to:
    bfstore-prod VPC

The distinction produces a useful lifecycle:

SOURCE SPACE
     │
     ▼
PROVISION TO POOL
     │
     ▼
AVAILABLE CAPACITY
     │
     ▼
ALLOCATE TO CHILD OR RESOURCE
     │
     ▼
ACTIVE OWNERSHIP
     │
     ▼
RELEASE
     │
     ▼
RECONCILIATION PERIOD
     │
     ▼
AVAILABLE AGAIN

A released CIDR is not necessarily reusable immediately. AWS documents that reuse can take a few minutes in Advanced Tier and up to 48 hours in Free Tier.

A spreadsheet often records only:

10.80.0.0/18 = production

IPAM can distinguish whether the block is:

  • available
  • reserved manually
  • delegated to a child pool
  • assigned to a VPC
  • released
  • discovered outside the intended process

That state is part of the allocation’s lifecycle.

Region and locale enforce where space may be consumed

An IPAM has a home Region and one or more operating Regions.

Operating Regions are the AWS Regions in which IPAM discovers and manages resources. IPAM only discovers resources in Regions configured as operating Regions.

Pools may also have a locale.

The locale is the Region in which a pool’s CIDRs are available for resource allocation. A VPC can receive an allocation only from a pool whose locale matches the VPC’s Region. Once selected, the locale cannot be changed.

This suggests:

GLOBAL PRIVATE PARENT
       │
       ├── eu-west-2 regional pool
       ├── eu-central-1 regional pool
       └── future regional pool

The top-level parent expresses organisational ownership.

Regional pools express allocation locality.

This prevents a workload in one Region from consuming space intended for another.

Locale does not create route aggregation by itself. Combined with aligned Regional pool boundaries, it helps preserve the conditions required for meaningful route summaries.

The locale is therefore more than console metadata.

It helps convert the address hierarchy into a regional allocation contract.

Pool allocation rules enforce the pool contract

An IPAM pool may define allocation rules covering:

  • automatic import
  • minimum netmask length
  • default netmask length
  • maximum netmask length
  • required resource tags
  • required locale

A production pool might express:

pool:
  name: bfstore-production-vpcs
  locale: eu-west-2

allocation_rules:
  minimum_netmask_length: 16
  default_netmask_length: 18
  maximum_netmask_length: 20

required_tags:
  Environment: production
  ManagedBy: opentofu
  NetworkOwner: bfstore-platform

The AWS terminology can appear counterintuitive.

For IPv4:

/16 is the largest permitted allocation.

/20 is the smallest permitted allocation.

A permitted range from /16 through /20 allows:

/16
/17
/18
/19
/20

but not /15 or /21.

Required tags answer:

Which class of resource
belongs in this pool?

Netmask rules answer:

How large or small may
an allocation be?

These rules do not replace IAM.

IAM decides which principal may call the API.

Pool rules decide whether the requested allocation fits the pool’s contract.

These pool allocation rules should not be confused with IPAM Policies, a separate AWS feature for directing public IPv4 allocations from IPAM pools to supported services such as Elastic IP addresses, Application Load Balancers, RDS and Regional NAT gateways.

Central ownership and delegated consumption

In an AWS organisation, IPAM can be integrated with AWS Organizations and administered from a delegated member account. That account operates IPAM, monitors organisation-wide address use and shares pools through AWS Resource Access Manager.

For bfstore, the natural placement is:

AWS MANAGEMENT ACCOUNT
        │
        ▼
DELEGATE IPAM ADMINISTRATION
        │
        ▼
BFSTORE-NETWORK ACCOUNT
        │
        ├── IPAM
        ├── pools
        ├── allocation rules
        ├── RAM shares
        └── monitoring

The management account establishes trusted access and registers the delegated administrator. The network account owns the address hierarchy.

A workload account can still own its VPC.

BFSTORE-NETWORK

owns:
    production VPC pool
         │
         ▼
RAM SHARE

principal:
    Production OU
         │
         ▼
BFSTORE-PROD

creates:
    VPC with pool-allocated CIDR

The network function retains non-overlap, pool policy and capacity visibility. Workload teams retain VPC, subnet, route-table and workload lifecycle.

Central ownership does not require central construction of every network.

Allocations should enter through IaC

A central IPAM does not mean engineers should open the console and choose whichever free CIDR looks friendly.

The VPC definition should request an allocation from the correct pool.

Conceptually:

vpc:
  name: bfstore-prod
  account: bfstore-prod
  region: eu-west-2

address_request:
  source_pool: workloads-production
  prefix: 18

required_tags:
  Environment: production
  ManagedBy: opentofu

The workflow should:

  1. identify the correct shared pool
  2. request a permitted prefix
  3. create the VPC using the allocation
  4. record the resulting CIDR in outputs and evidence
  5. divide the VPC range into reviewed subnet allocations
  6. release the allocation when the VPC is legitimately retired

The official route should be:

VPC creation
     │
     ▼
approved IPAM pool
     │
     ▼
contract-compliant CIDR
     │
     ▼
VPC

not:

VPC creation
     │
     ▼
engineer invents CIDR
     │
     ▼
IPAM notices later

Discovery is useful.

Controlled allocation is better.

Managed, unmanaged and ignored are different states

IPAM can discover resources that were not allocated through an IPAM pool.

Managed

The resource’s CIDR was allocated from an IPAM pool.

IPAM evaluates it for:

  • pool-rule compliance
  • overlap
  • utilisation
  • ownership

Unmanaged

IPAM discovered the resource, but its CIDR was not allocated from an IPAM pool.

The resource remains visible and is checked for overlap, but it sits outside the managed-allocation process.

Ignored

The resource has been deliberately exempted from monitoring and compliance evaluation.

Ignored is not a harmless dashboard filter.

When an active resource CIDR allocated from a pool is marked ignored, IPAM returns the allocation to the pool even though the resource may continue using the range. Unless another allocation record protects that space, it may later be selected for a second resource.

ACTIVE VPC
uses:
    10.80.0.0/18

IPAM state:
    ignored

pool view:
    10.80.0.0/18 may become available

Ignored resources are also excluded from overlap and allocation-rule evaluation.

An existing organisation rarely begins with every CIDR neatly allocated from a central hierarchy. Adoption can therefore be:

DISCOVER
    │
    ▼
CLASSIFY
    │
    ├── import and manage
    ├── redesign and migrate
    ├── temporarily monitor
    └── deliberately ignore

Ignoring should remain exceptional.

A CIDR excluded from checking has not stopped overlapping.

The dashboard has simply been asked not to mention it.

Ownership, overlap and route aggregation

Overlap is not merely a compliance failure. Its consequence depends on the networks.

  • Two isolated experiments may coexist while disconnected.
  • Two VPCs joined through Transit Gateway cannot route the same destination deterministically.
  • AWS and Azure connected through VPN inherit the same ambiguity.
  • An acquired partner network may force renumbering, translation or selective connectivity.

IPAM cannot prevent an external organisation from choosing the same private range. It can ensure bfstore knows its own estate and allocates deliberately.

Route aggregation should also shape the hierarchy. Suppose production VPCs in eu-west-2 are allocated beneath 10.80.0.0/12:

EU-WEST-2

10.64.0.0/10
│
├── 10.64.0.0/12    non-production
├── 10.80.0.0/12    production
├── 10.96.0.0/13    network and shared services
├── 10.104.0.0/13   reserved near-term
└── 10.112.0.0/12   reserved long-term

These child blocks completely partition the parent /10.

Central networks may be able to use meaningful summaries rather than learning every VPC separately. IPAM does not guarantee that every parent pool should be advertised. It preserves the option by keeping related allocations aligned and contiguous.

IPAM

Who owns each destination range?
        │
        ▼
ROUTING

Where should packets go?
        │
        ▼
SECURITY

Should the traffic be accepted?

IPAM does not create attachments, routes or security policy. It provides trustworthy destination ownership for those controls.

Capacity has quantity, shape and utilisation

An IPAM dashboard can show several kinds of utilisation.

Pool allocation

How much space has been assigned to child pools or resources?

VPC allocation

How much of the VPC CIDR is covered by subnet CIDRs?

Subnet address use

How many IPv4 addresses inside a subnet are active?

AWS publishes resource-utilisation metrics to CloudWatch. VpcIPUsage describes the portion of a VPC range covered by subnet CIDRs. SubnetIPUsage measures active IPv4 addresses against a subnet’s IPv4 space.

POOL CAPACITY

Can we allocate another VPC?


VPC CIDR CAPACITY

Can we create another subnet?


SUBNET IPv4 UTILISATION

Can this workload scale?

Quantity alone is not enough.

Suppose a pool has 65,536 free addresses, the raw size of a /16, but they are fragmented across 16 separate /20 blocks. A request for one contiguous /16 still fails.

TOTAL FREE

65,536 addresses


LARGEST CONTIGUOUS BLOCK

4,096 addresses


REQUEST

one /16

Planning must consider total capacity, largest contiguous block, alignment, route-summary boundaries and reserved growth space.

Address efficiency is not filling every gap. It is retaining the right-shaped gaps for the networks the platform expects to build.

IPv6 changes the monitoring emphasis

IPv6 provides abundant individual addresses.

It does not eliminate prefix governance.

A VPC may receive an IPv6 allocation that is divided into /64 subnet prefixes.

The useful questions become:

  • which larger prefix owns the VPC allocation
  • which subnet identifier belongs to each Availability Zone
  • whether the ranges are public or private
  • which routes may advertise them
  • whether allocations can be summarised
  • which account and Region own them

VPC IPAM can manage and monitor public and private IPv6 space. AWS also supports provisioning Amazon-provided contiguous IPv6 CIDRs into pools for VPC allocation.

IPv4 IPAM often asks:

Do we have enough addresses?

IPv6 IPAM more often asks:

Do we have a coherent
delegation hierarchy?

IPAM can report VPC-level allocation for IPv4 and IPv6. Active-address utilisation inside an IPv6 subnet is not currently represented in the same way as IPv4 subnet use. IPv6 governance therefore centres more heavily on prefix allocation, containment, ownership and routing than on counting active positions inside a /64.

A vast address space without ownership is still unmanaged space.

It is merely unmanaged with excellent legroom.

VPC IPAM is not automatically a multi-cloud IPAM

The organisation may operate AWS, Azure and Google Cloud networks.

VPC IPAM does not natively discover Azure virtual networks or Google Cloud VPC networks. A manual allocation can reserve a CIDR representing an external network so AWS allocations do not reuse it. AWS documents this model for on-premises space; using it for other clouds requires an external process to keep the record accurate.

A multi-cloud design therefore needs one of three models:

  • provider-native IPAM systems synchronised through automation
  • one enterprise IPAM that delegates ranges to every cloud
  • VPC IPAM authoritative for AWS, with manual reservations for external ranges
ENTERPRISE ADDRESS AUTHORITY
          │
          ├── AWS VPC IPAM
          ├── Azure address management
          ├── Google Cloud address management
          └── on-premises networks

The important requirement is not that one product owns every record. It is that every allocation is checked against the same connected-network reality.

AWS also supports an Infoblox integration in which Infoblox acts as the external authority for private IPAM scopes. That is one enterprise option, not a requirement for sound multi-cloud governance.

The tier must match the operating model

Amazon VPC IPAM offers Free and Advanced tiers.

The Free Tier is intended for IP address management in a single account and Region and includes capabilities such as BYOIP, Amazon-provided contiguous IPv6 blocks, private IPv6 management and Public IP Insights.

Advanced Tier adds capabilities including:

  • private IPv4 management
  • sharing IPAM pools across AWS accounts
  • IP address history auditing
  • management across multiple accounts or Regions

The architecture proposed in this article uses:

  • a delegated network account
  • shared private IPv4 pools
  • organisation-wide private address governance
  • historical auditing

That model requires Advanced Tier.

A single-account experiment using only Free Tier capabilities may begin without it. The multi-account private IPv4 design described here cannot.

Advanced Tier is charged per active IP address or prefix attachment managed by IPAM. The cost decision should therefore consider:

  • active-address volume
  • number of accounts and Regions
  • history requirements
  • public and private management needs
  • cost of manual governance
  • cost of overlap or renumbering incidents

The correct question is not:

Can IPAM be free?

It is:

Which operating model
does the architecture require,
and what does that control cost?

FinOps applies to control planes too.

Subnet planning remains beneath the VPC allocation

Once IPAM allocates a VPC CIDR, the VPC still needs a subnet plan.

Suppose production receives:

10.80.0.0/18

The design may divide it across:

  • three Availability Zones
  • application subnets
  • data subnets
  • public-entry subnets
  • network-service subnets
  • reserved space
VPC ALLOCATION

10.80.0.0/18
      │
      ├── AZ A
      │   ├── application
      │   ├── data
      │   └── public entry
      │
      ├── AZ B
      │   ├── application
      │   ├── data
      │   └── public entry
      │
      ├── AZ C
      │   ├── application
      │   ├── data
      │   └── public entry
      │
      └── reserved growth

IPAM tells me the parent allocation is legitimate.

It does not decide whether an application subnet should be /20 or /22.

That decision still depends on:

  • EKS Pod-address consumption
  • load-balancer interfaces
  • interface endpoints
  • database failover
  • deployment surge
  • provider-reserved addresses
  • future expansion

IPAM governs the parent.

Subnet capacity planning governs the children.

History and lifecycle turn addresses into evidence

An address allocation should have a lifecycle comparable to other infrastructure.

Request

Why is a network needed?

Select pool

Which routing and security domain owns it?

Allocate

Which prefix was assigned?

Build

Which VPC or resource consumed it?

Monitor

Is it compliant, overlapping or approaching exhaustion?

Change

Does it need another CIDR or a larger successor allocation?

Retire

Have resources, routes and dependencies been removed?

Release

Has IPAM returned the space to the pool after its reconciliation period?

Reuse

Is the block safe to allocate again?

A bfstore evidence record might contain:

allocation:
  cidr: 10.80.0.0/18
  resource: vpc-0123456789abcdef0
  account: bfstore-prod
  region: eu-west-2
  pool: workloads-production
  allocated_by: infrastructure-pipeline
  change_reference: NET-0042
  created_at: 2026-05-19
  lifecycle: active

IPAM retains address monitoring history for up to three years. Historical auditing is an Advanced Tier capability.

That history helps when:

  • an old firewall log contains an unfamiliar address
  • a deleted resource remains referenced elsewhere
  • a CIDR appears safe to reuse
  • an incident crosses several network generations

An IP address without time context can identify several resources across its lifetime.

History turns it back into evidence.

Adoption should begin with observation

The first implementation step should not be strict automatic allocation.

Phase 1: Discover

Integrate IPAM with the organisation.

Select the operating Regions.

Allow it to inventory existing AWS VPCs and subnets.

Phase 2: Reconcile

Classify discovered ranges as:

  • correct and retainable
  • overlapping
  • poorly sized
  • temporary
  • scheduled for migration
  • intentionally isolated

Phase 3: Design the hierarchy

Create:

  • scopes
  • top-level pools
  • Regional pools
  • environment and platform pools
  • reserved space
  • external-network reservations where required

Phase 4: Import carefully

Bring suitable existing VPC allocations under the correct pools.

Move resources into additional private scopes only when the networks are genuinely separate.

Record noncompliance rather than hiding it.

Phase 5: Enforce new allocation

Require new VPCs to receive CIDRs from shared pools through IaC.

Phase 6: Monitor

Create alarms and reviews for:

  • pool exhaustion
  • VPC allocation pressure
  • subnet IPv4 utilisation
  • noncompliant resources
  • overlap
  • unexpectedly ignored resources

Phase 7: Improve

Use utilisation and history to:

  • reclaim abandoned space
  • resize future allocations
  • preserve larger contiguous blocks
  • refine routing summaries
DISCOVER
   │
   ▼
UNDERSTAND
   │
   ▼
MODEL
   │
   ▼
ALLOCATE
   │
   ▼
ENFORCE
   │
   ▼
MONITOR

Beginning with enforcement before understanding the existing estate risks encoding old accidents as new policy.

Observation should arrive first.

The questions that matter

Area Core decision
Topology Which ranges belong to one routable network, and which belong to deliberately disconnected networks?
Governance Which account owns the hierarchy, and which accounts or OUs may consume each pool?
Allocation Which Regions, tags and netmask lengths define a valid request?
Capacity Is free space sufficient, contiguous, aligned and useful for future summaries?
Multi-cloud How are Azure, Google Cloud and on-premises allocations represented and reconciled?
Lifecycle How are allocations discovered, audited, retired and proven safe for reuse?
IPv6 How do IPv6 prefixes follow the same ownership, routing and lifecycle hierarchy?
Evidence Can an address be tied to the resource that used it at the time of an event?

These questions make IPAM part of network design rather than an inventory tool added afterwards.

The mental model I am keeping

My earlier model was:

IPAM

a central spreadsheet
with a cloud console

The stronger model is:

ADDRESS STRATEGY
       │
       ▼
      IPAM
       │
       ├── scopes: routing universes
       ├── pools: architectural hierarchy
       ├── rules: allocation contract
       ├── allocations: resource ownership
       ├── monitoring: capacity and compliance
       └── history: evidence over time

A scope asks which ranges belong to one routing universe.

A pool asks which architectural domain owns part of the space.

A locale limits the Region in which a pool may be consumed.

Allocation rules define which resource tags and prefix sizes fit the contract.

RAM shares define which accounts may consume centrally owned space.

Allocations identify the current owner of an exact CIDR.

Monitoring reveals overlap, capacity pressure and fragmentation.

History identifies which resource used an address at the time of an event.

The multi-cloud authority prevents one provider from allocating space already used elsewhere.

IPAM begins as address management.

It becomes architecture when its hierarchy describes:

  • Regions
  • environments
  • trust boundaries
  • ownership
  • routing summaries
  • growth
  • recovery
  • multi-cloud integration

The important IPAM object is not the individual address. It is the decision that a particular part of the network may consume a particular prefix from a particular architectural domain.

A spreadsheet can record the result.

A mature IPAM design can govern the process that creates it.

The CIDR still contains bits.

Now it also contains ownership, policy, route intent and a small reservation for tomorrow.

References and further reading