Unattached Elastic IPs: Why AWS Bills Them and How to Release Them Safely

So usually when we talk about cloud infrastructure, right, there's this basic expectation of cause and effect. Yeah, exactly. You spin up an instance, you see it running and you pay for it, then you turn it off and the billing stops. Right. That's the logical way it should work.

Right. But in February 2024, AWS completely changed how they bill for public IPv4 addresses and that logic just kind of broke down. It really did. Because since then, AWS bills for every single public IPv4 address at half a cent per hour or, you know, $0.005, whether it's actually attached to a resource or just doing absolutely nothing. Yeah.

And the billing mechanics here are exactly why it catches so many engineering teams off guard. Oh, for sure. I mean, let's say you terminate an EC2 instance, but the Elastic IP, you know, that dedicated static public address you reserved specifically for it is just left behind. Right. The meter just keeps running.

Exactly. Rate times hours equals cost, so that one leftover address costs about $3.65 a month. Wow. And today on this deep dive, we are looking at some engineering notes and AWS billing documentation. And our mission is basically finding and fixing this invisible infrastructure that's secretly draining your cloud budget.

Which is super important. Because you know, you might be listening to this thinking, well, it's only three bucks in change. But as an illustration, if you have hundreds of orphaned IPs across dozens of accounts over a year, you are paying a lot of money for literally nothing. Oh, absolutely. It's basically like paying a monthly parking garage fee for a car you already sold.

Which I mean, it raises the question, why doesn't AWS just automatically delete the IP when the instance is terminated? Well, because you might actually want to keep that static IP to attach to a replacement server later. Oh, right. AWS does not know your intent. So it becomes this classic organizational trap.

These orphaned IPs survive because they just accumulate silently. Right. Because no one is really watching them. Yeah, exactly. Nobody explicitly owns an IP address once the server it was attached to is gone.

They don't trigger standard infrastructure alarms. And they remain completely invisible on a per-service bill. So if they are slipping past the usual billing dashboards, we basically have to go looking for them manually? You do. I mean, I have run the DescribeAddresses API call before, and it just spits out this massive JSON file.

So I assume we're looking for a specific field that tells us if the IP is actually bound to an instance. Yes, the signal is straightforward. You just look at the returned elastic IP. If it has no association ID, it is attached to nothing. Okay.

Well, if finding them is as easy as spotting a blank association ID, the logical next step would just be to script a mass release of all those IPs, right? Just to stop the bleeding. I wouldn't touch that delete button just yet. Really? Why not?

Releasing an elastic IP is a one-way street, and it is permanent. Once you hit release, that specific IP address goes straight back into the AWS public pool. Oh, wow. Yeah, you usually cannot get that same address back. And you can never call a resource provably or guaranteed unused.

There's just no check or preview command that makes a delete risk-free. But I mean, if the IP is completely detached from my AWS account, and it's missing that association ID, it feels like it should be safe to delete. You'd think so, but you have to worry about external dependencies that are still looking for it. Ah, right. That's the real danger.

Before releasing one, engineers must verify if a DNS record is still pointing to it. That makes sense. You also have to check if a firewall allow list or a partner's configuration still references that exact IP. Think about the mechanics here. If a partner has hard-coded your IP into their firewall allow list, and you release that IP back to AWS, someone else immediately claims it.

Oh, I see where this is going. Yeah, your partner's firewall is now letting a stranger's traffic through instead of yours and releasing it breaks your integration permanently. Man, so an orphaned IP might be detached internally, but still deeply wired into your external business logic. Exactly. You really have to track down those DNS and firewall references first.

That is the necessary work, yeah. I mean, doing the manual DescribeAddresses check is a perfectly good way to find these. Right. But there is another option. It's a free, source-available scanner.

You just run pip install cloudcostwise. It runs read only on your own machine, flags this pattern and sends nothing to CloudWise. Nice. So it's a solid way to spot the leak without, you know, shipping your data out. Exactly.

Which really leaves us with a final thought for you to take away as you review your own environment today. Around orphaned IPs, what other invisible infrastructure is currently sitting idle in your AWS account, quietly charging you rent while waiting for a server that just no longer exists?