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.

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