AWS IPAM: What It Enforces, What It Only Reports, and What It Bills
IPAM allocation rules constrain what IPAM offers you, not what your account can create. Nothing stops a team from typing a CIDR by hand, so the rules you set as guardrails turn out to be a report — and the tier that manages private IPv4 bills you for every active address in every monitored account.
Published Aug 19, 2026
Subnet tiering and route scoping ends with two address
planning rules: do not overlap with anything you might one day connect to, and leave room in each
tier. Both are conventions. Conventions hold until an engineer in a hurry types 10.0.0.0/16 into a
Terraform variable, and neither rule leaves a trace when it is broken.
AWS IPAM is the service that turns those conventions into a registry. It is worth adopting. It is also routinely adopted on two assumptions that are wrong: that its allocation rules prevent noncompliant networks, and that it is close to free. The first assumption produces a false sense of safety. The second produces a bill that scales with the size of your estate rather than with how much of IPAM you actually use.
Allocation rules constrain what IPAM offers, not what you can create
An IPAM pool can carry allocation rules: a required netmask length, required resource tags, a required locale, and whether CIDRs found inside the pool's range are imported automatically. The word "rules" invites you to read these as admission control. They are not.
There are two ways a VPC gets a CIDR, and the rules only govern one of them:
| How the CIDR is chosen | What the rules do |
|---|---|
You ask IPAM for one (ipv4_ipam_pool_id with a netmask length) | IPAM picks a CIDR that satisfies the pool's rules, or fails the request |
| You type a CIDR literally, inside the pool's range | Nothing prevents creation. With auto-import on, IPAM absorbs it and marks it noncompliant |
AWS states the second case directly in its own best-practices guidance: with a rule capping
allocations at /24, "a resource could still be created using a CIDR larger than /24 from this pool,
if the space is available. However, doing so violates the allocation rule on the pool, and in turn
IPAM flags this resource as noncompliant."
Every width here comes from the prefix, so the comparison is real: the hand-typed /16 is 256 times the size of a compliant allocation, and the three that went through IPAM are barely visible beside it. IPAM absorbs it, records it as noncompliant, and the VPC keeps working. Nothing about the request was refused.
The compliance model confirms the shape. Every monitored resource carries a complianceStatus of
compliant, noncompliant, unmanaged, or ignored — a status that is computed and recorded, not a
gate that is passed. The VPC FAQ describes the intended workflow as creating alarms "to notify you
... if resources fail to comply with allocations rules set on a pool." Notify, after the fact.
This is the same narrower-than-it-looks guardrail that Lab 09 demonstrates from the other direction. AWS refuses to peer two VPCs with overlapping CIDRs, which teaches people that AWS prevents overlap — it only prevents overlap within one peering connection. IPAM closes the visibility gap that leaves behind. It does not close the creation gap.
The tier split decides whether IPAM solves your problem at all
IPAM has a Free Tier and an Advanced Tier, and the split does not fall where most people assume.
| Capability | Free Tier | Advanced Tier |
|---|---|---|
| Bring your own IP address (v4 and v6) | Available | Available |
| Amazon-provided contiguous IPv6 blocks | Available | Available |
| Public IP Insights | Available | Available |
| Bring your own ASN | Available | Available |
| Private IPv6 management | Available | Available |
| Private IPv4 management | Not available | Available |
| Share IPAM pools with other accounts | Not available | Available |
| Audit IP history | Not available | Available |
Private IPv4 management — the pool hierarchy, the allocation rules, the overlap detection across
your 10.0.0.0/8 space, the entire reason most teams go looking for IPAM — is Advanced Tier only.
Private IPv6 management is free. Pool sharing across accounts is Advanced. So is IP history, despite
being one of the headline capabilities on the service's own overview page.
AWS also attaches a catch-all to that table: "Any feature not listed in the table above is available only in the Advanced tier." Treat the Free Tier as a BYOIP and public-IPv4-visibility product, and assume anything else you read about IPAM carries a bill.
What the Advanced Tier bills, and why a pilot is not cheap
The Advanced Tier bills $0.00027 per hour for each active IP address, where an active address is
an IP or a prefix on an ENI that is attached to a resource. Unattached ENIs are not billed. A /28
IPv4 prefix or a /80 IPv6 prefix on an attached ENI counts as one active address, not sixteen
and not three hundred trillion — so prefix delegation is dramatically cheaper per usable address than
individual assignment.
Working that rate forward: $0.00027 × 24 × 30 gives roughly $0.19 per active IP per month, or about $194 per month per thousand active IPs. AWS's own worked examples land on $1,360.80 a month for 7,000 active addresses, and $2,167.56 a month for an organization-integrated IPAM covering 11,150.
The widths are the values, so the shape of the charge is visible: it scales with the size of your estate, not with how much of IPAM you adopt. Nothing about the middle bar buys more IPAM than the first one — it is the same product monitoring seven times as many addresses.
The sentence that decides your bill is this one, from the pricing page:
IPAM tracks and monitors all the IP addresses assigned to resources in your VPCs, even if they are not part of an IPAM IP address pool.
Cost scales with your estate, not with your adoption. You cannot onboard one pool, measure the charge, and extrapolate — the moment an Advanced Tier IPAM exists, every active address in every monitored account is billable, including addresses that predate IPAM and will never belong to a pool. Integrate with AWS Organizations and that means every member account.
This reframes the common recommendation that IPAM costs a rounding error next to one overlap incident. For a small single-account estate, close enough. For a few thousand instances across an organization, IPAM Advanced can cost more per month than the NAT Gateways it is helping you plan. It may still be worth it — renumbering a live VPC is a migration, and this is cheaper than one. But it is a line item to size before switching on, not an afterthought.
Forecasting the bill undercounts exactly where it matters
IPAM publishes a TotalActiveIpCount metric to the AWS/IPAM namespace, documented as "the number
of active IP addresses in your IPAM that you would be charged if you switched from the Free Tier to
the Advanced Tier." It exists specifically to be the forecast, and it is available only in the
Free Tier, which is the correct design — you use it before you switch.
Its caveats are where the forecast breaks:
- It only counts IPs from ENIs owned by monitored accounts. Addresses are excluded if the subnet owner or the ENI owner is not covered by IPAM.
- It is explicitly inaccurate for shared subnets. In a shared-VPC topology, the ENIs live in participant accounts while the subnet belongs to the owner.
- There is no breakdown by public versus private, or IPv4 versus IPv6.
The bias is one-directional: the estimate is low, and it is lowest in exactly the multi-account, shared-subnet architectures that push you toward the Advanced Tier in the first place. Before switching, reconcile the metric against a direct count of attached ENIs across every account you intend to monitor rather than trusting the single number.
Ignoring a resource hands its space back to the pool
Allocations do not release the way people expect, and the documented workaround has a sharp edge.
You cannot call ReleaseIpamPoolAllocation on a VPC CIDR — that API handles manual allocations
only. Attempting it produces The allocation ID is not valid, cannot release allocation for resource type VPC. To free a VPC's allocation you either delete the VPC, or set the resource's monitoring
state to Ignored, after which IPAM releases the allocation on your behalf.
That second option is the trap. From the console documentation:
When a resource is chosen to be ignored, any space allocated to it from an IPAM pool is returned to the pool.
The VPC still exists. Its instances still answer on those addresses. But the pool now considers that
range free, and will hand it to the next requester — and an ignored resource is exempt from overlap
evaluation, so IPAM will not report the collision it just enabled. Using Ignored to tidy up an
allocation is a way to manufacture an overlap with the tool whose purpose is preventing them. Reserve
it for resources genuinely outside IPAM's remit, and prefer a manual allocation to fence off space
that is in use but not IPAM-managed.
Two more details worth knowing before you plan a renumbering:
- Reclaim is not immediate, and the delay is tier-dependent. A released CIDR becomes available for reallocation in a few minutes on the Advanced Tier, but takes up to 48 hours on the Free Tier.
- Releasing an allocation permanently deletes its tags. They are not recoverable.
The numbers on the dashboard are not the numbers you want
Two IPAM readouts invite incorrect alarms.
ipUsage on a VPC is the percentage of the VPC's address space covered by subnet CIDRs — not the
percentage of addresses in use. A fully subnetted VPC with no instances reads 100%. A VPC at 40% with
every subnet full is out of addresses. For subnets, the figure does reflect IPv4 addresses in use, but
IPv6 utilization "cannot currently be calculated" and is simply absent.
IP address history is sampled, not evented. The API notes that changes "are picked up in periodic snapshots, so the start time may have occurred before this specific time." It is strong enough to answer which account owned an address last Tuesday. It is not a forensic timeline, and short-lived assignments between snapshots may not appear at all.
Structural limits you cannot buy your way out of
Most IPAM quotas are adjustable. Three are not, and they constrain the org chart more than the network.
counted here: 1 IPAM per Region and 1 delegated administrator per organization — neither adjustable. 1 resource discovery per Region.
counted here: 5 scopes per IPAM. Additional scopes are always private — a second public scope cannot be created.
counted here: 50 pools per scope, 50 CIDRs per pool, pools nested up to 10 deep.
counted here: Advanced Tier billing, per active IP on attached ENIs — including addresses that never came from this pool.
One IPAM per Region and one administrator per organization are hard limits, so two teams cannot run independent IPAMs in the same Region and IPAM administration cannot be split across accounts.
The scope limit carries a design implication worth stating plainly: because additional scopes are
always private and the public scope is a singleton, scopes are the mechanism for deliberate overlap.
Two disconnected environments that both use 10.0.0.0/16 belong in different private scopes, where
IPAM will correctly decline to call that an overlap.
Getting back out
Deleting the IPAM stops the charges. Downgrading from Advanced to Free is closer to a one-way door, because it requires first deleting:
- private scope pools
- non-default private scopes
- pools with locales different from the IPAM home Region
- non-default resource discovery associations
- pool allocations to accounts that are not the IPAM owner
That list is every artefact of the multi-account, multi-Region design you adopted Advanced to build. There is no downgrade that preserves your pool hierarchy, so the decision to switch is best treated as structural rather than reversible.
A checklist before switching on the Advanced Tier
- Count the active IPs you will be billed for, across every account the IPAM will monitor — not
just the accounts you plan to put in pools. Use
TotalActiveIpCountas a floor, then reconcile against attached ENIs per account, especially in shared subnets. - Decide where prevention comes from. IPAM will report a noncompliant CIDR; an SCP or a Terraform module is what stops one being created.
- Map your unconnected networks to private scopes before building pools, since scopes are how intentional overlap stays out of your overlap report.
- Check whether you need private IPv4 at all. If the goal is IPv6 planning or public IPv4 visibility, the Free Tier covers it.
- Write down the exit criteria. The downgrade path deletes the hierarchy, so the question is whether you are committing, not piloting.
Next
Client IP preservation moves from address planning into the ingress path, where the question becomes what a target sees in the source field once a load balancer sits in front of it.
For the failure this guide's registry is meant to prevent, Lab 09 builds a shared Terraform module with a default CIDR and shows what happens the day two teams that adopted it need to reach the same hub.