Removing an Idle Public IP From a Running EC2 Instance

For months, a public IP sat idle on one of my EC2 instances, quietly incurring cost for no reason. It had been there since day one — but all traffic actually routed through CloudFront to an internal ALB, which made the public IP completely redundant.

I knew it needed to go. And yet the phrase "remove a public IP from a running EC2 instance" felt daunting — the kind of task that sounds like it's one wrong click away from an outage, buried under pages of AWS documentation. So I did what's easy to do with jobs like this: I procrastinated.

The root cause wasn't where I expected

When I finally sat down to tackle it (with Claude Code as a pair), the first useful realisation was that the problem wasn't the instance at all. It was the subnet's MapPublicIpOnLaunch setting — the subnet was handing every new instance a public IP automatically.

That reframes the whole task. You can't strip a public IP off an already-running instance; AWS simply doesn't let you mutate that in place. So the fix isn't "edit the instance," it's "fix the subnet, then replace the instance cleanly."

The actual procedure

Here's what the change came down to:

• Create an AMI of the current instance — a full disk snapshot, so the replacement is identical to what's running today.
• Flip the subnet setting so new instances no longer get a public IP on launch.
• Run terraform apply -replace, which spins up a fresh instance from the AMI, re-registers it with the ALB, and terminates the old one.

Because the ALB drains and health-checks the new target, the cutover is controlled rather than abrupt.

The result

Total downtime was roughly 90 seconds — entirely the ALB health-check window as the new instance came into service. Start to finish, from understanding the root cause to applying the change, it took about 30 minutes of focused effort.

That's the part worth dwelling on: the task wasn't actually difficult. What had kept it on my list for months wasn't a knowledge gap — it was a confidence gap. I didn't want to be the person who took down a running service over a cost-optimization nit.

The real shift

What changed is that having an AI pair to reason through the "what could go wrong here" reduces the activation energy for exactly these tasks — the small, annoying, easy-to-postpone ones that never feel urgent enough to risk a disruption.

A redundant public IP is a tiny line item. But "tiny and easy to postpone" describes a huge amount of infrastructure cleanup, and those little items add up — on the bill and in the mental backlog. Lowering the barrier to just do them is its own kind of win.

No more procrastinating on the small-but-annoying tasks.