Teardown
No other Prism capability needs a page like this one. VPC IPAM does, for three reasons: its teardown is a long chain across two AWS services rather than a single call; it has an outcome (blocked) that is a correct result rather than an error; and a teardown that does not finish leaves a meter running on your AWS bill.
Read this before you enable, not after.
Where Teardown Lives
Settings > Danger zone. Unlike every other capability's one-shot danger zone, IPAM's is three stages laid out on the page rather than a single modal, because a modal cannot tell this story.
| Stage | What it is |
|---|---|
| 1. Pre-flight ledger | Everything teardown will do, everything it cannot do, and every blocking resource by name, before any button |
| 2. Mode | Ordered teardown (the default) or Force delete. Force delete is disabled until an ordered teardown has actually got stuck, with the reason shown inline |
| 3. Confirmation | A dialog where you type your customer ID. The three most consequential lines from the ledger are repeated inside it |
The confirm button reads "Delete the IPAM and stop the meter". Naming the benefit is what makes the destructive verb acceptable.
The typed customer ID is cleared every time the dialog closes, so reopening always starts from an empty field and the guard is never pre-satisfied by something you typed earlier.
The Three Lines You Must Read First
The pre-flight ledger always contains these, whatever your deployment looks like:
- No VPC is deleted. Your VPCs keep their addresses; only IPAM's record of them goes away.
- All CIDR address history is destroyed, irreversibly.
- Any pools blocked by live resources, named by resource id and account.
The Ordered Teardown
The default mode works from Prism's own record of what it created, deepest resource first, checkpointing after every step. It never walks the live AWS tree, because a half-deleted IPAM is not a deterministic thing to walk.
| Step | What happens |
|---|---|
| Pre-flight | Every pool's allocations are classified. Any allocation backed by a live resource is recorded as a blocker |
| Shares | Every RAM share Prism created is deleted: both the pool shares owned by the host and the discovery shares owned by the members |
| Allocations | Manual reservations are released. Resource-backed allocations are never attempted |
| Drain | Prism waits for AWS to actually release the allocations. This is a real wait, not a formality (see below) |
| CIDRs | Provisioned CIDRs are deprovisioned, deepest pool first |
| Pools | Pools are deleted, deepest first. Adopted and AWS-created pools are skipped and reported |
| Scopes | Non-default scopes are deleted. The two default scopes are AWS's and cannot be deleted by anyone |
| Associations | Each member's resource discovery is disassociated from the IPAM |
| The IPAM | Prism sweeps for any IPAM it tagged that its records do not account for, then deletes the IPAM. This is the call that stops the meter |
| Discoveries | Each member's resource discovery is deleted, followed by a sweep of that account for Prism-tagged leftovers |
| Permissions | The IPAM policy is detached from every account's access role |
The drain step is why teardown takes minutes rather than seconds. After a resource is gone, AWS releases its allocation asynchronously and cannot be hurried: an allocation has been observed surviving more than 9 minutes past a confirmed VPC deletion. Deprovisioning inside that window fails. Prism waits it out on a bounded schedule instead of pushing on and manufacturing failures.
Teardown survives a backend restart. It is a persisted, resumable job: if Prism restarts mid-teardown, the job resumes at the step it reached rather than being marked failed. This is a deliberate divergence from every other capability, and the reason is simple: the meter runs while the job is stopped.
Re-running teardown is safe and is the normal way to retry. Disabling can be started again from any settled state, including from disabled and from blocked. A repeated teardown treats already-removed resources as success, so nothing is double-deleted and nothing is missed.
Blocked: Teardown Waiting on Your Resources
Prism cannot delete a pool that a live resource is allocated from. Not "will not by default". Cannot. AWS refuses to release a resource-backed allocation and instructs the caller to delete the resource:
InvalidParameterValue: ... Cannot release allocation for resource type VPC.
Remove the resource using the corresponding cidr and IPAM will automatically
release the allocation
Prism will never delete a resource in your AWS account. That is a product boundary, so blocked is a first-class outcome, presented as an expected result with a named remedy rather than as an error to decode:
Teardown is waiting on resources Prism must not delete.
Pool
ipam-pool-07576ebc0f699f256(10.100.0.0/16) still has 1 allocation from a live resource:·
vpc-068e2835b7501db47:vpc,us-east-1, account857639285487Prism will never delete a resource in your account. Delete the VPC (or release its CIDR) and IPAM will release the allocation automatically. That takes several minutes and is not instant. Then press Retry teardown.
The IPAM is still running and still billing until it is deleted. If you cannot remove these resources, use Force delete below.
What You Do About It
- Read which resources are blocking, and in which accounts. Blockers are named by resource id, resource type, Region and owning account, because the resource is very often in a member account rather than the host.
- Remove the resource, or release its CIDR, in the account that owns it. This is your action in your account: there is no Prism control that does it.
- Wait. AWS releases the allocation on its own schedule, typically several minutes.
- Press Retry teardown. Prism resumes from where it stopped.
A blocked pool does not strand everything else. Teardown continues with every step that is not downstream of a blocked pool: shares, manual allocations in unblocked pools, unaffected scopes, associations and member discoveries all proceed. One blocked pool does not hold nine healthy accounts' teardown hostage.
Blocked means the IPAM is still alive, and an alive IPAM is a billing IPAM. Advanced-tier charges continue across your entire enrolled footprint for as long as teardown is blocked. This is not a state to leave sitting over a weekend.
Force Delete: The Cascade Escape Hatch
When the ordered teardown cannot finish (the drain never completes, deprovisioning keeps failing, or the graceful budget runs out), Prism offers Force delete, which is AWS's DeleteIpam --cascade.
It is offered because without it, a tenant wedged on an allocation they cannot remove would have no in-product way to stop a meter that scales with their entire footprint. It is never the default and never automatic.
Force delete is disabled until an ordered teardown has actually reached the stuck state, with the reason shown inline on the disabled control. It never appears as a first action.
What Cascade Does
| It does | It does not |
|---|---|
| Deallocates CIDRs from live VPC resources in private-scope pools | Delete any VPC, subnet or resource |
| Deprovisions IPv4 CIDRs from private-scope pools | Change any resource's actual IP addresses |
| Deletes all private-scope pools and non-default private scopes | Remove AWSServiceRoleForIPAM |
| Deletes the default scopes and the IPAM itself | Delete anything Prism adopted rather than created |
In AWS's own words: "No VPC resources are deleted as a result of enabling this option. The CIDR associated with the resource will no longer be allocated from an IPAM pool, but the CIDR itself will remain unchanged."
Your VPCs keep working, on the same addresses, with the same routing. What goes away is IPAM's tracking of them.
Cascade destroys all CIDR address history irreversibly. Every record of which range was allocated to what, when, and by whom is gone the moment the IPAM is deleted, with or without cascade. There is no undo, no export and no backup: AWS offers address history only as a per-CIDR lookup with no bulk read, so neither you nor Prism can take a copy first.
If that history matters, capture what you need before you tear down.
Cascade refuses outright if any pool exists in your public scope. This is why Prism refuses to create public-scope pools at all: with that rule in place, the escape hatch is always reachable. If your IPAM was adopted and already has public-scope pools, Prism deletes those pools and their CIDRs first, and tells you it is doing so, rather than presenting a disabled button with no path forward.
Force delete requires typing your customer ID, and Prism records who confirmed it and when.
The Residue Ledger
Teardown is incomplete in specific, enumerable ways. All of them are shown before you confirm, and the top three are repeated in the confirmation dialog. This is the full list.
| # | What is left behind | Can Prism remove it? |
|---|---|---|
| 1 | All CIDR address history, destroyed irreversibly by deleting the IPAM, with or without cascade. Not a leak: data loss that cannot be undone or backed up | No. Stated before you confirm |
| 2 | Every VPC, subnet and Elastic IP keeps its CIDR. Cascade stops IPAM tracking them; it does not touch the addresses themselves | Not applicable: this is correct behaviour, stated because "deallocates CIDRs from live VPC resources" reads as "the VPC goes away" if it is not said plainly |
| 3 | Pools blocked by resource-backed allocations, named by resource id and account | No, by design. Remove the resource yourself, then retry |
| 4 | The AWSServiceRoleForIPAM service-linked role, created by AWS in the host account and in every enrolled account. Neither cascade nor deleting a resource discovery removes it | No. Prism cannot remove it. Verify and delete it yourself in the AWS console if you want a clean account |
| 5 | RAM shares in accounts Prism can no longer reach: a member that was deboarded from Prism between enabling and disabling. Named by account id | No. Delete the share in that account |
| 6 | A member's record of having accepted a RAM invitation stays in that account's RAM history after the share is deleted | Cosmetic. Disclosed anyway |
| 7 | An adopted IPAM keeps metering. If Prism adopted an IPAM you already owned, teardown leaves it running (it is yours) and it continues to bill for everything still associated to it. Every association Prism could not remove is listed | No. Delete it yourself, or accept the charge |
| 8 | If teardown lands in partial failure or blocked with the IPAM alive, you are STILL BILLING at Advanced rates across your entire enrolled footprint | Retryable. Re-run disable from Settings. See below |
| 9 | Whether AWS prorates the hourly meter on deletion | Unknown, so nothing in the product promises it |
Prism never deletes anything it did not create. Ownership is decided by the tags Prism applies at creation time, never by a resource's name. An IPAM, pool, scope, resource discovery or RAM share that merely happens to be named like Prism's is treated as yours and left alone, and adopted resources are reported to you on teardown rather than discovered later in the console.
If Teardown Does Not Finish, You Are Still Billing
This is the loudest line in the capability, and Prism does not let it scroll away.
When teardown ends in blocked or in partial failure with the IPAM still alive, a persistent, non-dismissible banner sits on the Dashboard:
The IPAM is still running and still billing. Teardown failed for N of M accounts. Advanced-tier charges continue until the IPAM itself is deleted. → Retry teardown
A warning that can be dismissed is not a warning while a meter is running.
The wording throughout the product is "billing stops when AWS reports the IPAM deleted", never "charges stop immediately". Whether AWS prorates the hourly meter on deletion is not something Prism can observe, so it does not promise it in either direction. What Prism can tell you is exactly when AWS confirmed the IPAM was gone.
Partial Failure
If any step genuinely fails, the configuration stays in partial failure rather than moving to disabled, deliberately:
- The affected accounts stay visible so you can retry them
- The permission policies are not detached: a configuration that can never report clean can never release the credentials teardown needs
- The cached inventory is retained
- The status message names every account that did not tear down
Re-open Settings > Danger zone and disable again to retry. Repeated teardown is safe.
Adopted resources left in place are never a teardown failure. Skipping something Prism does not own is the intended outcome, and it never holds the configuration in partial failure. Those skips are reported separately, as a note, so you know what is still there.
A member account that left your AWS organization is reported as a note, not a failure. Prism cannot make calls into an account that has departed, so those steps are recorded as unreachable rather than counted against the teardown's status. The host-side work (disassociating that account's discovery, which frees an association slot) is always attempted, because the host has not gone anywhere.
After a Clean Teardown
When every step succeeds:
- The IPAM, its scopes, its pools and every Prism-created resource discovery and RAM share are deleted
- The IPAM permissions policy is detached from every account's access role
- Prism's cached inventory is cleared
- The status moves to
disabledand the setup wizard is shown again
You can re-enable at any time. A fresh enablement starts a new cold start, a new IPAM, and a new empty address history. The previous one is not recoverable.
Re-enabling recreates the meter. Everything in Advanced tier is mandatory and billed applies again from scratch, and you will be asked to acknowledge the cost again.
Related Pages
- Settings, Where the Danger zone lives, and the tier and cost figures
- Pools, Manual and resource-backed allocations, and why one of them blocks deletion
- Accounts, Removing a single account rather than tearing everything down
- Address Space, Address history, and why it cannot be exported
- VPC IPAM, The meter, the architecture, and what enabling commits you to
- Security Hub Issues, Troubleshooting disable operations