Delete unused Elastic Network Interfaces

An Elastic Network Interface is the virtual network card that lets a cloud machine connect to the network. The fact that matters for the bill is counterintuitive: the network card itself doesn't cost anything to leave lying around — AWS doesn't meter an idle one. So on its own, this finding isn't a direct line item the way an idle disk or an idle address is.

The reason it still shows up on a cost report is that a leftover network card very often has a public internet address still clipped to it, and that address is billed — about $3.65 a month each since AWS started charging for all public IPv4 in early 2024. So an orphaned interface is frequently a hidden IPv4 charge in disguise. Just as important, these leftovers are the clearest evidence that cleanup didn't finish: they're what's left when a server, a load balancer, or a serverless function was deleted but its plumbing wasn't. And they physically block other cleanup — you can't retire the security groups or network segments they're attached to until they're gone.

For budgeting, treat this as a leading-indicator and hygiene category rather than a dollar category. The right question at a cost review isn't "how much do network interfaces cost" — it's "how many detached, non-managed interfaces are we carrying, how many of them have a billed IP attached, and is that count flat?" A growing count says cleanup isn't closing the loop, which reliably predicts bigger waste categories drifting the same way.

Lena is the finance partner embedded with the platform team. "Unused network interfaces" appears on the wastage dashboard with a count of 64 and a tiny dollar figure, and she asks the question that's now standing on the agenda: "How many of these are truly orphaned versus owned by AWS services, and how many are carrying a public IP we're actually paying for?" The platform lead's answer is the useful one: the interfaces themselves are free, 19 belong to managed services and can't be touched, and 22 of the rest hold a billed address — so the real money is about $80 a month, plus a stuck decommission the leftovers are blocking.

The conversation isn't technical. Lena doesn't ask about subnets or MAC addresses. She asks three things: how many are safe to delete (orphaned and not service-owned), how many of those carry a billed IP, and whether anything else is blocked by leaving them. The split — 19 managed, 45 orphaned, 22 of those costing money, one subnet teardown waiting on them — is enough to act. She gets a commitment to clear the 45 this sprint and to add the orphan count and the attached-IP subset to the recurring finance pack so neither drifts back up unnoticed.

Two months later the residual is a handful of interfaces, all tagged as managed or deliberately kept. Lena knows that's the right floor, and she knows that if the orphan count climbs again it means cleanup isn't closing the loop after resources are deleted. The interface count is a hygiene metric; the attached-IP subset is the part with a dollar sign; she watches both as trends, not as a one-time number.

The direct line-item impact is unusual for a wastage category: the interfaces themselves are free, so a count of leftover network cards isn't a cost in itself. The dollars live in a subset — the ones still holding a billed public address — and that's typically a few dozen to a few hundred dollars a month, a fraction of a percent of cloud spend. The useful framing for finance is to split the count from the cost: report how many orphaned interfaces exist, and separately how many of those carry a billed IP, because only the second is money.

The larger budget impact is indirect and worth understanding. Leftover interfaces block the retirement of the network components around them, which is why account and environment decommissions — the kind of cleanup that produces real, lasting savings — stall. When a teardown that should remove a whole environment's spend sits unfinished for a quarter because of forgotten plumbing, the cost isn't the interface; it's the savings you didn't capture. This category is often the literal blocker on bigger wins.

This also tests chargeback in a specific way. Orphaned interfaces are by definition unowned — the resource they served is gone — so neither the (zero) interface cost nor the attached-IP cost can be cleanly assigned to a team. Making teams own and delete the interfaces tied to resources they decommission keeps the model honest, and the precision requirement (don't touch service-managed ones) is a reminder that this is engineering-owned cleanup, not something finance can script.

Treat the orphan count as a leading indicator. A growing count of detached, non-managed interfaces is one of the cleanest signals that cleanup isn't reaching the plumbing when resources are deleted — and that same gap predicts larger waste categories (idle volumes, stopped instances, unattached addresses) drifting the same way. Watch the count and its trend, plus the attached-IP subset for the actual dollars.

When a cloud resource is deleted, the virtual network card it used can be left behind — attached to nothing, doing no work. The card itself isn't billed, but it often still holds a public internet address that is billed, and it physically blocks the retirement of the network components around it. So it's a small, hidden cost wrapped inside a bigger hygiene problem.

This is a discipline signal more than a cost story. A pile of leftover interfaces says cleanup stops at "delete the server" and never reaches the plumbing — the same gap that produces larger waste elsewhere. The fix is low-risk reclamation, with one careful caveat: many interfaces belong to AWS-managed services and must be left alone, so the work is about deleting the right ones, not all of them.

At one company a VPC decommission had been "almost done" for two quarters — blocked, it turned out, by a layer of forgotten network plumbing nobody had cleaned up. The exec sponsor stopped asking when it would finish and started asking the better question: "Why does deleting a server leave this much behind, and why isn't releasing it part of the same change?"

Within a quarter the pattern changed. The team adopted a simple rule — retiring a workload includes deleting its leftover interfaces and releasing any address they carry — and added the orphan count to the standing report. The blocked decommission finished, the hidden IPv4 charges fell off, and the residual settled at a small number of service-owned interfaces that are supposed to be there. The dollar saving was modest; the point was that cleanup now reached all the way down.

That's the right outcome state. "Zero network interfaces" is the wrong goal — many are owned by AWS and must stay. "Every interface we carry is either in active use, owned by a managed service, or deliberately kept" is the right one. The report stops being a stuck ticket and becomes evidence the cleanup loop works end to end.

The direct dollar amount is small or zero — the interface itself is free, and only the subset holding a public address costs anything. It's tracked because of what its size and trend report about discipline: a small, stable count means cleanup reaches the plumbing when resources are deleted; a growing count means it stops at "delete the server," and the same gap almost certainly applies to bigger spend categories. It's also the category that most often blocks environment decommissions, which is where the larger savings actually are.

There's a second-order angle. A forgotten interface that still carries a public address — one that resolves in DNS or sits in a partner allowlist — 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, with the one caveat that it must be cleaned precisely because many interfaces are AWS-owned.