Pools
Pools are how you hand address space out. Where Address Space shows what AWS discovered, this page shows what you have planned: a hierarchy of scopes and pools carved out of your address ranges, and a ledger of every allocation made from them.
Accessing Pools
In the Security Hub sidebar, click VPC IPAM > Pools for the hierarchy, or VPC IPAM > Allocations for the cross-pool allocation ledger. Selecting a pool in the tree opens its detail page, which is deep-linkable.
The Hierarchy
VPC IPAM organises address space in four levels, and Prism renders all of them in one indented table so you can compare utilization down a branch.
| Level | What it is |
|---|---|
| Scope | The boundary within which overlap is computed. AWS creates two automatically (a private scope and a public scope) and you can add more private ones |
| Top-level pool | A pool directly under a scope, typically your whole address plan for an address family |
| Regional pool | A pool localised to one AWS Region, provisioned from a top-level pool |
| Nested pools | Further subdivisions (per environment, per team, per application) up to a depth of 10 |
A pool becomes usable by provisioning one or more CIDRs into it. A child pool's CIDRs are provisioned from its parent, so the hierarchy is a real allocation chain rather than a labelling convention.
The scope is what gives overlap its meaning. Two CIDRs "overlap" only relative to a scope. This is why Prism reads the whole hierarchy from the host account: a member account looking at a pool that has been shared to it cannot see which scope the pool belongs to at all, so a member-side read would produce rows whose overlap status means nothing.
Pools that Prism cannot place in the tree (because AWS reports no scope for them) are rendered under a synthetic Unscoped root with a warning chip, never dropped. A silently missing pool in a hierarchy view is the worst failure this page could have.
Reading the Tree
The tree is one table, not nested tables, so the utilization column stays aligned across every depth, which is the whole reason to look at a hierarchy rather than a flat list. Rows expand and collapse with the caret, expansion state is reflected in the URL so you can deep-link to a branch, and a branch deeper than the display limit renders an explicit "N deeper levels not shown" caption rather than quietly truncating.
Each row carries the pool's address family, its locale, its provisioned size, its utilization bar and its state.
Utilization for an IPv6 pool is not computable: AWS does not calculate it. Those rows show a muted em dash and no bar, which is not the same as 0%. See Utilization on Address Space.
Pool States
Creating and provisioning are asynchronous, so a pool passes through intermediate states before it is usable.
| State | Meaning |
|---|---|
create-in-progress | AWS is creating the pool. Settles in about 10 seconds |
create-complete | The pool exists |
pending-provision | A CIDR is being provisioned into the pool. Settles in about 20 seconds |
provisioned | The CIDR is available to allocate from |
failed-provision | AWS could not provision the CIDR. The reason is shown on the row |
pending-deprovision | A CIDR is being removed from the pool |
deprovisioned | The CIDR has been removed |
failed-deprovision | Deprovisioning failed. This is retryable, not terminal (see below) |
modify-in-progress / modify-complete | A pool property is being changed |
delete-in-progress / delete-complete | The pool is being deleted |
Three further states appear on any IPAM resource and mean something quite specific: isolate-in-progress, isolate-complete and restore-in-progress indicate that the account owning the resource left your AWS organization. They are not ordinary progress, and Prism labels them as what they are.
failed-deprovision usually means "too soon", not "broken". AWS releases an allocation asynchronously after the underlying resource goes away, and it cannot be forced: a deprovision issued inside that window fails. Prism retries rather than treating it as terminal. The same behaviour is what makes teardown a long-running operation rather than a single call.
Creating Scopes and Pools
Create a scope from the top of the tree, and a pool from the scope or parent pool you want it under.
| Field | Notes |
|---|---|
| Scope | The private scope the pool belongs to |
| Source pool | The parent pool, for anything below top level |
| Address family | IPv4 or IPv6. Must match the parent |
| Locale | The AWS Region the pool serves, for a regional pool. Must match the parent's locale or be unset |
| Description | Free text |
Quota Fences
Prism checks AWS's structural limits from its own cache before the call, so you get a sentence instead of an EC2 exception:
| Rule | Refusal |
|---|---|
| Pool depth 10 | A pool cannot be created under a parent already at maximum depth |
| 50 pools per scope | A scope that is full refuses new pools |
| 5 scopes per IPAM | An IPAM that is full refuses new scopes |
| Address family must match the parent | A child cannot change address family |
| Locale must match the parent's, or be unset | A child cannot be localised outside its parent |
A pool with no locale has no Region to allocate in, so AWS cannot allocate from it. Prism marks such a pool as not allocatable in the tree rather than offering an allocation action that will fail.
Why v1 Refuses Public-Scope Pools
Prism refuses to create a pool in the public scope, with an error naming the reason rather than a generic validation failure.
The reason is teardown. DeleteIpam --cascade is the only proven way out of a wedged IPAM whose meter is running, and AWS refuses cascade outright if any pool exists in the public scope. Allowing one operator action to create a state from which the meter cannot be stopped through the product is not a trade this version makes.
The public scope itself is still visible and readable (you can see what is in it), and public-scope pool management is planned for a later phase with its own teardown design.
If your host account's IPAM was adopted and already contains public-scope pools, teardown handles it: before cascading, Prism deletes the public-scope pools and their provisioned CIDRs first, and tells you it is doing so. Offering a disabled button with no path forward is how a tenant ends up with no in-product way to stop the meter.
Provisioning and Deprovisioning CIDRs
Provision adds a CIDR to a pool, drawn from its parent for a nested pool. Deprovision removes one.
Both are asynchronous: Prism records the CIDR immediately in the state AWS returned and the page polls until it settles. Provisioning normally completes in about 20 seconds.
Deprovisioning a CIDR that still has allocations against it will fail. Release the allocations first, and note that a resource-backed allocation cannot be released at all while the resource exists. See Allocations.
Allocations
An allocation is a range handed out from a pool. The Allocations view is the cross-pool ledger of every one AWS reports, and the pool detail page shows the same rows scoped to one pool.
| Column | Description |
|---|---|
| CIDR | The allocated range |
| Pool | The pool it came from |
| Source | Manual or Resource (see below) |
| Resource | The resource holding the allocation, for a resource-backed allocation |
| Type | The resource type, for example vpc |
| Account | The account that owns the resource |
| Region | The resource's Region |
| Description | Free text recorded at allocation time |
Allocations Are Not Address Space
This is the distinction that makes the capability worth having, and it is worth stating plainly:
- Allocations are what IPAM handed out.
- Address Space is what IPAM discovered.
A VPC created outside a pool (someone clicked through the console, or a Terraform module hard-coded a range) appears in Address Space and not in the allocation ledger. That delta is your unmanaged address space, and comparing the two is the compliance story the product exists to tell.
Manual and Resource-Backed Allocations
Every allocation is one of two kinds, and the difference decides what you can do with it.
| Source | What it is | Can Prism release it? |
|---|---|---|
| Manual | A reservation you made through Prism or the AWS console, backed by no resource | Yes |
| Resource | A range AWS assigned to a live resource (most often a VPC) out of the pool | No |
Prism cannot release a resource-backed allocation, and neither can you. AWS refuses it outright:
InvalidParameterValue: ... Cannot release allocation for resource type VPC.
Remove the resource using the corresponding cidr and IPAM will automatically
release the allocation
AWS's only remedy is deleting the resource: your VPC. Prism will never delete a resource in your account, so this is a product boundary, not an error to work around. Attempting the release returns a refusal that names the resource and the account, because your next action is "delete the VPC", not "fix the request".
This is also why teardown has a first-class blocked outcome: a pool with a live resource-backed allocation cannot be deleted by Prism, ever, until you remove the resource.
Release is asynchronous and cannot be hurried. After the resource is gone, AWS releases the allocation on its own schedule: an allocation has been observed surviving more than 9 minutes past a confirmed VPC deletion. That is normal. A deprovision issued inside that window fails.
The ledger includes allocations members made themselves from a pool you shared to them, not only allocations Prism made. Those are not Prism's to release, but they do block the pool from being deleted, so teardown reports them as named blockers keyed by account and resource.
Making a Manual Allocation
From a pool's detail page, a manual allocation reserves a range so nothing else can take it. It runs in the pool's locale, not the home Region: the Region is a property of the pool and is not something you select or override.
Pool Detail
Selecting a pool opens its own page with four tables:
| Table | Contents |
|---|---|
| Provisioned CIDRs | Every CIDR provisioned into the pool, with its state and any failure reason |
| Allocations | Every allocation from the pool, with its source |
| RAM shares | Which accounts the pool has been shared with |
| Blockers | Resource-backed allocations that will prevent this pool from being deleted, named by resource id and account |
The pool's destructive actions live here: deprovision a CIDR, release a manual allocation, delete a share, delete the pool.
Deleting a pool never cascades. If the pool holds a resource-backed allocation, Prism refuses and names the blocking resources rather than reaching for a cascading delete that would deallocate CIDRs from live VPCs. The cascading option exists only as a deliberate, separately confirmed escape hatch during teardown.
Sharing a Pool with Member Accounts
To let a member account allocate from a pool, share the pool to it through AWS RAM from the pool's RAM shares table. Select the accounts and create the share; Prism tags it as its own so teardown can find it later.
Sharing has two preconditions, and one of them is invisible in the association state:
- The account must be enrolled and its resource discovery associated to the IPAM.
- The account must be monitored: it must have actually appeared in a completed discovery sweep.
The second one is asynchronous and lags the first by about 4.5 minutes. Until it is satisfied, AWS refuses the allocation with an error that names the IPAM rather than the missing step:
UnsupportedOperation: The operation AllocateIpamPoolCidr is not supported.
Account 857639285487 is not monitored by IPAM ipam-0fd4edcdfbbcb27cd.
Prism checks readiness against the accounts AWS reports as discovered and warns or refuses rather than creating a share whose first use fails. It never gates on a fixed wait: the check is against AWS's own answer, so a slow sweep is handled and a fast one is not artificially delayed. Accounts shows readiness per account.
What Prism Will Not Touch
Some things are deliberately read-only or refused, each for a reason:
| Refusal | Why |
|---|---|
| Deleting a pool, scope, share or discovery Prism did not create | It is yours, or another tenant's. Ownership is decided by Prism's tags, never by a name match |
| Deleting either default scope | AWS creates them and refuses to delete them |
| Deleting the default resource discovery or the default association | AWS creates them with the IPAM; Prism records them as AWS-created so teardown never targets them |
| Modifying or deleting a pool that AWS itself manages | Some pools are wired into EC2's public-IPv4 allocation path and are not yours to change |
| Enabling auto-import on a pool Prism creates | Auto-import pulls in non-conforming CIDRs, keeps only the largest of any overlapping pair, and breaks ties randomly. It is shown read-only so an adopted pool's setting is visible, but Prism never turns it on |
| BYOIP and publicly advertisable pools | Deferred to a later phase |
| Changing which account is metered | Structurally impossible under Prism's architecture (see Settings) |
Adopted pools behave differently on teardown. A pool that already existed when Prism enrolled the account, or that AWS created itself, is never deleted by Prism. Teardown skips it and tells you it did. See Teardown.
Empty States
Pools use a different empty state from the inventory pages, on purpose. Pools are created by you and by Prism, never discovered, so an empty tree is always genuinely empty and can never be a cold start. The empty state reads "No pools yet" with a Create pool action.
Telling you to wait for a sweep that will never produce a pool would be wrong, which is why the cold-start component is not used here.
Related Pages
- Address Space, What AWS discovered, and the delta against what you allocated
- Dashboard, Worst utilization across pools
- Accounts, Which accounts are enrolled, discovered, and ready to allocate
- Teardown, Why a live allocation blocks pool deletion, and what to do about it
- VPC IPAM, Scopes, the architecture, and the meter
- Security Hub Issues, Troubleshooting pool and allocation errors