Skip to main content

VPC IPAM Issues

This page covers the questions that come up most often with VPC IPAM: an inventory that stays empty, a pool that will not delete, and a bill that lands entirely on one account.

VPC IPAM is a networking capability rather than a security one, so its behaviour differs from the Security Hub engines in ways that matter here. In particular, its data comes from a background sweep AWS runs on its own schedule rather than from a refresh you trigger, and its teardown can stop deliberately rather than fail. Both are covered below.

Why Is My Inventory Empty?​

Problem: VPC IPAM is enabled, every account shows as Enabled, and the Dashboard and Address space pages show nothing. No error is displayed anywhere, and refreshing changes nothing.

Cause: AWS's resource discovery is an asynchronous periodic sweep, not a live query. Prism does not read your VPCs and subnets when you open the page; it reads what AWS's last sweep recorded. Until AWS has completed its first sweep there is genuinely nothing to show, and nothing on the Prism side that a retry would change.

These are the measured timings:

FromTo first dataTypical
Creating the IPAM (first ever enable)The host account's own CIDRs appearup to about 20 minutes
A member account's association completingThat account's CIDRs appearabout 4 minutes
A member account's association completingScope-level data (overlap and compliance state)about 7 minutes

"Enabled, association active, zero rows" is a normal steady state during that window, not a fault.

Prism does not render this as an ordinary empty table, precisely because the two situations must never look alike. While AWS has never completed a sweep you get a distinct "AWS is still taking its first inventory" state with an indeterminate progress bar; once a sweep has completed and genuinely found nothing, you get an empty state that names the scope it searched: "AWS discovered no VPCs, subnets, EIPs or public IPv4 pools in the N accounts × M regions currently in scope." The first means wait; the second means the scope is wrong or the accounts really are empty.

Solution:

  1. Open the Accounts page and expand the accounts you are waiting on. Each account-and-region line carries AWS's own discovery status beside Prism's enrollment phase.
  2. If every line reads active, AWS has accepted the association and the sweep simply has not run yet. Wait. The timings above are the ones to expect. The page polls on its own; Check for results on the cold-start panel asks Prism to re-read AWS immediately, but it cannot make AWS sweep sooner.
  3. If any line reads not-found, this is not a cold start and waiting will never resolve it. See the warning below.
  4. If a sweep has completed and the tables are still empty, check the accounts and regions in scope on the Settings page under Operating regions. A resource in a region you did not select is invisible to IPAM, correctly.
warning

not-found is the one status that never resolves by waiting. It means the account's resource discovery was deleted, or the AWS RAM share that gave the host account access to it was revoked. Everything in that account is missing from every table on every page. The tables still look perfectly clean, because a missing account produces no rows and no error.

Prism draws a warning banner above the results whenever any account is in this state ("N of M accounts are no longer being discovered"), for exactly that reason. Fix it from the Accounts page by retrying the affected account, which re-runs its enrollment. If the share was revoked deliberately in that account, expect it to be revoked again unless whoever revoked it agrees otherwise.

A newly added account reached "Enabled" but still has no data​

Problem: You added a member account, it moved through the enrollment phases and reached Enabled, and yet its resources are absent. An attempt to allocate a CIDR to it from a shared pool is also refused.

Cause: Reaching a completed association is not the same as being usable. AWS reports the association as complete and its discovery status as active while the account is still not "monitored" by IPAM. The account only becomes usable once the discovery sweep has actually run and the account appears in IPAM's own list of discovered accounts. The measured gap is about four and a half minutes past the association completing.

This is why the Accounts page shows both Prism's phase and AWS's discovery state, rather than merging them into one status.

Solution: Wait for the account to appear in the inventory. That appearance is the readiness signal: the first allocation attempt after it appears succeeds. There is nothing to retry, and retrying the enrollment does not shorten the wait.

Why Can't I Delete This Pool?​

Problem: Deleting a pool fails, or disabling VPC IPAM stops with the pool reported as blocked and a message naming a VPC in one of your member accounts.

Cause: A member account holds a live resource-backed allocation from that pool: a VPC that took its CIDR from the pool and still exists. AWS will not release such an allocation on request. Asked to do so, it answers:

The allocation ID … is not valid. Cannot release allocation for resource type VPC. Remove the resource using the corresponding cidr and IPAM will automatically release the allocation.

That instruction (delete the resource) is AWS's only remedy, and there is no alternative API. Prism will never delete a resource in your account, so at that point Prism has done everything it is permitted to do.

Blocked is therefore a reported outcome, not an error. Prism:

  • names the pool, the CIDR, and every resource that blocks it, with its resource id, type, region and owning account;
  • continues with every part of the teardown that is not downstream of a blocked pool, so one blocked pool does not strand the rest of your accounts;
  • stops and waits for you, rather than retrying something that cannot succeed.

Solution:

  1. Read the blocker list. It names the exact resource and the account it lives in.
  2. In that account, delete the VPC, or release the CIDR the VPC took from the pool.
  3. Wait several minutes. IPAM releases the allocation on its own sweep, not immediately. See the warning below.
  4. Return to Prism and click Retry teardown (or retry the pool delete).
warning

The IPAM is still running and still billing while teardown is blocked. A blocked teardown is not a stopped meter. If you cannot remove the blocking resources, use Force delete, described below, rather than leaving the capability in this state.

The allocation is still there minutes after I deleted the VPC​

Problem: The VPC is gone (AWS itself reports it as not found), and the allocation is still listed against the pool. Retrying does not clear it.

Cause: Release is asynchronous and cannot be forced. There is no API that makes IPAM let go of an allocation; it happens when IPAM's own sweep notices the resource is gone. A ghost allocation has been observed to survive more than nine minutes past a confirmed VPC deletion.

Solution: Wait, then retry. Prism's teardown does this for you: it polls the pool until it reports zero allocations before it attempts to deprovision anything, which is the step that avoids the failure below.

note

failed-deprovision is retryable, not fatal. If a pool CIDR is deprovisioned inside the ghost-allocation window, AWS accepts the request, then settles it to failed-deprovision. It looks terminal and reads like a hard failure, but it is not: once the ghost allocation clears, the same operation succeeds. Prism retries it on a bounded ladder rather than giving up, and a failed-deprovision CIDR is safe to retry by hand too.

Force delete​

When the ordered teardown has exhausted its retries (the allocations will not drain, or a deprovision keeps failing), Prism offers Force delete, which is AWS's cascading IPAM delete. It is deliberately not available as a first action, and never runs without an explicit typed confirmation.

What it does, and what it does not do:

DoesDeallocates CIDRs from live VPC resources in private-scope pools, deprovisions IPv4 CIDRs, and deletes the pools, the scopes and the IPAM
Does notDelete any VPC, subnet or Elastic IP. Your resources keep their addresses; only IPAM's record of them goes away
DestroysAll CIDR address history, irreversibly. There is no undo and no export

Billing stops when AWS reports the IPAM deleted.

Why Is the Whole Bill on One Account?​

Problem: The entire VPC IPAM charge appears on the account you nominated as the IPAM host, including the IP addresses that belong to other enrolled accounts. You want it distributed to each account that owns the resources.

Cause: AWS decides this with an IPAM setting called MeteredAccount, and it defaults to ipam-owner. Under that default, the account that owns the IPAM is charged for every active IP address the IPAM manages, across every account enrolled in it. That is AWS's behaviour, not a Prism choice, and it is why the host account is presented as a deliberate decision during setup rather than inferred for you.

The alternative value, resource-owner, charges each resource's own account. Prism cannot use it. AWS requires two things for it that Prism deliberately does not have:

  • AWS Organizations integration, and
  • an IPAM created by a registered delegated administrator.

Prism never touches your AWS Organizations management account and never registers a delegated administrator, for any capability. Both preconditions are therefore permanently out of reach, which is why Prism displays MeteredAccount read-only, never sends it, and does not offer cost distribution as an option. This is a permanent position, not a pending feature.

Solution: There is no setting to change. What you can control is what is metered:

  1. Only the accounts you enrol are metered. Your whole AWS organization is not billed to the host, and in a shared-payer organization, accounts belonging to other customers are neither billed to your host nor visible to you. The enrollment set is the meter.
  2. Reduce the enrollment set or the operating regions. Both are levers on the bill, and both are editable on the Settings page. Removing an account stops its IPs being metered.
  3. Check the estimate before you enable. The setup wizard counts the real number of active IP addresses in the accounts and regions you have selected and shows the estimate inside the panel where you edit those selections, so you can see the number move as you change them.
warning

The host account is chosen once and cannot be changed. No AWS operation moves an IPAM between accounts, and Prism does not offer a re-host path. Moving the charge to a different account means disabling VPC IPAM and enabling it again with a different host. That deletes the IPAM and, with it, all CIDR address history, irreversibly. Choose the host account with the bill in mind.

note

Setting MeteredAccount yourself in the AWS console does not work around this either: the same delegated-administrator precondition applies there, and AWS applies a change lock afterwards. Prism deliberately holds no permission to send the setting at all.

Utilization Is Blank for an IPv6 Pool​

Problem: An IPv4 pool shows a utilization bar and a percentage; an IPv6 pool or prefix shows a dash and no bar.

Cause: AWS does not calculate it. In AWS's own words, the percentage of IPv6 address space in use cannot currently be calculated. There is no value to display.

This is different from 0%. A blank means not computable; 0% means measured and genuinely empty, which is what a freshly provisioned IPv4 range shows. Prism draws no bar rather than drawing an empty one, because rendering every IPv6 prefix as "0% used" would be a false reassurance about address exhaustion, the one thing this page exists to warn you about.

Solution: Nothing to fix. Judge IPv6 pools by their allocations rather than by a utilization figure. Note also that organization-wide utilization rollups and "most-used" rankings exclude IPv6 ranges entirely rather than counting them as zero, so those figures describe your IPv4 space.

I Can Only Add Four Member Accounts​

Problem: Enrollment refuses a fifth member account, naming a limit, even though you have many more accounts onboarded in Prism.

Cause: AWS's default quota is five resource-discovery associations per IPAM, and the IPAM's host account consumes one of them with its own association. Four member accounts is what remains. The limit is AWS's, and it is per host account.

Prism reads your host account's applied quota rather than assuming the default, so a quota that has already been raised is honoured. It also refuses before enabling anything rather than half-enrolling and failing partway. A partially enrolled IPAM is the worst outcome available, because the meter is already running by then.

Solution:

  1. The refusal names your current applied ceiling and how many accounts you asked for.
  2. It offers to file an AWS quota-increase request sized to your account count. Prism never files one without your explicit approval, because the request opens a support case on your AWS account.
  3. Approve it, and Prism files the request and then watches for the increase. When AWS raises the applied quota, enrollment unblocks on its own; Prism confirms the raise with AWS rather than taking anyone's word for it.
  4. If you would rather not wait, enrol up to the current ceiling now and add the rest once the increase lands.

Still Having Issues?​

If none of the above resolves your VPC IPAM problem:

  1. Check the Accounts page for per-account, per-region status: both Prism's phase and AWS's discovery state are shown there, and most VPC IPAM problems are visible on that one page.
  2. Confirm the accounts and regions you expect are actually in scope, on the Settings page.
  3. Verify that the accounts involved are onboarded in the Admin Portal under AWS Accounts.
  4. Contact CloudKeeper support with your realm name, the host account id, the affected account and region, and the exact status text shown on the Accounts page.