Address Space
Address Space is the product. It is the flat, filterable inventory of everything AWS VPC IPAM discovered across your enrolled accounts and operating Regions, joined to the posture AWS computed for it: how full each CIDR is, whether it conforms to the pool it came from, and whether it overlaps something else in the same scope.
The sidebar splits this into two rows (Address space and Public IPs) because a CIDR row and a public-address row share almost no columns. This page documents both.
Accessing Address Space
In the Security Hub sidebar, click VPC IPAM > Address space, or VPC IPAM > Public IPs for the public-address view. You can also arrive pre-filtered by clicking a tile or a posture count on the Dashboard.
Discovered, Not Declared
Everything on this page is something AWS found, not something you or Prism told it about. That is what makes the page useful and what makes one comparison on it worth making deliberately:
- Address space is what IPAM discovered in your accounts.
- Allocations is what IPAM handed out from a pool.
A VPC that exists in an enrolled account but was never allocated from a pool appears here and not in the allocation ledger. That delta is the compliance story: it is your unmanaged address space, and finding it is the point.
The CIDR Table
| Column | Description |
|---|---|
| CIDR | The resource's address range, in a monospace, digit-aligned column so 10.100.0.0/16 and 10.10.0.0/16 cannot be confused at a glance |
| Resource | The resource id and, where AWS supplies one, its name: a VPC, a subnet, or another discovered resource type |
| Type | vpc, subnet, and the other resource types AWS reports |
| Account | The AWS account that owns the resource |
| Region | The operating Region the resource is in |
| Utilization | How much of the range is in use, as a bar. See Utilization |
| Compliance | Whether the CIDR conforms to the pool it was allocated from |
| Overlap | Whether the CIDR overlaps another CIDR in the same scope |
| Management state | Whether IPAM is managing the resource's addresses |
Rows are keyset-paginated in CIDR order, and further pages load on demand rather than all at once: an estate of any size produces a lot of subnets.
Selecting a CIDR opens its address history.
The VPC-Only Posture Caveat
This is the single most important thing to understand before you read a posture column, because AWS's behaviour here surprises everyone once.
AWS populates compliance, overlap and management state only on vpc rows. Subnet rows, which are typically the large majority of a discovered inventory, come back with all three blank, while still carrying a genuine utilization figure. In the spike sample this design was built against, 12 of 15 rows had all three blank, and every one of those was a subnet.
Prism handles this explicitly rather than letting a blank pass for a clean result:
- A blank posture on a non-VPC row is stamped not applicable at the moment it is read from AWS, never guessed at display time.
- It renders as a muted em dash with a tooltip, never as a chip. An unknown state must never read as a clean one.
- Every posture count, every rollup and every filter denominator on this page and on the Dashboard is scoped to VPC rows, and the page says so on screen.
A subnet showing an em dash under Compliance is not compliant and not non-compliant. AWS did not evaluate it. Do not read the column as a pass, and do not read the absence of red as coverage.
The practical consequence: if you filter the table to compliant, every subnet disappears. That is correct, because none of them has a compliance value at all. Filter to VPCs when you want a posture answer, and use the utilization column when you want an answer about subnets.
Overlap
Overlap is computed by AWS within an IPAM scope, which is why enrolling every account into one private scope is what makes cross-account conflict detection work at all. Two accounts that independently stood up default VPCs on 172.31.0.0/16 are reported as overlapping, with the owning account on each row. There is no AWS Organizations integration and no management-account access anywhere in the picture.
Management State
Management state answers "is IPAM tracking this resource's addresses?" It is an eventually consistent observation with a multi-minute lag, not an instant fact.
A VPC created from an IPAM pool has been measured taking about 7 minutes to move from absent to managed in the same account, and about 12 minutes cross-account. Prism holds a recently discovered row as pending rather than reporting it as unmanaged, so a VPC you allocated five minutes ago does not read as a problem.
unmanaged on a row that has been around for a while is a real signal: it usually means the resource's CIDR was not allocated from an IPAM pool. unmanaged on a row that appeared minutes ago is almost always the lag, and Prism renders it as pending instead.
Utilization
The utilization column is AWS's own figure for how much of the range is in use, drawn as a bar.
| Utilization | Colour |
|---|---|
| Below 80% | Green |
| 80% to under 95% | Amber |
| 95% and above | Red |
Utilization is not computable for IPv6. AWS does not calculate IP usage for IPv6 address space, so those rows carry no figure. Prism draws no bar at all, just a muted em dash and a tooltip reading "AWS does not calculate IP usage for IPv6 address space."
That is different from 0%, and the distinction is not cosmetic. A 0% bar would report an empty range; a spinning indeterminate bar would report a value still loading. Neither is true: the number does not exist and will not arrive.
These thresholds are tighter than the ones on pool rows (70/90), because a subnet has far less headroom than a pool. 90% of a /16 is comfortable; 90% of a /28 is an outage next week.
Filtering
The filters card above the table narrows the list:
- Account: the enrolled accounts, shown as
Account name (123456789012) - Region: the operating Regions
- Resource type:
vpc,subnet, and the other discovered types - Compliance, Overlap, Management state: toggle chips per value
- Search: free-text against the CIDR and the resource id or name
Filters are reflected in the page URL, so a filtered view can be shared or bookmarked, and typing in the search box is debounced rather than firing per keystroke.
The posture filters operate on VPC rows by construction, because only VPC rows carry posture. Combining a posture filter with Type: subnet returns nothing, and that is arithmetic rather than a bug.
Address History
Selecting a CIDR opens a history panel showing what IPAM has recorded about that specific range over time: when it was allocated, to what, in which account, and when it was released.
Address history is the one screen in VPC IPAM that reads live from AWS, rather than from Prism's cached inventory. AWS offers it as a per-CIDR lookup with no bulk feed, so there is no way to pre-fetch it and no history table to browse. You reach it from a CIDR, which is why it opens as a panel rather than being its own page.
Because it is a live call, it can be slow on a distant Region and it can be throttled if you open many in quick succession. Prism bounds it with a timeout and surfaces throttling as such rather than as a generic failure.
Address history is destroyed when the IPAM is deleted, and it cannot be exported or backed up. It is a per-CIDR lookup with no bulk read, so there is no way for Prism or for you to take a copy before teardown. If this record matters to you, capture what you need before you disable the capability. See Teardown.
Public IPs
The Public IPs view is Public IP Insights: every public IPv4 address AWS discovered across your enrolled accounts and operating Regions.
| Column | Description |
|---|---|
| Address | The public IPv4 address, monospace and digit-aligned |
| Association status | Whether the address is attached to anything. disassociated is the one to look for |
| Type | For example an Amazon-owned Elastic IP |
| Account | The account that owns the address |
| Region | The Region the address is in |
| Allocation | The Elastic IP allocation id, where the address is an EIP |
| Attached to | The service, resource, network interface or instance the address is attached to, where AWS reports them |
| Network border group | The network border group AWS reports |
| Tags | The tags on the address |
An address with disassociated status is an idle public IPv4 address, and AWS charges for it. Public IPv4 addresses are billed whether or not anything is attached, so this filter is the most directly actionable thing in the capability: every row it returns is money being spent on nothing.
The Dashboard surfaces the idle count as its own figure for the same reason.
Rows with almost every column empty are normal. Service, attached resource, VPC, subnet, network interface, instance and security groups are only populated when the address is actually attached to something. An unattached Elastic IP legitimately reports the address, its owner, its Region, its allocation id and nothing else, and it is exactly the row you most want to see.
This view loads a page at a time with a Load more control, rather than assuming everything fits in one page. AWS provides no bulk pagination helper for this data, so Prism walks it explicitly.
Empty States
| State | What you see |
|---|---|
| Cold start | "AWS is still taking its first inventory" with an indeterminate bar and one chip per account-and-Region association. The first sweep takes up to about 20 minutes; a newly added account typically appears within 4 to 7 minutes |
| Filtered to nothing | "No CIDRs match these filters." The filter is too narrow; the estate is not empty |
| Genuinely empty | A message naming the scope that was searched: how many accounts, how many Regions, and the sweep it is as of |
| Coverage gap | A non-dismissible warning above the table naming the accounts that stopped being discovered. Anything in those accounts is missing from the table below, however clean it looks |
When the coverage-gap banner is showing, the empty state and the counts beneath it are scoped to the accounts that are reporting, never to the full enrollment. A table that looks clean because data is missing is the failure mode this banner exists to prevent.
Related Pages
- Dashboard, Totals, worst utilization, and the posture rollups
- Pools, What IPAM handed out, and how that differs from what it discovered
- Accounts, Which accounts are actually being discovered
- VPC IPAM, The meter, the architecture, and the cold start
- Teardown, What happens to address history when the IPAM is deleted
- Security Hub Issues, Troubleshooting missing inventory