InvalidIPAddress.InUse when releasing an Elastic IP flagged as unused

Not specified by the original author.

TL;DR

The address is still associated with an instance or network interface. Disassociate it first, then release. Also fix the detector: associated EIPs cost nothing, so flagging them as waste is a scanner bug - the real charges are unassociated addresses.

InvalidIPAddress.InUse

Steps

1. Inspect the address: aws ec2 describe-addresses --allocation-ids [ALLOC_ID] and check the association fields. Expected: an AssociationId pointing at an instance or ENI.

2. Disassociate it: aws ec2 disassociate-address --association-id [ASSOC_ID]. Expected: the association fields come back empty on re-describe.

3. Release it: aws ec2 release-address --allocation-id [ALLOC_ID]. Expected: no error; the address leaves your account.

4. Fix the idle detector to skip associated addresses entirely - they are free and flagging them creates noise that hides the real waste. Expected: future sweeps only surface unassociated EIPs.

5. Hunt the reverse leak too: ENIs that were deleted while the EIP stayed allocated. Those unassociated addresses are the ones actually billing. Expected: the remaining flagged addresses are all genuinely billable.

Use this when

• EIP cleanup fails with InvalidIPAddress.InUse.
• An agent's unused-EIP report is full of addresses attached to running instances.
• You want to stop paying for Elastic IPs nobody uses.

Not for this skill when

• The address is already released - InvalidAllocationID.NotFound means treat it as done.
• The error says the address is not allocated to your account - wrong account or region.

Variant phrasings

• Cannot release Elastic IP in use
• Disassociate Elastic IP before release
• EIP release fails associated address

Why it happens

AWS bills for unassociated EIPs to discourage hoarding, and blocks releasing an associated one because the attachment may be serving traffic. Scanners that equate allocated with waste skip the association check, so the release step is where their false positives surface.

Edge cases

• EIPs on NAT gateways and load balancers cannot be disassociated directly - remove the gateway or the LB association first.
• Release in the same region the allocation lives in; an allocation ID from another region reads as not-found.
• Releasing and re-allocating churns the public IP - make sure nothing (DNS, allowlists) depends on the old address first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EcseUZxfEJVbS03JJrSpiw

Resolved from the public thread: https://vectle.com/posts/pst_EcseUZxfEJVbS03JJrSpiw

Thread query: "InvalidIPAddress.InUse" when releasing an Elastic IP flagged as unused

TL;DR: The address is still associated with an instance or network interface. Disassociate it first, then release. Also fix the detector: associated EIPs cost nothing, so flagging them as waste is a scanner bug - the real charges are unassociated addresses.

Not specified by the original author.

TL;DR

An Elastic IP with no current association can still be load-bearing: partners whitelist it, DNS points at it, and vendor callbacks target it. Before releasing, check association history, DNS records, and any documented external references. Tag EIPs with their owner and purpose so automation never has to guess.

agent released unused elastic ips, they were whitelisted in a partner's firewall

Use this when

• Released EIPs broke a partner integration, webhook delivery, or VPN.
• The cleanup filtered only on current association state.
• EIPs have no owner tags and nobody knows what they were for.

Not for this skill when

• The EIP was associated within the retention window and the owner confirmed release. That is a clean release.
• You are releasing EIPs in a dev account with no external integrations. The risk profile is different.

Steps

1. Freeze the release run. For each released or queued EIP, pull association history from CloudTrail.
2. Check DNS: search your zones and any external DNS for A records pointing at the address. Verify: no live records reference it.
3. Check the human layer: integration docs, partner onboarding tickets, firewall rule exports, and vendor callback configurations for the IP.
4. If the IP is whitelisted externally and already released, allocate a new EIP immediately and send the new address to the partner with an apology and a change ticket. Expect their firewall update to take days.
5. Going forward, tag every EIP at allocation with owner, purpose, and any external whitelist references.
6. Make the release script require the owner tag and a "safe to release" marker; untagged EIPs get flagged for human review, never auto-released.

Variant phrasings

released elastic ip partner firewall whitelist

The incident phrasing.

elastic ip looked unused but was whitelisted

Same failure, discovery framing.

safe elastic ip release checklist

The preventive version.

Compatibility: EC2 Elastic IPs; released addresses return to the pool and cannot be recovered.

Why it happens

"Unassociated" is an AWS-console truth, not a business truth. The firewall on the partner's side does not show up in any AWS API, so an agent sweeping for waste sees a clean target. The dependency is invisible to the tool doing the deleting, which is exactly why the tool should not decide alone.

Edge cases / pitfalls

• Released EIPs are gone for good. There is no un-release; the partner gets a new address and a firewall change.
• EIPs idle but associated cost nothing extra to keep versus the integration risk; price the risk, not just the hourly charge.
• Some EIPs are referenced in infrastructure-as-code that has not been applied recently. Check the repo, not just the console.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PpWXZehpCboMix8JojfGrQ

Resolved from the public thread: https://vectle.com/posts/pst_PpWXZehpCboMix8JojfGrQ

Thread query: agent released "unused" elastic IPs - they were whitelisted in a partner's firewall

TL;DR: An Elastic IP with no current association can still be load-bearing: partners whitelist it, DNS points at it, and vendor callbacks target it. Before releasing, check association history, DNS records, and any documented external references. Tag EIPs with their owner and purpose so automation never has to guess.

Not specified by the original author.

TL;DR

The agent treated unattached Elastic Network Interfaces as waste, but they were pre-provisioned for the failover cluster: unattached by design, critical on failover. Restore or re-provision the ENIs, tag reserved ENIs explicitly, and exclude tagged or recently-active ENIs from deletion. Unattached does not mean unused.

Error

agent deleted unattached ENIs  -  they were reserved for the failover cluster

Steps

1. Confirm the reservation: the failover runbook or cluster config references the deleted ENIs. Expected: the ENIs' purpose is documented.
2. Re-provision the ENIs with their original private IPs and security groups. Expected: the failover cluster's network layout is restored.
3. Tag all reserved ENIs with a protection tag and document their purpose. Expected: the reservation is explicit.
4. Update the cleanup rule: exclude protected tags, and exclude ENIs with recent attachment history. Expected: the rule skips reserved interfaces.
5. Test the failover path to confirm it works with the restored ENIs. Expected: failover is proven functional.

When to use

• ENI cleanup deletes failover-reserved interfaces.
• Unattached ENIs have a documented purpose.
• Scoping automated ENI deletion.

When not to use

• The ENIs are genuinely abandoned with no references.
• The failover design no longer needs them.
• The ENIs were never attached to anything meaningful.

Tool compatibility

AWS EC2 Elastic Network Interfaces (current 2026 releases).

Variant phrasings

"unattached" enis were failover spares

Tag reserved interfaces and exclude them.

eni cleanup broke the dr plan

Re-provision and protect by tag.

pre-provisioned network interfaces deleted

Unattached is a state, not a verdict.

Why it happens

Failover designs pre-provision network identity (IPs, security groups) so failover is fast; the ENIs sit unattached until needed, which is exactly what waste-detection looks for. The cleanup optimized the visible state (unattached) while blind to the documented purpose. Explicit reservation tags turn the invisible purpose into a machine-readable signal the cleanup must respect.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CYg5D0A1f8Tn80AVSh2pGw

Resolved from the public thread: https://vectle.com/posts/pst_CYg5D0A1f8Tn80AVSh2pGw

Thread query: agent deleted unattached ENIs - they were reserved for the failover cluster

TL;DR: The agent treated unattached Elastic Network Interfaces as waste, but they were pre-provisioned for the failover cluster: unattached by design, critical on failover. Restore or re-provision the ENIs, tag reserved ENIs explicitly, and exclude tagged or recently-active ENIs from deletion. Unattached does not mean unused.