Amazon VPC IPAM: Hierarchical CIDR Planning, Allocation, and BYOIP at Scale

The most expensive mistake in multi-account networking is not a misconfigured route table; it is two VPCs that both own 10.0.0.0/16. You cannot renumber a live VPC, you cannot route overlapping prefixes through a Transit Gateway, and by the time the overlap surfaces you have a spreadsheet, a Slack channel, and a quarterly meeting where humans manually hand out CIDR blocks. Amazon VPC IP Address Manager (IPAM) replaces all of that with a hierarchy of pools, automated allocation, and continuous overlap detection across every account in the organization. This is how to design the hierarchy, delegate it, automate allocation, monitor exhaustion, and bring your own public IP space — the way a platform team should, before anyone provisions a VPC.

Address allocation by spreadsheet fails for the same reason manual IAM fails: it does not scale and it cannot be enforced. A team picks 10.20.0.0/16 because it “looked free,” and six months later a Transit Gateway attachment is rejected or a Direct Connect route is black-holed because someone else picked the same block in another account. The longest-prefix-match router underneath TGW and VPC peering simply cannot represent two identical prefixes pointing at different destinations. IPAM is the single source of truth that issues address space rather than recording it after the fact, refuses to issue a conflict, and watches every CIDR it can see for overlap and exhaustion.

By the end of this article you will be able to design a top-down pool tree, delegate IPAM to a networking account, bolt allocation guardrails onto leaf pools, share them through AWS RAM so workload accounts self-serve, alarm on utilization before a prod VPC create fails, and bring your own public IPv4 space and ASN onto AWS without ever announcing the same prefix from two origins. Because IPAM is a system you operate, not a feature you toggle, the failure modes, limits, settings and the diagnostic playbook are all laid out as scannable tables — read the prose once, then keep the tables open when you are mid-migration.

What problem this solves

In a single account with one VPC, you can pick a CIDR by hand and never think about it again. The pain begins at organizational scale: dozens or hundreds of accounts, multiple Regions, mergers that drag in pre-existing 10.x estates, and a Transit Gateway or Direct Connect that demands every routable prefix be globally unique. The spreadsheet that “tracks” allocations is always slightly wrong, always behind, and can never prevent the next collision — it only records it after someone has already shipped a colliding VPC.

What breaks without address governance is concrete and expensive. A Transit Gateway route table cannot hold the same prefix twice, so the second VPC advertising 10.10.0.0/16 is silently unreachable across the shared backbone. A Direct Connect or Site-to-Site VPN route to on-prem 10.0.0.0/8 black-holes any AWS VPC that overlaps it. VPC peering between two 10.0.0.0/16 VPCs is simply rejected. And the cruelest part: you usually cannot renumber the offending VPC, because it is live, regulated, or load-bearing, so the fix is a multi-sprint migration rather than a config change.

Who hits this: any platform or network team running more than a handful of accounts, anyone standing up a hub-and-spoke Transit Gateway, anyone integrating an acquired company’s address space, and anyone who must advertise their own public IP range (for IP allow-lists, reputation, or a lift-and-shift that hard-codes IPs). IPAM’s first-day value is rarely the allocation — it is the discovery of the overlap nobody could previously see, then the guarantee that no new overlap can ever be created. To frame the whole field before the deep dive, here is every problem class IPAM addresses, what fails without it, and the IPAM mechanism that fixes it:

Learning objectives

By the end of this article you can:

• Explain the IPAM → scope → pool → allocation hierarchy and why a child pool’s source_ipam_pool_id and locale together decide what it can allocate to.
• Choose between the Free Tier and Advanced Tier and state exactly which capabilities (cross-account/cross-Region pools, org-wide monitoring, BYOIP/BYOASN, public IP insights) require Advanced.
• Design a top-down pool tree — locale-free top pool, locale-pinned Regional pools, per-environment/OU leaf pools — and provision CIDRs into each layer with the right netmask.
• Attach allocation guardrails (allocation_default/min/max_netmask_length, allocation_resource_tags) so a pool refuses non-compliant requests, and prove the rejection.
• Delegate IPAM to a networking account and share leaf pools to accounts or OUs via AWS RAM (the pool, not the IPAM).
• Automate VPC CIDR allocation from a shared pool, reserve space with explicit allocations, and reclaim addresses bottom-up respecting deletion-protection semantics.
• Monitor utilization, overlap and compliance via AWS/IPAM CloudWatch metrics and the resource-CIDR inventory, and alarm before exhaustion.
• Bring your own public IPv4 space (BYOIP) and ASN (BYOASN) onto AWS with a valid ROA, and control advertisement so a prefix is never announced from two origins.

Prerequisites & where this fits

You should already understand VPC fundamentals — that a VPC owns one or more CIDR blocks, that subnets carve host space out of those blocks, and that a route table forwards by longest-prefix match so two identical prefixes cannot coexist in one table. Comfort with aws CLI in CloudShell, reading JSON output, and Terraform/CloudFormation basics is assumed; every operation below ships both an aws snippet and an IaC snippet. Familiarity with AWS Organizations, delegated administrator accounts, and AWS RAM (Resource Access Manager) sharing makes the delegation section land faster.

This sits at the foundation of multi-account networking, upstream of almost everything else you build. If VPC networking fundamentals and the VPC deep dive on subnets, routing, IGW, NAT and endpoints are the “what is a VPC” layer, IPAM is the “who is allowed to own which addresses” layer that must exist before you connect anything. It is the prerequisite for a clean Transit Gateway multi-account architecture and for resilient Direct Connect + Transit Gateway, both of which break the instant two prefixes collide. It depends on the account structure from Control Tower landing zones and is governed by Organizations SCPs and delegated admin.

A quick map of who owns what during an IPAM rollout, so you call the right person fast:

Core concepts

Five mental models make every later operation obvious.

A spreadsheet records; IPAM issues. This is the entire shift. A spreadsheet records allocations after the fact and can never refuse a conflict; IPAM issues them and refuses to issue a conflict within a scope. Every VPC stops declaring a CIDR and starts drawing one from a pool, so uniqueness is guaranteed at creation, ownership is recorded centrally, and overlap is continuously detected. The difference between “record after” and “issue and refuse” is the whole problem.

The hierarchy has four levels, and each level has a job. An IPAM is the top-level resource, pinned to a home Region but aware of multiple operating_regions. A scope is a routing domain — every IPAM ships a private default scope and a public default scope, and prefixes inside one private scope must not overlap. A pool is a collection of CIDRs that nests: a child pool’s source_ipam_pool_id points at its parent and provisions space out of it. An allocation is a CIDR handed out of a pool to a resource (a VPC) or reserved manually. Get these four nouns straight and the rest is detail.

Locale decides who a pool can serve. A locale is the AWS Region (or Local Zone) a pool is tied to. Only a pool whose locale matches a VPC’s Region can allocate to that VPC. The standard pattern is a locale-free top pool (so it can feed every Region) with locale-pinned Regional pools beneath it. A pool with the wrong locale — or a top pool accidentally pinned to one Region — is the most common reason an allocation silently fails.

Guardrails are hard filters, not suggestions. A pool can carry allocation_default_netmask_length (the size handed out if the caller omits one), allocation_min_netmask_length / allocation_max_netmask_length (inclusive bounds on the prefix length, not host count), and allocation_resource_tags (a map every allocation must match or the request is rejected). These let you make prod and non-prod address space provably separate and prevent a team from grabbing a /12 when they should take a /20.

Two tiers, and only one is for an organization. The Free Tier gives pools, allocation, and basic monitoring within a single account/Region. The Advanced Tier adds cross-account and cross-Region pools shared via RAM, organization-wide overlap and utilization monitoring, BYOIP/BYOASN management, and public IP insights. Advanced is billed per active IP it manages. Everything below assumes Advanced Tier.

Before the deep sections, pin the vocabulary down side by side:

Free Tier vs Advanced Tier — the capability split

The tier choice is not cosmetic; almost every organizational capability lives behind Advanced. Pick Free only for a single-account experiment. The exact split:

Why IPAM over the alternatives

Teams reach IPAM after a manual scheme has already hurt them. Seeing the alternatives side by side makes the trade explicit — what each approach can and cannot do:

The pattern is clear: every alternative either records without preventing, or forces you to build (and forever maintain) the prevention/monitoring that IPAM gives natively. The only scenario where a manual scheme wins is a single account with one or two VPCs that will never connect to anything.

Designing the pool hierarchy

IPAM lives in your networking/IPAM delegated account, not the management account. Reserve a dedicated account for it. A sound top-down design for an org is: one global top-level pool covering the whole supernet you control, a Regional pool per operating Region (locale-pinned), then per-environment or per-OU pools beneath each Region. The top pool stays locale-free so it can feed every Region; the layer below is pinned.

# In the IPAM delegated account
resource "aws_vpc_ipam" "org" {
  description = "Org-wide IPAM"
  tier        = "advanced"

  operating_regions { region_name = "eu-west-1" }
  operating_regions { region_name = "us-east-1" }
}

# Top-level pool: the whole RFC1918 supernet you control, locale-agnostic
resource "aws_vpc_ipam_pool" "top" {
  address_family = "ipv4"
  ipam_scope_id  = aws_vpc_ipam.org.private_default_scope_id
  description    = "Top-level - all private space"
}

resource "aws_vpc_ipam_pool_cidr" "top" {
  ipam_pool_id = aws_vpc_ipam_pool.top.id
  cidr         = "10.0.0.0/8"
}

# Regional pool, locale-pinned so VPCs in this Region draw from it
resource "aws_vpc_ipam_pool" "euw1" {
  address_family      = "ipv4"
  ipam_scope_id       = aws_vpc_ipam.org.private_default_scope_id
  locale              = "eu-west-1"
  source_ipam_pool_id = aws_vpc_ipam_pool.top.id
  description         = "eu-west-1 regional pool"
}

resource "aws_vpc_ipam_pool_cidr" "euw1" {
  ipam_pool_id   = aws_vpc_ipam_pool.euw1.id
  netmask_length = 12          # IPAM carves a free /12 from the /8
}

The CloudFormation equivalent uses AWS::EC2::IPAM, AWS::EC2::IPAMScope, AWS::EC2::IPAMPool and AWS::EC2::IPAMPoolCidr, so estates split across both tools share one allocation authority. The three structural layers, what each does, and the rule for its locale:

A concrete sizing of a 10.0.0.0/8 tree shows how the layers divide and how much room each leaves — size generously so you rarely re-cut (pool size doesn’t drive cost, only active IPs do):

Pool attribute reference

Every meaningful pool attribute, its values, default, when to change it, and the gotcha:

Scopes — when you need more than the defaults

Most organizations need exactly the two default scopes. You add a private scope only when you genuinely run disconnected routing domains — address space that will never route to the rest of the estate, where deliberate overlap is acceptable (think isolated lab or a fully air-gapped environment). Adding scopes to “organize” pools is a mistake: it disables the very overlap detection you came for, because overlap is computed within a scope, never across.

Operating Regions and cross-Region behaviour

The IPAM has a home Region (where the IPAM resource lives) and a set of operating Regions (where it can create pools and monitor resources). Getting this wrong is a quiet trap: you cannot create a locale-pinned pool for a Region the IPAM doesn’t operate in, and resources in non-operating Regions simply aren’t monitored. The behaviours to know:

Allocation guardrails on leaf pools

Beneath each Regional pool, create one pool per environment (or per OU). This is where you bake in allocation rules so the pool refuses non-compliant requests: a default netmask, inclusive bounds on prefix sizes, and required tags on every allocation.

resource "aws_vpc_ipam_pool" "euw1_prod" {
  address_family      = "ipv4"
  ipam_scope_id       = aws_vpc_ipam.org.private_default_scope_id
  locale              = "eu-west-1"
  source_ipam_pool_id = aws_vpc_ipam_pool.euw1.id
  description         = "eu-west-1 prod"

  # Allocation guardrails
  allocation_default_netmask_length = 20   # default VPC size if caller omits one
  allocation_min_netmask_length     = 16   # nobody may grab bigger than /16
  allocation_max_netmask_length     = 24   # nor smaller than /24

  # Every allocation MUST carry these tags or the request is rejected
  allocation_resource_tags = {
    Environment = "prod"
  }
}

resource "aws_vpc_ipam_pool_cidr" "euw1_prod" {
  ipam_pool_id   = aws_vpc_ipam_pool.euw1_prod.id
  netmask_length = 16
}

allocation_min_netmask_length and allocation_max_netmask_length are inclusive bounds on the prefix length, not the host count, so “min 16 / max 24” means allocations between a /16 and a /24. Because larger prefix length = smaller network, min is the biggest block someone may take and max is the smallest — the inversion trips everyone the first time. The allocation_resource_tags map is a hard filter: a VPC create that does not carry Environment=prod will not draw from this pool.

The guardrail-to-effect mapping, with the exact failure when violated:

A prefix-length cheat sheet so nobody guesses how big a block actually is:

Delegating administration and sharing pools via AWS RAM

Two things must be wired before member accounts can self-serve. First, delegate IPAM to your networking account so it (not the org management account) administers IPAM. Run this once from the management account:

aws ec2 enable-ipam-organization-admin-account \
  --delegated-admin-account-id 222233334444

This also enables the trusted access between IPAM and Organizations that powers org-wide monitoring. Second, share the leaf pools to the accounts or OUs that should allocate from them, using AWS RAM. You share the pool, not the IPAM, and RAM sharing with your organization must be enabled first.

resource "aws_ram_resource_share" "ipam_prod" {
  name                      = "ipam-euw1-prod"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "ipam_prod" {
  resource_arn       = aws_vpc_ipam_pool.euw1_prod.arn
  resource_share_arn = aws_ram_resource_share.ipam_prod.arn
}

# Share to an entire OU (principal = OU ARN) or to specific account IDs
resource "aws_ram_principal_association" "ipam_prod_ou" {
  principal          = "arn:aws:organizations::111122223333:ou/o-exampleorgid/ou-prod-abcd1234"
  resource_share_arn = aws_ram_resource_share.ipam_prod.arn
}

Once shared, a workload account can reference the pool ID directly in its own VPC definition. It cannot see other pools, cannot widen the netmask bounds, and every CIDR it pulls is registered centrally in the IPAM account. The sharing model, what each piece does, and the failure if you skip it:

What a member account can and cannot do once a pool is shared to it — the trust boundary:

Automating VPC CIDR allocation

This is the payoff. A spoke VPC no longer hard-codes a block; it names a pool and a size, and IPAM hands back a free, non-overlapping CIDR. Run this from the member account that received the RAM share:

resource "aws_vpc" "spoke" {
  ipv4_ipam_pool_id   = "ipam-pool-0prodshared0euw1"  # the shared pool ID
  ipv4_netmask_length = 20                            # ask for a /20

  tags = {
    Environment = "prod"   # required by the pool's allocation_resource_tags
    Name        = "payments-prod"
  }
}

CloudFormation expresses the same contract through Ipv4IpamPoolId and Ipv4NetmaskLength on AWS::EC2::VPC. You can also reserve space outside of a VPC — for a future EKS secondary CIDR, an on-prem block you are reconciling, or a peer’s range — with an explicit allocation that carves the space so IPAM will never re-issue it:

aws ec2 allocate-ipam-pool-cidr \
  --ipam-pool-id ipam-pool-0prodshared0euw1 \
  --netmask-length 22 \
  --description "reserved for eks-prod secondary CIDR"

The CLI returns an IpamPoolAllocationId; hold onto it, because that is what you use to release the reservation later. The allocation methods, when to use each, and how IPAM treats it:

The most useful allocation-state CLI calls, and what each one answers:

Declarative provisioning end to end

The whole point is that network teams stop touching the console. The pool hierarchy, RAM shares, and alarms live in the IPAM account’s Terraform state; member-account modules reference shared pool IDs as variables. A reusable VPC module never needs a CIDR input again:

variable "ipam_pool_id" { type = string }
variable "vpc_netmask"  { type = number, default = 22 }
variable "environment"  { type = string }

resource "aws_vpc" "this" {
  ipv4_ipam_pool_id   = var.ipam_pool_id
  ipv4_netmask_length = var.vpc_netmask
  tags                = { Environment = var.environment }
}

The division of state, who owns each file, and what not to put where:

Monitoring utilization, overlap, and exhaustion

IPAM continuously computes utilization for every pool and every monitored resource. Query it on demand to find pools that are filling up, and resources that overlap:

# Resource-level view across the whole IPAM: which VPCs/EIPs, and their util %
aws ec2 get-ipam-resource-cidrs \
  --ipam-scope-id ipam-scope-0abc123 \
  --filters Name=management-state,Values=managed

# Overlapping + non-compliant resources, surfaced directly
aws ec2 get-ipam-resource-cidrs \
  --ipam-scope-id ipam-scope-0abc123 \
  --filters Name=overlap-status,Values=overlapping \
            Name=compliance-status,Values=noncompliant

The richer signal is the metrics IPAM publishes. With Advanced Tier and state monitoring enabled, IPAM emits per-pool metrics — allocation counts, available address counts, and the all-important utilization ratio — to CloudWatch under the AWS/IPAM namespace. Alarm on the pool before it exhausts, not after a VPC create fails in prod:

resource "aws_cloudwatch_metric_alarm" "prod_pool_exhaustion" {
  alarm_name          = "ipam-euw1-prod-utilization-high"
  namespace           = "AWS/IPAM"
  metric_name         = "IPAMPoolAllocationUtilizationPercentage"
  dimensions = {
    IpamId       = aws_vpc_ipam.org.id
    IpamPoolId   = aws_vpc_ipam_pool.euw1_prod.id
    IpamScopeId  = aws_vpc_ipam.org.private_default_scope_id
  }
  statistic           = "Maximum"
  period              = 3600
  evaluation_periods  = 1
  threshold           = 80
  comparison_operator = "GreaterThanOrEqualToThreshold"
  alarm_actions       = [aws_sns_topic.netops.arn]
}

A pre-existing VPC that overlaps shows up in the overlap report the moment IPAM starts monitoring its account — which is exactly how you find the landmines the spreadsheet missed. The IPAM resource statuses, what each means, and the action it demands:

The AWS/IPAM metrics worth alarming on, and the threshold to start with:

Bring your own public IP space (BYOIP) and BYOASN

Public space lives in the IPAM public scope. To advertise your own range from AWS, you provision it into a public-scope pool, prove ownership, then advertise it. Two ownership requirements matter: the prefix must be at least a /24 for IPv4 (the smallest globally routable block), and you need a valid ROA (Route Origin Authorization) in your RIR’s RPKI naming AWS’s ASN (16509) as an authorized origin so the advertisement passes RPKI validation.

# Provision your CIDR into a public-scope pool (publicly-advertisable)
aws ec2 provision-ipam-pool-cidr \
  --ipam-pool-id ipam-pool-0publicpoolexample \
  --cidr 203.0.113.0/24 \
  --cidr-authorization-context \
      Message="$MSG",Signature="$SIG"

The authorization context is a signed message proving you control the block; you sign a message string with the private key whose public half is published in your RDAP/whois record. Provisioning runs an asynchronous verification — poll get-ipam-pool-cidrs until state is provisioned. Only then advertise it:

aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24

# and to withdraw it (e.g., before migrating advertisement back on-prem)
aws ec2 withdraw-byoip-cidr --cidr 203.0.113.0/24

You can also bring your own ASN (BYOASN) so EC2 and Global Accelerator advertise your prefixes from your ASN rather than Amazon’s. Provision the ASN, associate it with the IPAM, and tie it to the public pool:

aws ec2 provision-ipam-byoasn \
  --ipam-id ipam-0abc123example \
  --asn 64512 \
  --asn-authorization-context \
      Message="$MSG",Signature="$SIG"

Keep advertisement under your control: provision and verify with advertisement off, cut over DNS, then advertise-byoip-cidr; withdraw before you ever move the announcement back to on-prem so you never have the same prefix announced from two origins. The BYOIP requirements, why each exists, and the failure if you miss it:

The BYOIP lifecycle states and what each one means operationally:

IPv4 vs IPv6 BYOIP differ in important ways — do not assume the IPv4 rules transfer:

Architecture at a glance

Follow the control path left to right. It begins in the management account, where you enable trusted access with AWS Organizations and run enable-ipam-organization-admin-account exactly once to delegate IPAM to a dedicated networking account — the management account never administers IPAM day to day. In the IPAM delegated account sits the IPAM itself (home Region plus operating_regions), the pool tree (a locale-free 10.0.0.0/8 top pool, locale-pinned /12 Regional pools, /16 per-environment leaf pools), and the allocation guardrails (min/max netmask, required tags) that make a pool refuse a bad request. From there a leaf pool is published through an AWS RAM resource share — the pool ARN, scoped to an OU and blocking external principals — so that member accounts can reference the pool ID and have a /20 drawn for each spoke VPC without ever picking a CIDR. Every drawn CIDR is registered back in the IPAM account, where utilization and overlap are computed and a CloudWatch alarm on AWS/IPAM fires at 80%. A separate branch into the public scope provisions BYOIP space (/24 minimum, a ROA naming ASN 16509) and advertises it only after DNS cutover.

The five numbered badges mark exactly where this path fails in practice: a locale mismatch stalls allocation, a guardrail rejects an untagged or wrong-sized request, a RAM share done wrong leaves the member account seeing nothing, an overlap or exhaustion condition surfaces in the monitoring branch, and a BYOIP advertisement is refused for a missing ROA or premature announcement. Read the diagram once to internalise the flow, then use the legend as the first triage table when an allocation or advertisement does not behave.

Real-world scenario

A fintech platform team I worked with ran 60+ accounts that had grown organically before any address governance existed. Three separate teams had independently landed VPCs on 10.10.0.0/16. The pain surfaced when they stood up a central Transit Gateway for shared services: the second and third attachments advertising 10.10.0.0/16 were silently unusable, because a TGW route table cannot hold the same prefix twice. Renumbering a live, regulated payments VPC mid-quarter was not on the table.

The constraint was hard: they could not renumber the offending VPCs quickly, but they had to know the full blast radius before the TGW migration, and prevent any new overlap from that day forward. They stood up Advanced-Tier IPAM in a dedicated networking account, defined a 10.0.0.0/8 top-level pool with Regional (/12) and per-environment (/16) children, and imported every existing VPC’s CIDR rather than recreating anything. The import immediately populated the overlap report:

aws ec2 get-ipam-resource-cidrs \
  --ipam-scope-id ipam-scope-0abc123 \
  --filters Name=overlap-status,Values=overlapping \
  --query 'IpamResourceCidrs[].{Vpc:ResourceId,Cidr:ResourceCidr,Acct:ResourceOwnerId}'

That single command turned “we think three VPCs collide” into an exact list of resource IDs, CIDRs, and owning accounts — the precise scope they needed to plan migrations. From that point, every new VPC was forced through RAM-shared pools with allocation_resource_tags enforcing environment separation, so the overlap set could only shrink. They renumbered the two least-critical colliding VPCs over the following two sprints, left the regulated one isolated behind PrivateLink until its planned window, and never created a fresh overlap again.

The numbers tell the story of the migration arc, week by week:

The lesson: IPAM’s real first-day value was not allocation, it was discovery of the overlap nobody could previously see — and then making it structurally impossible to add another.

Advantages and disadvantages

IPAM trades a one-time design-and-delegate cost for permanent, enforced address governance. Weigh it honestly before you commit a team to operating it:

IPAM is the right call for any organization with more than a handful of accounts, a hub-and-spoke Transit Gateway, hybrid connectivity to on-prem, or a need to advertise owned public space. It is overkill for a single account with one or two VPCs that will never peer or connect to anything — there, a documented manual CIDR is fine. The disadvantages are all manageable: the pool tree is the only decision you must get roughly right up front, and even that can be extended (new Regional/leaf pools) far more easily than it can be fundamentally re-shaped.

Hands-on lab

Stand up a minimal IPAM, build a two-level pool tree with guardrails, draw a VPC CIDR, and prove the guardrails reject a bad request — then tear it all down. This is single-account and Free-Tier-friendly for the basic pool/allocation steps (no cross-account RAM, no BYOIP). Run in CloudShell.

Step 1 — Variables.

REGION=eu-west-1
export AWS_DEFAULT_REGION=$REGION

Step 2 — Create the IPAM (Free Tier, one operating Region).

IPAM=$(aws ec2 create-ipam \
  --operating-regions RegionName=$REGION \
  --query 'Ipam.IpamId' --output text)
SCOPE=$(aws ec2 describe-ipams --ipam-ids $IPAM \
  --query 'Ipams[0].PrivateDefaultScopeId' --output text)
echo "IPAM=$IPAM SCOPE=$SCOPE"

Expected: an ipam-… ID and an ipam-scope-… ID.

Step 3 — Top pool, provision 10.0.0.0/16 into it.

TOP=$(aws ec2 create-ipam-pool --ipam-scope-id $SCOPE \
  --address-family ipv4 --query 'IpamPool.IpamPoolId' --output text)
aws ec2 provision-ipam-pool-cidr --ipam-pool-id $TOP --cidr 10.0.0.0/16

Step 4 — Leaf pool with guardrails (locale-pinned, required tag, netmask bounds).

LEAF=$(aws ec2 create-ipam-pool --ipam-scope-id $SCOPE \
  --address-family ipv4 --source-ipam-pool-id $TOP --locale $REGION \
  --allocation-default-netmask-length 24 \
  --allocation-min-netmask-length 20 \
  --allocation-max-netmask-length 26 \
  --allocation-resource-tags Key=Environment,Value=lab \
  --query 'IpamPool.IpamPoolId' --output text)
aws ec2 provision-ipam-pool-cidr --ipam-pool-id $LEAF --netmask-length 20

Wait until the leaf pool’s provisioned CIDR shows state=provisioned:

aws ec2 get-ipam-pool-cidrs --ipam-pool-id $LEAF \
  --query 'IpamPoolCidrs[].State' --output text

Step 5 — Create a compliant VPC (drawn /24, correct tag). Expected: it succeeds.

aws ec2 create-vpc --ipv4-ipam-pool-id $LEAF --ipv4-netmask-length 24 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Environment,Value=lab}]' \
  --query 'Vpc.{Id:VpcId,Cidr:CidrBlock}'

Step 6 — Prove the guardrails (the whole point). Each of these MUST fail:

# (a) Missing the required Environment=lab tag -> rejected
aws ec2 create-vpc --ipv4-ipam-pool-id $LEAF --ipv4-netmask-length 24 || echo "REJECTED: tag rule"

# (b) Too big: /19 is below allocation-min-netmask-length 20 -> rejected
aws ec2 create-vpc --ipv4-ipam-pool-id $LEAF --ipv4-netmask-length 19 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Environment,Value=lab}]' || echo "REJECTED: min netmask"

# (c) Too small: /27 is above allocation-max-netmask-length 26 -> rejected
aws ec2 create-vpc --ipv4-ipam-pool-id $LEAF --ipv4-netmask-length 27 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Environment,Value=lab}]' || echo "REJECTED: max netmask"

If any of (a)–© succeeds, your guardrail is not doing what you think — a guardrail you have not seen reject something is a guardrail you do not have.

Step 7 — Confirm the allocation registered.

aws ec2 get-ipam-pool-allocations --ipam-pool-id $LEAF \
  --query 'IpamPoolAllocations[].{Cidr:Cidr,Type:ResourceType,Owner:ResourceOwner}'

Validation checklist — what each step proved:

Teardown (bottom-up — deletion protection blocks any other order):

# Delete the VPC(s) first (releases their auto allocations), then:
aws ec2 deprovision-ipam-pool-cidr --ipam-pool-id $LEAF --cidr <leaf-cidr>
aws ec2 delete-ipam-pool --ipam-pool-id $LEAF
aws ec2 deprovision-ipam-pool-cidr --ipam-pool-id $TOP --cidr 10.0.0.0/16
aws ec2 delete-ipam-pool --ipam-pool-id $TOP
aws ec2 delete-ipam --ipam-id $IPAM

Cost note. Free-Tier IPAM with a couple of pools and one VPC for an hour is effectively free; Advanced Tier would bill per active managed IP. Deleting the IPAM bottom-up stops everything.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First a scannable table you can read mid-migration, then the full reasoning for the entries that bite hardest. The recurring theme: IPAM rarely errors loudly; it refuses quietly, and the skill is knowing which refusal you are looking at.

The expanded form for the entries that cost the most time:

1. VPC create from a pool fails with no allocation / a “locale” complaint. Root cause: The pool the VPC references has no locale, or the top-level pool was accidentally locale-pinned so it can’t feed the VPC’s Region. Confirm: aws ec2 describe-ipam-pools --query 'IpamPools[].{Id:IpamPoolId,Locale:Locale,Depth:PoolDepth}' — the leaf pool must carry the VPC’s Region, the top pool should show null. Fix: Pin the Regional layer to each Region; keep the top pool locale-free. Only a locale-matched pool can allocate to a VPC in that Region.

2. CreateVpc is rejected with a tag error. Root cause: The leaf pool’s allocation_resource_tags is a hard filter and the VPC create didn’t carry the required tag. Confirm: describe-ipam-pools shows AllocationResourceTags; compare to your --tag-specifications. Fix: Add the exact key/value (e.g. Environment=prod). This is the mechanism that keeps prod and non-prod space provably separate — it is working as designed.

3–4. A request for a /15 (or a /27) is rejected. Root cause: The size is outside the pool’s inclusive prefix bounds. min_netmask_length is the biggest block allowed (smallest prefix number), max_netmask_length the smallest block. Confirm: Check AllocationMinNetmaskLength / AllocationMaxNetmaskLength on the pool. Fix: Ask within bounds. If the bounds are genuinely wrong, change them on the pool (in the IPAM account) — a member account cannot.

6. A member account reports it “can’t see the pool.” Root cause: The RAM share is missing, points at the wrong principal/OU ARN, or RAM “sharing with Organizations” was never enabled. A common variant: someone shared the IPAM instead of the pool. Confirm: aws ram get-resource-shares --resource-owner SELF; aws ram get-resource-share-associations --association-type PRINCIPAL. Fix: Enable RAM sharing with Organizations (management account), then associate the pool ARN and the correct OU/account principal to the share.

7. An imported VPC shows overlapping. Root cause: A pre-existing duplicate CIDR that the spreadsheet missed — exactly what import is meant to surface. Confirm: get-ipam-resource-cidrs --filters Name=overlap-status,Values=overlapping returns the resource IDs, CIDRs and owning accounts. Fix: You cannot renumber a live VPC instantly; isolate the collider (PrivateLink) and renumber it in a planned window. The overlap set can only shrink once new VPCs are forced through guardrailed pools.

9–10. BYOIP won’t advertise, or a prefix ends up announced twice. Root cause (9): The prefix is smaller than /24, lacks a valid ROA naming ASN 16509, or is still in pending-provision. (10): You advertised on AWS without first withdrawing the on-prem announcement. Confirm: get-ipam-pool-cidrs --query 'IpamPoolCidrs[].State' (must be provisioned); for double-announcement, check a looking-glass / your BGP. Fix: Provide a /24+ with a correct ROA, wait for provisioned, advertise only after DNS cutover, and withdraw the other origin before announcing — never originate the same prefix from two ASNs at once.

11. You can’t deprovision a CIDR or delete a pool. Root cause: Deletion-protection semantics — a pool with live allocations under it can’t be emptied or deleted. Confirm: get-ipam-pool-allocations returns a non-empty list. Fix: Reclaim bottom-up: delete the VPCs (which releases their auto allocations) and release manual reservations by IpamPoolAllocationId first, then deprovision and delete the pool.

Best practices

• One IPAM, in a dedicated networking account, delegated from management. Never run IPAM out of the org management account; delegate it once with enable-ipam-organization-admin-account and keep the blast radius small.
• Top pool locale-free, Regional pools locale-pinned, leaf pools per environment/OU. This is the only tree shape that lets one supernet feed every Region while keeping allocations Region-correct.
• Put guardrails on every leaf pool and prove they reject. allocation_min/max_netmask_length plus allocation_resource_tags, and test a bad request until you have seen the rejection. A guardrail you haven’t watched fire is not a guardrail.
• Share the pool, not the IPAM, and block external principals. RAM-share leaf pools to OUs with allow_external_principals = false; members self-serve without seeing anything else.
• Force every VPC to draw a CIDR — zero hard-coded blocks. ipv4_ipam_pool_id in every VPC module; a literal CIDR anywhere is a future collision.
• Alarm on AWS/IPAM utilization at 80%, routed to NetOps. Catch exhaustion before a prod VPC create fails, not after the pager.
• Import existing VPCs, never recreate them. Import surfaces overlap and brings live VPCs under monitoring without renumbering; recreating a live VPC is how you cause the outage you were trying to prevent.
• Reclaim bottom-up and respect deletion protection. Release manual reservations and delete VPCs before deprovisioning/deleting pools.
• For BYOIP, verify with advertisement off, then cut over, then advertise. And always withdraw the old origin first — never two announcements of one prefix.
• Keep everything declarative. Pool tree, RAM shares, alarms in the IPAM account’s IaC; member modules reference shared pool IDs as variables/outputs.
• Review the overlap and compliance report on a cadence. New imports, mergers and manual reservations can introduce noncompliant/overlapping resources; make the report a recurring check, not a one-off.

Security notes

• Least-privilege IAM for IPAM operations. Allocation and pool-management actions (ec2:AllocateIpamPoolCidr, ec2:ProvisionIpamPoolCidr, ec2:CreateIpamPool, ec2:ModifyIpamPool) should be tightly scoped — the networking team manages pools; workload accounts get only what RAM grants. Use SCPs to deny pool creation/deletion outside the delegated account.
• Delegation is a privilege boundary. The delegated IPAM account effectively governs the org’s address plan; treat it like any other security-sensitive delegated admin and restrict who can assume into it.
• allocation_resource_tags as a guardrail, not a secret. Tags enforce environment separation but are not a security control on their own — pair them with SCPs/RCPs so a non-prod principal cannot create resources in prod address space at all.
• BYOIP authorization keys. The private key you use to sign the BYOIP authorization context proves ownership of public space — store and rotate it like any high-value secret; a leak lets someone attempt to hijack your prefix authorization.
• RAM external sharing off. Set allow_external_principals = false on IPAM pool shares so address authority never leaks outside the organization.
• Audit with CloudTrail. IPAM allocate/provision/advertise calls are CloudTrail events; alert on provision-ipam-pool-cidr, advertise-byoip-cidr, and modify-ipam-pool from unexpected principals.
• Public scope is internet-facing intent. Anything in the public scope is or can be advertised to the internet — review public-pool changes with the same care as a security group opening 0.0.0.0/0.

The control-to-threat mapping for the IPAM control plane:

Cost & sizing

The bill driver for IPAM is simple: Advanced Tier charges per active IP it manages, billed hourly. The Free Tier (single account/Region, no cross-account sharing, no BYOIP) has no per-IP charge. So cost scales with the number of monitored, allocated addresses across the estate — not with the number of pools or VPCs. There is no per-pool or per-allocation fee; you are paying for the continuous monitoring/inventory of active IPs.

Right-sizing IPAM is therefore about not over-monitoring: import the address space you actually need governed, mark genuinely-irrelevant CIDRs as ignored rather than managed, and don’t stand up Advanced Tier in tiny single-account setups that the Free Tier covers. The cost is almost always trivial relative to the value — a single TGW outage from an undetected overlap, or one emergency renumber of a regulated VPC, dwarfs a year of IPAM’s per-IP charge. The cost/sizing levers:

A rough picture: for an org with a few thousand actively-managed addresses across 60 accounts, Advanced-Tier IPAM is a low-tens-of-dollars-per-month line item — comfortably inside a platform budget and immaterial next to the cost of a single address-collision incident. Size the pools generously (a /8 top pool, /12 regions) so you rarely re-cut the tree; pool size does not drive cost, only active IPs do.

Interview & exam questions

1. Why can’t two VPCs both use 10.0.0.0/16 if they need to connect? Routing is by longest-prefix match, and a Transit Gateway or VPC route table cannot hold two identical prefixes pointing at different destinations. The second attachment/peering is rejected or silently unreachable. IPAM prevents this by issuing only unique CIDRs within a scope and detecting any existing overlap.

2. Walk through the IPAM hierarchy. An IPAM (home Region + operating Regions) contains scopes (a private and public default; prefixes within a scope must not overlap), which contain pools that nest via source_ipam_pool_id, which hand out allocations (CIDRs) to VPCs or as manual reservations. Overlap is enforced per scope.

3. What does locale do, and what’s the standard pattern? A locale ties a pool to a Region (or Local Zone); only a locale-matched pool can allocate to a VPC in that Region. The pattern is a locale-free top pool feeding locale-pinned Regional pools, with per-environment leaf pools beneath. A wrong/missing locale is the classic reason an allocation silently fails.

4. Free Tier vs Advanced Tier — what needs Advanced? Cross-account pools (RAM sharing), cross-Region pools, org-wide overlap/utilization monitoring, BYOIP/BYOASN, and public IP insights all require Advanced. Free Tier is single-account/Region with basic monitoring. Advanced bills per active managed IP.

5. How do allocation_min_netmask_length and allocation_max_netmask_length work — and what’s the trap? They are inclusive bounds on the prefix length, not host count. Because a larger prefix number is a smaller network, min is the biggest block allowed and max is the smallest. “min 16 / max 24” permits /16 through /24. The inversion trips people constantly.

6. How do you let a workload account self-serve CIDRs without exposing the whole address plan? Share the leaf pool (not the IPAM) via AWS RAM to the account or OU, with allow_external_principals=false. The member references the pool ID, draws within the guardrails, and cannot see other pools, widen bounds, or skip required tags.

7. You import an existing estate and three VPCs show overlapping. What now? You generally can’t renumber a live VPC instantly. Isolate the collider (e.g. behind PrivateLink) and renumber it in a planned window, while forcing all new VPCs through guardrailed pools so the overlap set can only shrink. Import’s value here is discovery — turning a guess into an exact list of resource IDs and accounts.

8. What are the hard requirements to advertise a BYOIP IPv4 prefix from AWS? The prefix must be at least a /24, you need a valid ROA in your RIR’s RPKI naming ASN 16509 (or your BYOASN), and the provisioning ownership check (signed authorization context) must complete to provisioned. Advertise only after, ideally post-DNS-cutover.

9. How do you avoid announcing the same prefix from two origins during a migration? Provision and verify on AWS with advertisement off, cut over DNS, then advertise-byoip-cidr; and withdraw the on-prem (or other) announcement before AWS originates it. Never originate one prefix from two ASNs simultaneously.

10. How do you get warned before a pool exhausts? Enable Advanced-Tier state monitoring and alarm on the AWS/IPAM CloudWatch metric IPAMPoolAllocationUtilizationPercentage at, say, 80%, routed to a NetOps SNS topic — so you provision more space before a prod VPC create fails, rather than after.

11. Why can’t you immediately delete a pool, and how do you reclaim space? Deletion-protection semantics block deprovisioning a CIDR or deleting a pool while allocations exist under it. Reclaim bottom-up: delete VPCs (releasing their auto allocations) and release manual reservations by IpamPoolAllocationId, then deprovision and delete the pool.

12. How do you bring an existing VPC under IPAM without renumbering it? Import its current CIDR into the appropriate pool. This registers the space as a manual allocation, flips the resource to managed, and makes it appear in utilization and overlap reports — the VPC keeps its address while finally becoming visible. Do not recreate the VPC.

These map primarily to the AWS Certified Advanced Networking – Specialty (ANS-C01) — network design and management at scale, hybrid connectivity, IP addressing — and touch the Solutions Architect Professional (SAP-C02) multi-account networking domain. The cert-mapping for revision:

Quick check

1. Two VPCs in different accounts both own 10.10.0.0/16 and you attach both to one Transit Gateway. What happens, and why?
2. Your top-level pool was created with locale = "eu-west-1". A VPC in us-east-1 can’t draw from the tree. What’s wrong?
3. A leaf pool has allocation_min_netmask_length = 16 and allocation_max_netmask_length = 24. Will a request for a /26 succeed? Will a /16? Will a /12?
4. A member account says it “can’t see” the pool you shared. Name two things to check.
5. You’re migrating a public prefix onto AWS. In what order do you provision, advertise, withdraw on-prem, and cut over DNS — and why?

Answers

1. The TGW route table cannot hold the same prefix (10.10.0.0/16) twice, so only the first attachment is routable; the second is silently unreachable. Routing is longest-prefix-match and can’t represent two identical prefixes to different destinations. IPAM would have prevented the duplicate at allocation time.
2. The top-level pool is locale-pinned to eu-west-1, so it can only feed that Region. Keep the top pool locale-free and pin the Regional layer; only a locale-matched pool can allocate to a VPC in a given Region.
3. A /26 is rejected (smaller than the /24 max). A /16 succeeds (it’s the largest allowed). A /12 is rejected (bigger than the /16 min). Remember: min = biggest block allowed, max = smallest.
4. Check (a) the RAM resource share has the pool ARN associated (not the IPAM) and the correct OU/account principal — get-resource-share-associations; and (b) that RAM sharing with Organizations is enabled in the management account. A frequent mistake is sharing the IPAM instead of the pool.
5. Provision and verify on AWS with advertisement off → cut over DNS → advertise-byoip-cidr on AWS → withdraw the on-prem announcement. This guarantees the prefix is never announced from two origins at once and that DNS already points at the new path before AWS originates the route.

Glossary

• IPAM (IP Address Manager) — the top-level AWS resource that plans, allocates and monitors IP address space across accounts and Regions; pinned to a home Region with multiple operating Regions.
• Scope — a routing domain inside an IPAM; every IPAM has a private and a public default scope, and prefixes within a scope must not overlap.
• Pool — a collection of CIDRs that nests via source_ipam_pool_id; the unit you carve, guardrail, and RAM-share.
• Allocation — a CIDR drawn out of a pool, either automatically (a VPC) or as a manual reservation; identified by an IpamPoolAllocationId.
• Locale — the Region (or Local Zone) a pool is tied to; only a locale-matched pool can allocate to a VPC in that Region.
• Operating Region — a Region the IPAM operates/monitors in; pools can only exist in operating Regions.
• Provisioned CIDR — a block added into a pool (its supply), either carved from a parent pool by netmask_length or an explicit cidr.
• Allocation guardrails — allocation_default/min/max_netmask_length and allocation_resource_tags on a pool that constrain and filter what it will hand out.
• Free Tier / Advanced Tier — IPAM’s two capability/billing tiers; Advanced adds cross-account/Region pools, org-wide monitoring, and BYOIP/BYOASN, billed per active managed IP.
• AWS RAM (Resource Access Manager) — the service used to share IPAM pools (not the IPAM) to accounts or OUs so they can self-serve allocations.
• Delegated administrator — the dedicated networking account to which IPAM administration is delegated via enable-ipam-organization-admin-account.
• BYOIP (Bring Your Own IP) — provisioning your own public IPv4/IPv6 prefix into a public-scope pool and advertising it from AWS.
• BYOASN (Bring Your Own ASN) — bringing your own Autonomous System Number so AWS advertises your prefixes from your ASN rather than Amazon’s (16509).
• ROA (Route Origin Authorization) — a signed object in your RIR’s RPKI authorizing a given ASN to originate a prefix; required for BYOIP advertisement to pass RPKI validation.
• Overlap / compliance status — IPAM’s per-resource flags (overlapping/nonoverlapping, compliant/noncompliant/unmanaged) that surface collisions and guardrail violations.
• Deletion protection (semantics) — you cannot deprovision a CIDR or delete a pool while allocations exist under it; reclamation is bottom-up.

Next steps

You can now design an IPAM hierarchy, delegate and share it, automate allocation with guardrails, monitor for exhaustion and overlap, and bring your own public space onto AWS. Build outward:

• Next: AWS Transit Gateway multi-account VPC architecture — the hub-and-spoke that depends on collision-free CIDRs from IPAM.
• Related: VPC deep dive: subnets, routing, IGW, NAT and endpoints — how the CIDRs IPAM hands out get carved into a working VPC.
• Related: Resilient Direct Connect + Transit Gateway — hybrid routing where on-prem overlap with your VPCs black-holes traffic.
• Related: AWS PrivateLink for service provider/consumer access — the isolation pattern used to keep an overlapping VPC reachable without renumbering.
• Related: AWS Organizations: SCP guardrails & delegated admin — the policy layer that pairs with IPAM tag guardrails to enforce address governance.
• Related: Network Reachability Analyzer & Access Analyzer for connectivity validation — prove a path works after you’ve untangled the CIDRs.