VPC IPAM
Amazon VPC IPAM in Prism answers a question none of the other Organization Services answer: where is your organization's IP address space, who owns it, how much of it is used, and where does it collide? From one interface you can browse every VPC, subnet, Elastic IP and public IPv4 address AWS discovers across your enrolled accounts and Regions, read utilization down a pool hierarchy, find two accounts that have quietly built on the same CIDR, hand address space out from pools, and manage which accounts are being discovered at all.
Enabling VPC IPAM starts a usage meter on your own AWS bill, and that meter scales with your footprint.
AWS VPC IPAM's Advanced tier is mandatory for any multi-account use, and Advanced is billed at $0.00027 per active IP per hour (roughly $0.197 per IP per month) across every account and Region you enrol, including addresses that sit in no IPAM pool at all. There is no free multi-account IPAM. Read Advanced tier is mandatory and billed before you run the setup wizard.
VPC IPAM Is Not a Security Capability
Every other capability under Security Hub reports findings: a misconfiguration, a threat, a vulnerability, an over-permissive policy. VPC IPAM reports none. It is network address management, and it lives here because it is an organization-wide AWS service that Prism enables across your accounts through the same enrollment machinery, not because it detects anything.
The practical consequences:
- There are no findings, no severities and no workflow states. Nothing from IPAM appears in the unified Security Hub findings inbox, and there is no severity filter anywhere in these pages.
- There is no IPAM tile on the Security Hub Overview page, because that page is a grid of finding counts and IPAM would contribute a permanent zero. IPAM appears instead in its own Networking panel on Configuration > Capabilities.
- The numbers on the Dashboard are inventory and utilization figures, not a posture score. A high number is not a bad number.
Advanced Tier Is Mandatory and Billed
AWS offers VPC IPAM in two tiers, and only one of them can do what this capability exists to do.
| Tier | What it covers | Cost |
|---|---|---|
| Free | A single Region in a single account. Nothing cross-account. | Free |
| Advanced (what Prism uses) | Multiple Regions, multiple accounts, cross-account resource discovery, overlap and compliance state, pool hierarchies, Public IP Insights | $0.00027 per active IP per hour |
This is not a packaging preference Prism could work around. AWS refuses the cross-account association outright on the Free tier. An attempt to associate a second account's resource discovery returns:
UnsupportedOperation: The operation is not supported by your IPAM Tier.
You cannot associate more than one resource discovery to your IPAM.
So there is no free multi-account product. The cross-account inventory, the overlap detection and the utilization figures this capability is built for are Advanced-only, and Prism creates the IPAM at the Advanced tier from the moment it creates it at all.
Advanced to Free is not an undo. Downgrading an existing IPAM back to the Free tier is blocked by AWS until private-scope pools, non-default private scopes, off-home-locale pools, non-default discovery associations and non-owner allocations have all been cleaned up. In practice, once a real multi-account deployment exists, the way out is teardown, not a tier change.
What the Meter Counts
The rate is charged per active IP per hour, and "active IP" is AWS's definition, not Prism's. The scope of what is metered is the part customers are most often surprised by:
- Every enrolled account, and every operating Region you selected. Accounts you did not enrol are neither discovered nor metered.
- Addresses that are in no pool. An IP does not have to have been handed out by an IPAM pool to be counted; it only has to be discovered. A default VPC nobody has touched in three years counts.
- Both IPv4 and IPv6 addresses on discovered resources.
The setup wizard shows you a Prism estimate of your active-IP count before you commit, counted from attached network interfaces in exactly the accounts and Regions you selected. It is labelled a lower bound, deliberately: AWS's own meter can see addresses Prism cannot enumerate before the IPAM exists. See Step 4: Scope and cost.
The two levers that bound the bill are which accounts you enrol and which operating Regions you select. There is no organizational-unit exclusion control, and that is not an omission: under Prism's architecture a resource discovery covers exactly one account, so there is nothing for an OU exclusion to exclude. Add and remove accounts from the Accounts page; change Regions from Settings.
Prices quoted here and in the product are indicative us-east-1 list prices, shown for orientation. Consult the AWS VPC pricing page for authoritative and Region-specific rates.
No Management Account and No Delegated Administrator
If you know AWS VPC IPAM, you expect a delegated administrator. Prism does not use one, anywhere, ever.
AWS's own documented model is to enable IPAM from the AWS Organizations management account, register a delegated administrator, and let trusted access fan a resource discovery out into every member account. Prism does none of that. It holds no route to your management account, changes no AWS Organizations setting, registers no delegated administrator and carries no organizations:* permission at all.
What Prism does instead:
- You nominate one enrolled account as the host. Prism creates the IPAM there, in that account, through that account's own access role.
- In every other enrolled account, Prism creates a resource discovery, an IPAM component that monitors the account it belongs to.
- Each member account shares its own resource discovery to the host account through AWS RAM.
- The host associates each shared discovery to the IPAM.
Every one of those calls is made by an ordinary member account using credentials Prism already holds for it. There is no privileged account in the picture.
| Consequence | What it means for you |
|---|---|
| Only accounts you enrol are visible | An account you have not added is not discovered, not inventoried, and not metered. Coverage is opt-in per account, not organization-wide by default. |
| The bill lands on the host account | AWS charges the IPAM's owner. See Settings for why Prism cannot redistribute it. |
| There is a hard ceiling on member accounts | The association quota is what bounds enrollment. See The four member ceiling. |
| No AWS root email addresses are needed | Unlike GuardDuty, Macie and Detective, there is no invitation flow keyed on root email, and no EmailVerificationFailed failure mode. |
The Four Member Ceiling
AWS caps resource discovery associations per IPAM at 5 by default, and the host's own automatically created association consumes one of them. That leaves four member accounts on a fresh host account.
This is the limit most tenants meet first, so Prism handles it explicitly rather than letting you discover it as a failure halfway through enablement:
- The setup wizard reads the live applied quota on your host account (not a hard-coded 5) and shows it as you pick accounts. If your quota has already been raised, the wizard knows.
- Selecting more accounts than the ceiling allows disables Next, with the ceiling and your selection both named. Prism refuses at the edge rather than half-enrolling and failing on the last association with the meter already running.
- The quota is adjustable. From the wizard, Prism can file a Service Quotas increase request sized to your account count, but only on your explicit approval, because filing one opens a support case on your account.
- Prism then polls the applied value itself and unblocks enrollment when AWS has actually raised it. You do not have to come back and tell it.
An increase request needs a qualifying AWS Support plan on the host account. If your account cannot file quota requests automatically, Prism says so and points you at raising it manually rather than retrying a request that will never succeed.
Discovery Is a Sweep, Not a Query
AWS VPC IPAM builds its inventory with a periodic background sweep. It is not a live read-through of your accounts, and Prism cannot make it run on demand.
This produces one state that looks broken and is not: enabled, zero rows.
Measured cold-start timings:
| From | To | Typical |
|---|---|---|
| Creating the IPAM | The host account's own first discovered CIDRs | up to about 20 minutes |
| A member's association completing | That member's CIDRs appearing | about 4 minutes |
| A member's association completing | Scope-level compliance and overlap data | about 7 minutes |
Prism distinguishes the cold start from an empty estate rather than rendering both as "no results":
- While AWS has never completed a sweep, the Dashboard, Address Space and the other inventory pages show "AWS is still taking its first inventory", with an indeterminate progress bar and one status chip per account-and-Region association, so you can see that the associations themselves are healthy.
- Once a sweep has completed and genuinely found nothing, the empty state names the scope it searched: how many accounts, how many Regions, as of when. An honest zero is written differently from a cold start on purpose.
There is nothing to retry during a cold start and nothing is wrong. A Check for results button is offered so you can force a look, but it cannot make AWS sweep sooner.
Enrolled Is Not the Same as Usable
An account reaching Enabled on the Accounts page means its resource discovery is associated to the IPAM. It does not yet mean the account can allocate address space from a pool.
AWS requires the account to be monitored (that is, to have actually appeared in a completed discovery sweep) before it will honour an allocation from a pool shared to it. Until then AWS refuses with:
UnsupportedOperation: The operation AllocateIpamPoolCidr is not supported.
Account 857639285487 is not monitored by IPAM ipam-0fd4edcdfbbcb27cd.
The measured gap between the association completing and the account becoming usable is about 4.5 minutes. Prism carries that readiness as a separate signal on the Accounts page and warns before you share a pool to an account that is not there yet, rather than letting you create a share whose first use fails with an error that names the IPAM instead of the missing step.
Teardown Can Be Blocked
Disabling VPC IPAM is not a one-shot operation like every other capability's, and it has an outcome none of them have: blocked.
Prism will never delete a resource in your account. So if a member account holds a live VPC whose CIDR was allocated from a Prism-managed pool, Prism cannot delete that pool. AWS's only remedy is deleting your VPC, and that is a line Prism does not cross. Teardown reports the blocking resources by id and account and waits for you.
There is an escape hatch (DeleteIpam --cascade) that gets past it, offered behind explicit confirmation, and it destroys all CIDR allocation history irreversibly. And there is residue neither path removes.
Teardown has its own page, and it is worth reading before you enable, not after.
If teardown ends in blocked or partial failure with the IPAM still alive, you are still being billed. Advanced-tier charges run until AWS reports the IPAM deleted. Prism says so persistently rather than in a banner that scrolls away.
Navigation
VPC IPAM is accessible from the Security Hub sidebar under VPC IPAM. The sidebar has seven rows; these docs group them into six pages:
| Page | Covers |
|---|---|
| Dashboard | Address-space totals, worst utilization, compliance and overlap counts, discovery health, the metered active-IP count and running cost estimate, and the refresh control |
| Address Space | The Address space and Public IPs screens: everything AWS discovered, its posture, and per-CIDR address history |
| Pools | The Pools tree, pool detail, and the Allocations ledger |
| Accounts | The Accounts screen: enrollment and discovery health in one grid |
| Settings | Operating Regions, tier and cost, permissions, and the Danger zone |
| Teardown | What disabling actually does, the blocked outcome, force delete, and the residue ledger |
Setup has its own page: Enabling VPC IPAM.
The VPC IPAM sidebar group is present whether or not IPAM is enabled, the same as AWS Config's. Clicking Dashboard on a tenant that has never enabled it lands you on the setup wizard, which is the correct destination.
On Configuration > Capabilities, VPC IPAM appears in its own Networking panel below the detection engines, not in the engine grid. Its copy always states that the paid Advanced tier is required, and its button reads Enable before setup and Manage afterwards.
Prerequisites
Before using VPC IPAM, ensure the following:
- Your organization has been onboarded to Prism by CloudKeeper
- Security Hub has been enabled for your organization as a beta feature by CloudKeeper
- Security Hub access enabled for your account by an Admin in Preferences > Admin Management
- At least two AWS accounts onboarded in Prism: one host plus at least one member. A host-only deployment has no cross-account product and is not supported
- Acceptance that the host account's AWS bill will carry an Advanced-tier IPAM charge for every account you enrol
You do not need AWS management-account access, a delegated administrator, AWS Organizations trusted access, or any account's AWS root email address.
Related Pages
- Enabling VPC IPAM, The two-stage consent flow, host selection, Regions, and the cost gate
- Dashboard, Totals, utilization, posture counts, and the running cost estimate
- Address Space, Discovered inventory, posture, public IPs, and address history
- Pools, The pool hierarchy, provisioning, allocation, and pool sharing
- Accounts, Enrollment and discovery health, and the cold start
- Settings, Operating Regions, tier and cost, and permissions
- Teardown, The blocked outcome, force delete, and the residue ledger
- Configuration, Where VPC IPAM sits among the Security Hub capabilities
- Security Hub Issues, Troubleshooting enablement and discovery problems