Accounts
The Accounts page fuses two things every other capability keeps apart: enrollment (how far Prism got setting an account up) and discovery health (what AWS says about that account right now). They are on one grid because splitting them would force you to correlate two pages to answer the only question that matters when something is wrong: why is this account missing from every table?
Accessing Accounts
In the Security Hub sidebar, click VPC IPAM > Accounts.
If IPAM has not been set up yet, the page shows an info banner with a Go to setup button that opens the setup wizard.
Configuration Card
At the top, a card summarises the deployment:
- Host account: the account that owns the IPAM, shown with a lock. It cannot be changed
- Home Region: where the IPAM lives
- Operating Regions: the Regions being discovered
- Association ceiling: the live applied quota on the host account, and how many member slots remain
- Status: for example Enabled, Partial Failure, or In Progress
There is no delegated administrator and no admin chip on any row. Every member account holds its own resource discovery and shares it to the host; the host is the account that owns the IPAM, not an administrator over the others. No AWS root email addresses are involved at any point.
The Accounts Grid
One row per enrolled account, expanding to a line per account-and-Region pair.
| Column | Contents |
|---|---|
| Account | Account name (account ID), or the bare account id if Prism has no name for it |
| Role | Host or Member |
| Status | Prism's enrollment phase for the account, with any error beneath it |
| Discovery | AWS's own discovery status for the association |
| Last successful discovery | When AWS last completed a sweep for this account and Region |
| Ready to allocate | Whether the account has appeared in a completed sweep and can therefore allocate from a shared pool |
| Retries | How many times the account has been retried, or - |
| Actions | Retry on failed rows, and Remove |
Prism's Phase and AWS's Discovery Status Are Different Things
The Status column is how far Prism got. The Discovery column is what AWS reports about the association. They answer different questions and they can legitimately disagree.
| Prism phase | Meaning |
|---|---|
| Pending | Enrollment submitted, not started |
| Granting access | Prism is attaching the IPAM permissions policy to the account's access role and waiting for it to take effect |
| Enabling | The IPAM (host) or the resource discovery (member) is being created |
| Sharing | The member is sharing its resource discovery to the host through AWS RAM |
| Accepting | The host is accepting the RAM invitation, where one was raised |
| Associating | The host is associating the shared discovery to the IPAM |
| Enabled | The association is established |
| Failed | Enrollment failed; the error is beneath the chip |
| Removing | Removal is in progress |
| Disabled | The capability was disabled, or the account was removed |
| AWS discovery status | Meaning |
|---|---|
active | AWS is discovering this account |
not-found | AWS can no longer reach the discovery. See below |
Granting access is the phase that takes the longest. Prism attaches the policy and then waits for IAM to make it usable, which takes minutes per account. A row sitting here is healthy, not stuck. The page polls throughout.
Discovery Health Is Judged by the Absence of a Failure Code
AWS does not report "this account is healthy". It reports problems. So health here is the absence of a failure code, combined with a successful sweep timestamp, and that shapes how you read the grid:
| Failure code | Last successful discovery | Read it as |
|---|---|---|
| None | A timestamp | Healthy. AWS is discovering this account |
| None | Empty | Cold. AWS has not completed a first sweep yet. Nothing is wrong |
| Present | Anything | Broken. The code is AWS's explanation and is the thing to read before acting |
"No failure code" is not the same as "confirmed working" on an account that has never swept. An account with no failure code and no successful discovery time is in the cold state, not the healthy one, and Prism distinguishes the two rather than folding an unknown into a pass.
The Cold Start
Enrollment completing is not data appearing. AWS's discovery is a periodic background sweep, not a live query, and Prism cannot make it run sooner.
| From | To | Typical |
|---|---|---|
| Creating the IPAM | The host account's 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 |
| A member's association completing | That member being able to allocate from a shared pool | about 4.5 minutes |
During the cold window, accounts show as enrolled with an empty Last successful discovery, and the inventory pages show "AWS is still taking its first inventory" rather than an empty table.
There is nothing to retry during a cold start. Retry on a healthy-but-cold account tears down and rebuilds an association that was fine, and restarts the clock. If the phase is Enabled and there is no failure code, wait.
Ready to Allocate Is a Separate Signal
An account reaching Enabled means its resource discovery is associated to the IPAM. It does not mean the account can allocate address space from a pool shared to it.
AWS requires the account to be monitored (to have actually appeared in a completed sweep) before it honours an allocation, and refuses until then with an error naming the IPAM rather than the missing step:
UnsupportedOperation: The operation AllocateIpamPoolCidr is not supported.
Account 857639285487 is not monitored by IPAM ipam-0fd4edcdfbbcb27cd.
The Ready to allocate column carries that answer directly, derived from the accounts AWS reports as discovered. Sharing a pool checks it before creating a share.
What not-found Means
not-found is the silent-breakage signal, and it is the most important status on this page. It means AWS can no longer reach the account's resource discovery. Anything in that account is missing from every inventory table, however clean those tables look.
There are two causes and they have different fixes:
| Cause | What happened | Fix |
|---|---|---|
| The RAM share was revoked | Someone deleted the resource share in the member account, so the host no longer has access to the discovery | Retry the account. Prism re-creates the share and re-associates |
| The resource discovery was deleted | Someone deleted the resource discovery itself in the member account | Retry the account. Prism re-creates the discovery, shares it and re-associates |
Prism distinguishes the two in the row's error message rather than reporting a generic failure, because the second one also freed that account's one-per-Region discovery quota and the first did not.
A not-found account also consumes an association slot until it is repaired or removed. With a default ceiling of four member accounts, one broken account can be the reason a fifth will not enrol.
Whenever any account is not-found, a non-dismissible warning appears above the results on the Dashboard and the inventory pages:
N of M accounts are no longer being discovered. Their resource discovery was deleted or their RAM share was revoked, so anything in those accounts is missing from every table on this page, however clean it looks.
A coverage gap is always drawn above the results, because missing data makes the results look better, not worse.
Accounts That Left Your Organization
Three states (isolate-in-progress, isolate-complete and restore-in-progress) mean the account that owns the resource was removed from your AWS organization. They appear on any IPAM resource and they are not ordinary progress.
Prism labels them as isolation rather than as a failure, and refuses to retry them. Burning a retry ladder and a multi-minute permission wait against an account that has departed is pure waste, and the account will not come back because Prism asked again.
Removing an isolated account from IPAM still works and is the right move: it releases the association slot the departed account is holding.
Adding Accounts
The Not enrolled table lists onboarded accounts IPAM is not currently discovering, including previously removed ones, which are labelled as such.
- Select the accounts to enrol.
- Click Add N to IPAM.
- Each account walks the enrollment phases: Pending, Granting access, Enabling, Sharing, then Associating.
Adding accounts here runs every guard the setup wizard runs. This is not a lighter path:
- The association-ceiling pre-flight, counting existing live associations plus the host's own. Over the ceiling, the add is refused before anything is created, with the quota-increase path offered
- The tenant-isolation check on every account id
- The ownership-tag check, which refuses an account whose one allowed resource discovery is already held by a different Prism tenant
Adding an account extends the meter. Every account you add is discovered across every operating Region, and every active IP in it is billed at the Advanced-tier rate on the host account's bill. The confirmation says so and shows the estimated impact before you commit.
Retrying a Failed Account
If an account shows Failed, a Retry action appears on its row.
- Read the error and AWS's discovery status first. If AWS reports a failure code, retrying will not help until the underlying cause is addressed.
- Click Retry. The account re-enters enrollment from the beginning, including the permission grant.
- If the retry fails on permissions, open the Permissions tab in Settings, repair the roles, then retry.
The Retries column records how many attempts an account has had.
A quota exhaustion is not retryable and Prism does not pretend otherwise. If enrollment failed because the association ceiling is full, the row says so, names the quota, and Retry is refused. Raising the quota (from the configuration card or the setup wizard) is the only thing that changes the outcome.
Retrying one account never disturbs the others. Members are enrolled independently, so partial failure is a per-account condition to work through, not a state that has to be cleared before the working accounts produce inventory.
Removing an Account
- Click Remove on the account's row.
- A confirmation dialog names the account, states what will be deleted, and warns about the discovery consequence below.
- The account enters the Removing phase, then drops out of the grid and reappears in Not enrolled, flagged as previously removed.
Removal disassociates the account's resource discovery from the IPAM, deletes the RAM share, deletes the resource discovery, drops the account's cached inventory, and detaches the IPAM permissions policy from its access role.
Removing an account is cost-bearing in reverse and structurally load-bearing, and the dialog says both.
- In reverse: removing an account stops metering its IPs, so it lowers your bill. That is usually the intent.
- Structurally: deleting that account's resource discovery flips the host's association for it to
not-found. That is expected during a removal, not a fault, but it is the same status a revoked share produces, so it is worth knowing which one you are looking at.
Removing the host account is not possible. The host owns the IPAM, and there is no AWS operation that moves an IPAM between accounts. Changing hosts means teardown and re-enabling, which destroys all CIDR address history irreversibly.
Removing an account does not delete anything Prism adopted. A resource discovery that already existed when Prism enrolled the account is left running, and Prism simply stops using it. See Teardown for the full residue ledger.
When Enrollment Changes Are Unavailable
Add, Retry and Remove are disabled unless the configuration has settled, which means status Enabled or Partial Failure.
- While an operation is running, a banner says enrollment changes are paused until it finishes, and the page polls.
- If setup failed, that banner is suppressed: nothing is going to finish. Re-running setup is the way out, and the failure banner at the top of the page is the accurate one.
Live Auto-Polling
While any account is in an active phase, or the configuration itself is mid-operation, the page polls and updates chips and progress on its own.
The inventory pages poll much less often than this one, and deliberately. Polling every few seconds against a sweep that takes twenty minutes would be several hundred wasted requests for one result, so the cold-start view checks at a slower cadence and offers a Check for results button when you want to look now.
Related Pages
- Enabling VPC IPAM, The wizard, the association ceiling, and the quota-increase path
- Dashboard, Discovery-health rollup and the coverage-gap banner
- Address Space, What the discovered accounts actually reported
- Pools, Sharing a pool, and why readiness is checked first
- Settings, Operating Regions, tier and cost, and repairing account permissions
- Teardown, What removal and disabling leave behind
- Security Hub Issues, Troubleshooting enrollment and discovery failures