Release unattached Elastic IPs

An Elastic IP is just a public internet address that a workload uses to be reachable. The relevant fact for the bill is simple: AWS charges a small hourly fee — about $3.65 a month — for an address that is allocated to your account but not actively attached to a running machine. It has always worked this way for idle addresses. Since early 2024 AWS also charges for the addresses that are in use, at the same rate, because IPv4 addresses are genuinely scarce and AWS is pricing accordingly.

This finding is about the idle ones — addresses left behind when a server was deleted, when a machine was switched off, or when a piece of networking was decommissioned but the address was never handed back. Each one is roughly $3.65 a month, forever, on no activity. That sounds trivial, and per address it is. The reason it lands on a cost report is aggregation: a few hundred stranded addresses across dozens of accounts is comfortably over $1,000 a month of pure waste, recurring indefinitely, attached to nothing.

For budgeting purposes this category behaves like other small-but-sticky hygiene items: it's easy to create (anyone can allocate an address), it survives the resource it was meant for, and nobody feels ownership of it. The right framing at a cost review isn't "how big is the IP bill" — it's "how many addresses are we paying for that aren't attached to anything, and is that number flat?" A growing count is a tagging-and-lifecycle signal long before it's a dollar problem.

Priya is the finance partner embedded with the platform team. At the monthly cost review a new-ish line — "public IPv4 / Elastic IP" — has been ticking up since the 2024 pricing change, and she asks the question that's now standing on the agenda: "How many addresses are we paying for that aren't attached to anything, and what's that costing us a month?" The answer is 47 addresses, about $172 — small in absolute terms, but it's been growing every month, which is the part that matters.

The conversation isn't technical. Priya doesn't ask about subnets or interfaces. She asks three things: how many are genuinely orphaned versus pinned for a reason, who can confirm the orphaned ones aren't referenced off-platform, and how long the cleanup takes. The platform lead explains that releasing them is near-zero-risk except where something external — a customer firewall rule, a DNS record — points at the address, and that the check for that is quick. Priya gets a commitment to clear the orphans this sprint and to add the count to the recurring finance pack so it can't drift back up unnoticed.

Two months later the same line shows a residual of about $7 — two intentionally pinned addresses with documented owners. Priya knows that's the right floor, and she knows that if the orphan count climbs back above a handful, it means cleanup isn't closing the loop after instances are deleted. The dollar figure is small; she treats the count and its trend as the real metric.

The direct line-item impact is small per resource and only matters in aggregate. Most environments carry somewhere between a few dozen and a few hundred dollars a month of orphaned-address cost — a fraction of a percent of total cloud spend. It won't move a quarterly number on its own, but it's exactly the kind of charge that lands in "unexplained variance" when budgets are tight, and finance ends up asking what a vague "public IPv4" line even is.

The 2024 pricing change is the part worth understanding at a budget level. A standing per-address fee on every public IP appeared with no architectural change on your side — so a chunk of this line is now structural, not waste, and reducing it means engineering decisions (fewer public addresses, IPv6 adoption) rather than cleanup. The orphan subset is the part you can act on immediately; separating "waste we can release this month" from "structural cost that needs an architecture change" is the useful framing to bring to the review.

This category also tests chargeback. Orphaned addresses are by definition unowned — the resource they served is gone — so the cost can't be cleanly assigned to a team. Every untagged orphan is a dollar that gets absorbed centrally or argued over. Making teams own (and release) the addresses tied to resources they decommission keeps the chargeback model honest at near-zero effort.

Treat it as a leading indicator. A growing orphan count — separate from the dollar amount — is one of the cleanest signals that cleanup isn't closing the loop when resources are deleted. That same gap predicts larger waste categories (idle volumes, stopped instances, unused gateways) drifting in the same direction. Watch the count and its trend, not the absolute spend.

AWS charges for public internet addresses — both the ones in active use and, the focus here, the ones left allocated to the account but attached to nothing. Each orphaned address is a few dollars a month forever; at organisation scale the aggregate becomes a recurring drag from infrastructure that was decommissioned but never fully cleaned up.

This is a hygiene signal more than a cost story. A handful of stranded addresses says cleanup isn't closing the loop after resources are deleted — the same discipline gap that produces larger waste elsewhere. The fix is low-risk reclamation plus a convention that addresses are released when the thing they served goes away.

At one company the quarterly cloud review carried a line that nobody could quite explain: a public-IP charge that had appeared after the 2024 pricing change and kept inching up. The exec sponsor stopped asking what it cost and started asking the better question: "How many of these addresses are attached to nothing, and why don't we hand them back when we delete the thing they served?"

Within a quarter the line stopped growing. The team adopted a simple rule — when a workload is decommissioned, its address is released as part of the same change — and added the orphan count to the standing report. The residual settled at a handful of deliberately pinned addresses, each with a named owner and a reason. The dollar saving was modest; the point was that the line had become a confidence signal instead of an unexplained creep.

That's the right outcome state. "Zero public IPs" is the wrong goal; "every address we pay for is either attached to something or deliberately pinned with an owner" is the right one. The report stops being a question mark and becomes evidence the cleanup loop works.

The dollar amount is usually small. It's tracked because its size and trend report on the discipline underneath: a small, flat, fully-tagged residual means cleanup is closing the loop when resources are deleted; a growing orphan count means it isn't, and the same gap almost certainly applies to bigger spend categories that don't surface as cleanly.

There's a second-order angle. A forgotten public address that still resolves in DNS, or one a partner still allowlists, is an audit and security loose end as much as a cost one. So this category sits where cost, security posture, and operational hygiene meet — modest in dollars, useful as a signal, and cheap to keep clean.