Enabling VPC IPAM
The VPC IPAM setup wizard walks you through five steps and two separate submissions. The first submission creates no AWS resource and costs nothing; the second one is where the Advanced-tier meter starts. That split is deliberate, and understanding it is the difference between a cost decision you made and a cost decision you discovered.
Accessing the Wizard
- In the Security Hub sidebar, open VPC IPAM > Dashboard. If IPAM has never been configured for your organization, that route renders the wizard.
- From Configuration > Capabilities, find the Networking panel below the detection-engine grid and click Enable on the VPC IPAM card.
The sidebar group is always present, so both routes work on a tenant that has never enabled IPAM.
Two Stages, and Only the Second One Bills
Every other capability in Prism has a single Enable click. VPC IPAM has two, because the cost estimate cannot be computed until Prism has read-only access into your accounts, and asking you to consent to a bill before showing you a number is not consent.
| Stage | What you click | What happens in AWS | Is anything billing? |
|---|---|---|---|
| Begin | Next through the wizard to the cost step | Prism attaches its read permissions to each selected account's access role and counts the IP addresses attached to network interfaces in the accounts and Regions you chose | No. No IPAM, no resource discovery, no RAM share: nothing has been created |
| Activate | Enable IPAM (Advanced tier — billed) | Prism creates the IPAM in the host account, creates and shares a resource discovery from every member, and associates them all | Yes. From the moment the IPAM exists |
Abandoning between the two stages is free and complete. A draft configuration that is waiting for your consent can be discarded at any time: Prism detaches every permission it attached and deletes the draft. No AWS resource was ever created, so there is nothing to clean up and nothing to be billed for.
The consent checkbox on the cost step is enforced by the server, not just by the browser. Prism's activate request is refused outright if the acknowledgement is missing, and the activation is recorded as its own audit entry, separate from the enrollment decision, so your audit log can show who approved the spend and what number was on screen when they did.
Wizard Steps
| Step | Name | What you configure |
|---|---|---|
| 1 | Host account | The one account that will own the IPAM, and pay for it |
| 2 | Accounts | The member accounts to enrol and discover |
| 3 | Regions | The home Region and every operating Region |
| 4 | Scope & cost | The estimate, the metered scope, and the consent gate |
| 5 | Review | Confirm everything, then activate |
Next stays disabled until the step you are on is complete, and Back is disabled on step 1. You can move back and forth freely before you activate, and the cost estimate on step 4 recomputes when you change the accounts or Regions that feed it.
Prerequisites
- At least two AWS accounts onboarded in Prism. One is the host; at least one more must be enrolled as a member
- Authority to accept an AWS charge on the host account
Step 1: Host Account
Choose the single AWS account that will own the IPAM.
| Field | Required | Notes |
|---|---|---|
| Host account | Yes | Single-select, from your onboarded accounts. The host is not also a member; it is listed separately from step 2 |
The wizard opens this step with a notice you should read rather than skim:
This account is not an AWS delegated administrator. Prism creates the IPAM here and asks every other enrolled account to share its resource discovery with it through AWS RAM. No management-account access is used, no AWS Organizations setting is changed, and no delegated administrator is registered. This account is where the IPAM lives, and by default it is where the IPAM bill for every account you enrol lands. Only the accounts you enrol are managed and billed; no other account in your organization is affected.
The Host Account Is Permanent
The host account cannot be changed after enablement. This is true at two levels and neither has a workaround:
- AWS has no operation that moves an IPAM between accounts. An IPAM belongs to the account that created it, permanently.
- Prism refuses the change explicitly rather than leaving it to convention, because the host account carries a larger IAM policy than members do (including the permission to delete the IPAM), and a silent host change would leave that permission standing on an account that no longer needs it.
Changing hosts means disabling VPC IPAM and enabling it again, and disabling destroys all CIDR address history irreversibly. Choose an account you will keep.
AWS allows only one IPAM per Region per account, and that quota cannot be raised. If the account and home Region you pick already contains an IPAM, the wizard tells you at this step and offers to adopt it or to choose another account. It does not defer the collision to the creation call, where there would be no remedy.
If Prism adopts an IPAM you already own, the wizard's copy changes to match: Prism is not creating anything, it is adding your enrolled accounts to a meter you already pay, and on teardown that IPAM is left running (because it is yours) and keeps metering. See Teardown.
Prism refuses to adopt an existing IPAM that is on the Free tier and does not carry Prism's ownership tags. Flipping your own IPAM to Advanced would spend your money on a resource Prism does not own, and Prism cannot create a second IPAM alongside it because of the one-per-Region quota. The wizard names both options and lets you decide.
Step 2: Accounts
Select the member accounts to enrol. Each one gets its own resource discovery, shares it to the host, and is then discovered, inventoried and metered.
| Field | Required | Notes |
|---|---|---|
| Accounts | Yes | Multi-select checkbox list, each option reading Account name (account ID). The host account is not in this list |
At least one member account is required. A host-only deployment has no cross-account product, and the Free tier would serve it, so Prism does not offer it as a paid mode.
The Association Ceiling
This step enforces the limit that bounds the whole capability. AWS caps resource discovery associations per IPAM at 5 by default, and the host's own automatically created association consumes one. That is four member accounts on a fresh host.
The step reads your host account's live applied quota (not a hard-coded 5) and shows it as a running count:
3 accounts selected · your current limit is 4 member accounts
Select more than the ceiling allows and Next is disabled, with both numbers named.
Prism refuses at the edge rather than half-enrolling. If the wizard let you submit an over-ceiling selection, the enablement would create the IPAM, enrol accounts one by one, and fail on the association that crossed the limit, leaving you half-enrolled with the meter already running. The refusal here exists precisely to prevent that outcome.
Raising the ceiling. The quota is adjustable. Above the boundary the step offers to file a Service Quotas increase request on your host account, sized to exactly the number of accounts you selected plus one for the host.
- Prism shows you the exact value it will request.
- You approve it explicitly. Prism never files a quota request unprompted, because filing one opens a support case on your account.
- Prism files the request and records its id.
- Prism polls the applied quota itself and re-opens the step when AWS has actually raised it.
Prism unblocks on the applied value AWS reports, never on a customer telling it the raise landed. A Re-check now button forces the poll, but the applied value is always the authority: a raise that was reported but did not land would drive Prism straight into the half-enrolled state above.
Filing an increase request needs a qualifying AWS Support plan on the host account. If your account cannot file automatically, Prism says so and points you at raising it in the AWS console, rather than presenting a retryable error for something that will never succeed.
You can add and remove accounts after setup from the Accounts page. Adding accounts there inherits every guard on this step, including the association-ceiling pre-flight, so "start with four accounts and add the rest once the increase lands" is a supported path, not a workaround that walks into the ceiling later.
Step 3: Regions
Select the home Region and the operating Regions.
| Field | Required | Default | Notes |
|---|---|---|---|
| Home Region | Yes | us-east-1 | Single-select. Where the IPAM itself lives |
| Operating Regions | Yes | us-east-1 | Multi-select. The home Region is locked in the list and cannot be deselected |
The Four Region Rules
VPC IPAM is more Region-sensitive than any sibling capability, because "which Region" means four different things inside one product. The wizard states them in one place so you are not deriving them by analogy:
| Rule | What it governs |
|---|---|
| The IPAM lives in the home Region | The IPAM, its scopes, its pools, provisioning and deprovisioning, and every lifecycle call all happen in the home Region. Every IPAM identifier is scoped to it |
| Allocations happen in the pool's locale | Allocating from a pool, and releasing an allocation, run in the Region the pool is localised to, not the home Region. A pool with no locale is not allocatable |
| Discovery reads run from home, about a target Region | Discovered CIDRs, discovered accounts and public addresses are read from the home Region with the target Region passed as a parameter. This is the rule most often got wrong by analogy with the first |
| Operating Regions are what gets discovered | An account is inventoried in the operating Regions you select here, and nowhere else. Resources in a Region you did not select are invisible and unmetered |
Changing the home Region after enablement is not possible: it is a property of the IPAM. Operating Regions can be changed later from Settings.
Operating Regions are a cost lever, not a display filter. Adding a Region extends discovery (and therefore the meter) into that Region for every enrolled account. Removing one stops the discovery and drops its cached inventory.
VPC IPAM is not available in every AWS Region, and Prism validates your selection against a supported-Region list at the edge (before any AWS call), so an unsupported Region is rejected with a message naming the Region, rather than failing several minutes later with an error that names IAM.
Opt-in Regions are checked per account. An account that has not opted in to a Region you selected is reported against that account rather than failing the whole enablement.
Step 4: Scope and Cost
This is the screen. It is rendered top to bottom in a deliberate order, because the order is the argument.
1. The unavoidability alert. The price is in the title, not the small print:
VPC IPAM Advanced tier is required, and it is billed: $0.00027 per active IP per hour. There is no free multi-account IPAM. AWS refuses to associate a second account's resource discovery on the Free tier, so the cross-account inventory, overlap detection and utilization this capability exists for are Advanced-only.
2. The estimate, with its provenance stated. Prism has, by this point, already attached its read permissions and counted the IP addresses attached to network interfaces across the accounts and Regions you selected.
| State | What you see |
|---|---|
| Computed | ≈ 8,412 active IPs → ≈ $1,658 / month, tagged Prism estimate, with: "Counted from attached ENIs in the accounts and regions selected above: a lower bound. AWS's own meter may differ." |
| Unavailable | —, tagged Not estimated, with: "Prism could not estimate your active-IP count. The charge is real regardless. Enable only if you accept an unknown monthly figure." |
Prism never shows $0.00 here. An unpriced deployment is not a free one, and a zero would read as "this is free", which is the single most expensive misreading available on this screen. When the count cannot be computed, the screen says so in words.
The two-stage flow exists precisely so that Not estimated is the exception rather than the default. Without a grant in place first, every tenant whose access roles did not already carry EC2 describe permissions would see "Not estimated", and a consent screen that shows no number is not a cost gate.
3. The metered scope panel, headed "Metered scope: this is what you will pay for". It echoes your account selection and your operating Regions read-only, each with an Edit button that jumps you back to the relevant step, and it contains the estimate from above, inside the panel, so the number moves when you change the levers.
There are only two levers, and they are both here. There is no organizational-unit exclusion control, because under Prism's architecture a resource discovery covers exactly one account and there is nothing for an exclusion to exclude.
4. Where the bill lands.
The IPAM bill for all enrolled accounts lands on the host account. AWS defaults the metered account to the IPAM's owner, so the account that owns the IPAM is charged for every active IP it manages. Only the accounts you enrol here are managed; no other account is billed or visible. Moving the charge to each resource's own account requires AWS Organizations integration and an IPAM created by a delegated administrator, neither of which Prism uses. Prism does not change this setting and cannot change it for you.
Note what this does not say: it does not say "your whole organization". The meter follows the accounts you enrol, not your organization. In a shared-payer organization that distinction matters.
5. Advanced to Free is not an undo. Downgrading the tier later is blocked by AWS until private-scope pools, non-default private scopes, off-home-locale pools, non-default discovery associations and non-owner allocations are all cleaned up. Plan on teardown as the exit, not a tier flip.
6. The gate. A single switch:
I understand VPC IPAM Advanced tier is billed, that the meter covers every active IP in the accounts and regions selected above whether or not they are in a pool, and that the charge lands on the host account.
Next is disabled until it is on. The acknowledgement is re-checked if you go back and change anything, and it is sent to the server, which refuses to activate without it.
Step 5: Review
The Review step restates both cost alerts, then summarizes:
- Host account
- Member accounts
- Home Region and Operating Regions
- Estimated active IPs and the resulting monthly figure
- The acknowledgement, and who is giving it
The submit button reads Enable IPAM (Advanced tier — billed). The last string you read before clicking contains the word "billed" on purpose.
If the request is rejected, the error appears on this step rather than bouncing you elsewhere. Every rejection reachable from here (an account outside your organization, an unsupported Region, an over-ceiling selection, an existing IPAM in the host Region) is fixable with Back.
What Happens After You Activate
The wizard hands off to an asynchronous job and is replaced by a progress card headed Enabling VPC IPAM across accounts…. The page polls and hands over to the Dashboard when the run settles.
The sequence, in order:
| Stage | What runs | Phase shown per account |
|---|---|---|
| Host | Attach the host permissions policy and wait for it to take effect, check for an existing IPAM, then create the IPAM at the Advanced tier and wait for it to settle | Granting access → Enabling → Enabled |
| Members, in parallel | Attach the member policy and wait, check for an existing resource discovery, create one, then share it to the host through AWS RAM | Granting access → Enabling → Sharing |
| Association, serially | The host accepts each RAM share where an invitation was raised, then associates each discovery to the IPAM | Accepting → Associating → Enabled |
Granting access legitimately takes minutes. Prism attaches an IAM policy to each account's access role and then waits for the change to become usable. IAM propagation is not instant, so the progress bar can sit at the same percentage for a long stretch. A pause here is normal and is not a stalled job.
The host stage is fatal. If the IPAM cannot be created, the run stops and no member grant is attached beyond the read permissions already in place. A member resource discovery with no IPAM to associate to is pure liability (it consumes that account's one-per-Region discovery quota and yields nothing), so Prism does not create any.
Member accounts, by contrast, succeed and fail independently. A configuration where the IPAM is healthy and one member failed settles in partial failure, and you repair it from the Accounts page.
The Cold Start
Enablement finishing is not the same as data appearing. AWS's discovery is a periodic background sweep, and the first one takes a while:
- Up to about 20 minutes from IPAM creation to the host account's own first discovered CIDRs
- About 4 minutes from a member's association completing to that member's CIDRs appearing
- About 7 minutes for scope-level compliance and overlap data
During this window the Dashboard and the inventory pages show "AWS is still taking its first inventory" rather than an empty table, with one status chip per account-and-Region association so you can see the associations are healthy, and a Check for results button. There is nothing to retry.
An account reaching Enabled means its discovery is associated. It does not yet mean the account can allocate from a shared pool: AWS requires the account to have appeared in a completed sweep first, about 4.5 minutes past association. Prism tracks that separately and warns before you share a pool to an account that is not ready. See Enrolled is not the same as usable.
Partial Success
Member accounts are enrolled independently, so some can succeed while others fail. When any do, the configuration settles in partial_failure:
- The accounts that enrolled are being discovered and appear in the inventory as normal.
- The Dashboard shows a warning banner with a Review button through to Accounts.
- Each failing account is listed there with its error and a Retry action.
- If the failure names permissions, use the Permissions tab in Settings to re-check and repair the roles, then retry.
Nothing is rolled back on partial failure, and retrying one account never disturbs the others.
A quota exhaustion at the association step is terminal, not retryable. If the association quota runs out, Prism stops rather than burning a retry ladder against a limit that will not move on its own. The account's error names the quota and points you at the increase path.
A prior failed or disabled configuration is cleared when you resubmit the wizard, except when the old configuration still points at an IPAM that exists. In that case Prism refuses and asks you to disable properly first, because a failed configuration can perfectly well be carrying a live, metering IPAM, and quietly replacing the record of it would strand the only handle for the call that stops the meter.
Related Pages
- VPC IPAM, What the capability is, the tier, and the architecture
- Dashboard, What you see once the first sweep lands
- Accounts, Add accounts, retry failures, and read discovery health
- Settings, Change operating Regions, review tier and cost, and repair permissions
- Teardown, What disabling does, and what it cannot do
- Security Hub Issues, Troubleshooting setup failures