Seeing a surprise AWS bill increase? You’re not alone. AWS started charging for all public IPv4 addresses, but here’s how to find and eliminate those hidden costs before your CFO notices.

So, Your AWS Bill Jumped. Let’s Talk About Those Public IPs.

I remember a Monday morning that started with a Slack DM from our finance lead. All it said was, “Cloud spend is up 8% this month. Why?” My coffee hadn’t even kicked in. After a frantic 20 minutes of digging through Cost Explorer, I found the culprit. It wasn’t some massive new database or a runaway Lambda function. It was a swarm of tiny, seemingly insignificant charges: $0.005/hour. Multiplied by hundreds of forgotten dev instances, idle Elastic IPs, and even network interfaces someone forgot to detach, it had become a death-by-a-thousand-cuts situation. That’s the new reality we live in, and if you haven’t been hit by it yet, you will be.

The “Why”: What Changed and Why Your Wallet is Lighter

Let’s get this straight. For years, we got a “free” Public IPv4 address with any running EC2 instance. It was a given. We spun up a `t3.micro` for a quick test, it got a public IP, and we didn’t think twice. Well, the party’s over. As of February 1, 2024, AWS started charging for every single Public IPv4 address in use. The official reason is the global exhaustion of IPv4 addresses, and this is their way of encouraging more efficient use (and, let’s be honest, opening a new revenue stream).

The charge applies to IPs associated with EC2 instances, Elastic IPs (both associated and unassociated), and any other resource that grabs a public IPv4. It doesn’t matter if the instance is running or stopped. If it’s holding onto that IP, the meter is running.

Solution 1: The Quick Fix – “Find and Destroy”

Okay, your boss is breathing down your neck. We need to stop the bleeding, now. This is the manual, brute-force approach to find the low-hanging fruit.

Step 1: Hunt Down Unused Elastic IPs

This is the most common offender. These are IPs you allocated but never associated with an instance, or the instance they were attached to has been terminated. They’ve always cost money, but now they’re easier to miss among the new charges.

Go to the EC2 Console -> Elastic IPs. Look for any that don’t have an “Associated instance ID”. If you don’t need it, release it. Done.

You can also use the AWS CLI, which is much faster:

# This command lists all EIPs that are not associated with anything.
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null].AllocationId' --output text

Pipe those Allocation IDs to the `aws ec2 release-address` command and you’re golden.

Step 2: Audit Public IPs on Running/Stopped Instances

This is the new charge. You need to find instances that have a public IP assigned directly but don’t actually need one. A classic example is a junior dev’s `temp-poc-server-01` that was spun up in a public subnet “just to make it work” and then forgotten. Go through your EC2 list and ask the hard question: “Does this machine really need to be accessible from the entire internet?” If not, disassociate the public IP.

Solution 2: The Permanent Fix – “Stop the Bleeding by Design”

Manually cleaning up is fine once, but you’re a senior engineer. Your job is to build systems that prevent the problem from happening again. This means changing how you think about network architecture.

Rethink Your VPCs: Private is the New Default

Your default posture should be that nothing lives in a public subnet unless it absolutely has to. Your web servers, application servers, and especially your databases (`prod-db-01` should NEVER have a public IP) belong in private subnets.

Warning: Be mindful that NAT Gateways have their own costs (per hour + data processing). But for most architectures, a single NAT Gateway per AZ is far cheaper and more secure than paying for dozens of individual Public IPs.

Solution 3: The ‘Nuclear’ Option – “Deny by Default”

Sometimes, education and best practices aren’t enough, especially in a large organization with developers of varying skill levels. If you manage an AWS Organization, you can enforce the “no public IPs” rule with a Service Control Policy (SCP).

This is the big hammer. You can apply an SCP to an entire OU (like your “Developer_Sandbox” OU) that explicitly denies the ability to create or associate public IPs.

Here’s a sample SCP that blocks users from creating network interfaces with public IPs. It’s a “hacky” but effective way to stop the auto-assignment in public subnets.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:CreateNetworkInterface",
      "Resource": "arn:aws:ec2:*:*:network-interface/*",
      "Condition": {
        "Bool": {
          "ec2:AssociatePublicIpAddress": "true"
        }
      }
    }
  ]
}

Heads Up! This is a powerful and potentially breaking change. Test this thoroughly in a non-prod OU first. You will absolutely break applications that rely on this behavior if you roll it out without planning. But for enforcing a security and cost-control posture, it’s incredibly effective.

So, take a deep breath. That surprise bill isn’t a disaster; it’s a wake-up call. It’s forcing us to build better, more secure, and more cost-effective architectures. Now go hunt down those IPs.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions