AWS IPAM (Amazon VPC IP Address Manager) is a VPC feature that plans, tracks and monitors IP addresses across your AWS accounts and Regions. You carve your private range into pools, and every new VPC gets its CIDR from a pool instead of from someone's memory, so two VPCs can't quietly land on the same range.
Two VPCs, both 10.0.0.0/16, and now they need to talk. If you run a handful of accounts, you've likely met this one. Overlapping CIDRs can't be routed to each other, and "the initial VPC CIDR block allocated to your VPC cannot be changed or deleted" (REL02-BP03). The only fix is a new VPC, which is why teams end up re-creating VPCs mid-migration.
You'll see what IPAM costs, a pool plan for 3 to 15 accounts, the Organizations setup, and a path for existing VPCs.
Private IPv4 across accounts needs the Advanced Tier, at $0.00027 per active IP per hour or about $0.19 per IP per 30-day month.
How IPAM keeps two accounts from getting the same CIDR
IPAM has four building blocks (How IPAM works):
- A scope is one network's IP space. Every IPAM gets a default private and public scope.
- A pool is a set of contiguous CIDRs. Pools nest: top-level, Regional, environment.
- An allocation is a CIDR a pool hands to a VPC or a child pool.
- A locale is the Region a pool serves. A VPC only draws from a pool with its Region as locale, and a locale can't be changed.
The IPAM runs from a home Region, and every pool locale must be one of its operating Regions.
Prevention comes from the gap between managed and monitored (CIDR monitoring). A VPC created from a pool is Managed: IPAM checked pool rules and existing allocations before returning a CIDR. A VPC with a typed CIDR starts Unmanaged, and IPAM can only mark it Overlapping once it collides with another CIDR in the same scope.
The active IPs in those VPCs are what you pay for, so price them before designing anything.
What AWS IPAM costs: Free vs Advanced Tier
The Free Tier covers one Region and one account. It includes BYOIP, org-wide Public IP Insights and private IPv6 management, but not private IPv4 management, pool sharing or IP history. Private IPv4 across accounts means the Advanced Tier.
Advanced costs $0.00027 per active IP address per hour (Amazon VPC pricing), the same in all 36 Regions on AWS's Price List. A 30-day month comes to $0.1944 per IP.
An active IP is an address or prefix on an elastic network interface (ENI) attached to a resource such as an EC2 instance. That definition sets the bill:
- IPs on unattached ENIs aren't billed.
- A /28 IPv4 prefix on an attached ENI counts as one active IP.
- Unused pool space is free.
- IPAM bills every active IP in the VPCs it monitors, pooled or not, member accounts included.
Budget on the pricing page, whose organization example bills 10,000 member-account IPs. If you've read that private IP monitoring is free inside an organization, don't plan on it.
| Active IPs | Monthly IPAM cost (30 days) | Typical org shape (illustrative) |
|---|---|---|
| 500 | $97.20 | 3 to 5 accounts, small ECS or EC2 footprint |
| 1,500 | $291.60 | 8 to 10 accounts, mixed workloads |
| 5,000 | $972.00 | About 15 accounts, or one pod-heavy EKS cluster |
| 7,000 | $1,360.80 | The pricing page's Advanced example |
Kubernetes moves this number most. The Amazon VPC CNI gives each pod a secondary IP on the node's ENI by default, so by my reading each pod IP counts. With prefix delegation it assigns /28 prefixes, each billed as one.
Cost Explorer files every Region under the home Region's usage type, such as USE1-IPAddressManager-IP-Hours.
Make each account pay for its own IPs
By default the IPAM owner account pays for everything. Set Metering mode (MeteredAccount) from ipam-owner to resource-owner and each account pays for the active IPs it owns. Charges still consolidate to the payer, and members see IPAddressManager usage in their own Cost Explorer.
This cost distribution requires Organizations integration, an IPAM created by the delegated admin, and a home Region that isn't opt-in.
The timing is strict (cost distribution). The change takes effect after 24 hours, you can only opt out within those 24 hours, and then it locks for 7 days. Decide before enabling. Warn account owners and finance too, because members get IPAM line items without owning an IPAM.
Is IPAM worth it for 3 to 15 accounts?
In my view it pays off once VPC creation leaves one person's hands: several teams, vended accounts with their own VPC, VPCs you'll connect, or a second Region.
When one engineer creates every VPC, a written /8 plan is enough, and the AWS VPC Subnet Calculator splits each VPC CIDR across Availability Zones. Revisit when VPC creation goes self-service.
The cheapest evidence is a Free Tier IPAM. It shows "Your estimated IPAM total active IP count" across your organization; multiply by $0.1944 for the monthly Advanced bill. It can be off for shared subnets, so treat it as a sizing number, not an invoice. Upgrading is a tier edit; downgrading takes a teardown.
Design an AWS VPC IPAM pool hierarchy by Region and environment
The top-level 10.0.0.0/8 pool gets locale None because it never allocates to a VPC, so auto-import isn't available there. Regional pools under it set the locale, and environment pools sit beneath each Region. AWS's IPAM best practices note this layout supports route summarization.
First, reserve ranges used on-premises or by VPN partners with a custom allocation, so IPAM never hands them out.
Each environment pool gets allocation rules: a default netmask, a minimum (the largest block allowed) and a maximum (the smallest). You can also require resource tags, which blocks VPC creation when a tag is missing. The example below requires none.
Share each environment pool through AWS RAM with its OU, using the OU ARN as principal, so your OU structure decides who draws from which range. My recommended starting plan (not an AWS requirement):
| Pool | CIDR | Locale | Default / min / max netmask | Shared with |
|---|---|---|---|---|
| Top-level | 10.0.0.0/8 | None | n/a | Nobody |
| eu-west-1 | 10.0.0.0/12 | eu-west-1 | n/a | Nobody |
| eu-west-1 prod | 10.0.0.0/14 | eu-west-1 | /20 · /16 · /22 | Production OU |
| eu-west-1 non-prod | 10.4.0.0/14 | eu-west-1 | /21 · /18 · /24 | Development OU |
| eu-west-1 sandbox | 10.8.0.0/16 | eu-west-1 | /24 · /22 · /26 | Sandbox account |
| us-east-1 | 10.16.0.0/12 | us-east-1 | Same three child pools | Nobody |
10.0.0.0/12 holds 16 /16 blocks: prod and non-prod take 4 each, sandbox 1, leaving 7 spare. The prod pool fits 64 /20 VPCs, and 10.32.0.0 upward stays free for new Regions. That's 9 pools of the 50-per-scope quota, at depth 3 of 10.
Enable IPAM across AWS Organizations
Order matters, because the wrong console leaves IPAM blind to your accounts.
- Pick a member account, ideally a dedicated network account, as the organization's single IPAM admin. The management account can't be this delegated administrator.
- From the management account, delegate in the IPAM console (Organization settings, Delegate) or with the CLI below. Only this path creates the
AWSServiceRoleForIPAMservice-linked role. Enabling trusted access in Organizations or runningregister-delegated-administratorskips the role, so IPAM can't monitor your accounts (Organizations integration). - In the admin account, create the IPAM in your main Region with your operating Regions, allow data replication from source accounts, and pick the tier.
- Enable RAM sharing with Organizations, then create the pool share in the IPAM home Region, not the pool's Region, with
AWSRAMDefaultPermissionsIpamPool. - Create VPCs with "IPAM-allocated IPv4 CIDR block" instead of typing a CIDR.
The management account needs ec2:EnableIpamOrganizationAdminAccount, organizations:EnableAwsServiceAccess, organizations:RegisterDelegatedAdministrator and iam:CreateServiceLinkedRole.
aws ec2 enable-ipam-organization-admin-account \
--delegated-admin-account-id 111122223333
# { "Success": true }
Then run aws iam get-role --role-name AWSServiceRoleForIPAM in a member account. NoSuchEntity means the role was never created, usually because delegation went through Organizations. Redo it from the IPAM console.
Create the pool and the VPC in code
The IPAM account defines the prod pool with the L1 ec2.CfnIPAMPool, and the workload account requests a /20 from it:
import * as ec2 from 'aws-cdk-lib/aws-ec2';
declare const privateScopeId: string, euWest1PoolId: string, prodPoolId: string;
// IPAM admin account, home Region
new ec2.CfnIPAMPool(this, 'ProdPool', {
addressFamily: 'ipv4',
ipamScopeId: privateScopeId,
sourceIpamPoolId: euWest1PoolId,
locale: 'eu-west-1',
provisionedCidrs: [{ cidr: '10.0.0.0/14' }],
allocationDefaultNetmaskLength: 20,
allocationMinNetmaskLength: 16,
allocationMaxNetmaskLength: 22,
autoImport: true,
});
// Production workload account, eu-west-1, after the RAM share
new ec2.Vpc(this, 'AppVpc', {
ipAddresses: ec2.IpAddresses.awsIpamAllocation({
ipv4IpamPoolId: prodPoolId,
ipv4NetmaskLength: 20,
defaultSubnetIpv4NetmaskLength: 24,
}),
});
After deploy the VPC should hold a /20 inside 10.0.0.0/14 and show as Managed and Compliant in the IPAM console. Three details:
- Without
defaultSubnetIpv4NetmaskLength, every subnet group needs acidrMaskor synthesis fails (CDK aws_ec2 README). - A child pool's CIDR must be free space in its source pool.
- Changing the pool or netmask on an AWS::EC2::VPC replaces it, as do
Locale,AddressFamily,SourceIpamPoolIdandIpamScopeIdon an AWS::EC2::IPAMPool.
Adopt IPAM when your VPCs already exist
Once delegated, IPAM discovers VPCs in every member account and operating Region. VPCs outside all pool CIDRs stay Unmanaged but monitored for overlap; a 172.31.0.0 default VPC never maps to a 10.0.0.0/8 pool.
Enable auto-import on Regional or environment pools to manage in-range VPCs. The import rules:
- The pool needs a locale.
- Import ignores allocation rules, so a VPC can arrive Noncompliant.
- Of overlapping CIDRs, only the largest is imported; of identical ones, one at random.
- A VPC covering an already-allocated smaller CIDR isn't imported.
Importing doesn't touch workloads or connectivity, and it can't re-address anything. Say prod VPC A and staging VPC B both use 10.0.0.0/16. IPAM marks both Overlapping, and auto-import takes one at random. The fix is a new staging VPC with a /21 from the non-prod pool, a workload move, then deleting VPC B. A secondary CIDR adds room but leaves the overlapping initial CIDR in place (re:Post).
Networks that reuse ranges on purpose, like an acquisition you'll never connect, belong in a separate private scope so they stop raising overlap alarms.
Limits and mistakes to check before you commit
The IPAM quotas that shape the design:
| Quota | Default | Adjustable | What it means for you |
|---|---|---|---|
| IPAMs per Region | 1 | No | No side-by-side test IPAM |
| IPAM administrators per organization | 1 | No | Choose the network account once |
| Pools per scope | 50 | Yes | The 9-pool plan uses under a fifth |
| Pool depth | 10 | Yes | Region plus environment uses 3 |
Going from Advanced back to Free means deleting private-scope pools, non-default private scopes, pools outside the home Region, non-default resource discovery associations, and allocations to other accounts.
Tear down in order: RAM share, allocations, provisioned CIDRs, pools and non-default scopes, then the IPAM (Delete an IPAM). Cascade delete, blocked by any public-scope pool, handles the IPAM side and leaves VPCs and CIDRs untouched.
Frequently Asked Questions
Is AWS IPAM free?
Can you use IPAM with a single AWS account?
Do you need AWS Control Tower to use IPAM?
What happens to IPAM allocations when an account leaves the organization?
Where to start
- AWS IPAM's Advanced Tier is the price of multi-account private IPv4 planning.
- Design pools by Region, then environment, and share each with its OU through AWS RAM.
- Delegate the IPAM admin from the IPAM console, not the Organizations console.
This week, create a Free Tier IPAM in your network account and multiply its active IP estimate by $0.1944. For the OU design behind these pools, read the AWS multi-account strategy, then the cloud foundation guide.
Next step