AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list

An unattached Elastic IP now costs the same as one that's busy: $0.005 an hour, roughly $3.60 a month, for every public IPv4 address AWS has allocated to you, attached or not. An idle Application or Network Load Balancer costs even more — about $16 a month just to exist, before it routes a single request. And here's the part almost nobody expects: AWS's own Trusted Advisor "Idle Load Balancers" check, the tool built to catch exactly this waste, only looks at Classic Load Balancers. It has never checked an Application Load Balancer or a Network Load Balancer for being idle — which happens to be what almost every AWS account runs today.

Jake found out about this the annoying way. Three months after his part-timer set up a staging environment for the shop's new trade-in appraisal tool, Jake noticed a $31 line item on the AWS bill that hadn't been there before, next to a service he'd never heard anyone mention: "Virtual Private Cloud." Nobody had touched that project since March. Nothing was broken. Nothing was running, as far as he could tell. And yet the bill kept climbing, month over month, for three EC2 instances that had long since been terminated.

"That's the thing about AWS," Ethan told him. "You can delete every instance you launched and still get billed forever, because the instance was never the expensive part. It's what got left behind — the IP address, the load balancer — that keeps the meter running. AWS doesn't send you a reminder. It just quietly bills you $0.005 an hour until you notice, or until you don't."

What "standing waste" actually costs you every month

"Standing waste" is a useful way to think about the resources this article covers, because none of them are doing anything, and none are expensive enough on their own to notice, but every one of them bills continuously whether you're using it or not. An unattached Elastic IP, an idle load balancer, and a Global Accelerator nobody remembered to delete all share the same failure pattern: someone provisioned them for a project, the project ended, the resource didn't get deleted, and it has been quietly accruing charges ever since — sometimes for years.

Here's what that actually adds up to for a typical account that's been running for a while and hasn't done a cleanup pass:

None of these numbers look dangerous in isolation. That's exactly the design flaw in how people notice them — a $3.60 line item never triggers an investigation on its own. It's the accumulation across regions, projects, and years that turns "standing waste" into a real number on the annual bill.

Why Elastic IPs quietly cost money now

An Elastic IP, or EIP, is a static public IPv4 address you reserve inside your AWS account. Unlike the public IP an EC2 instance gets automatically, which changes every time you stop and start the instance, an EIP stays the same until you release it — useful for DNS records, allowlists, and failover setups where the address itself has to stay constant.

The charge covers public IPv4 addresses across your VPC resources, AWS Global Accelerator's static addresses, and AWS Site-to-Site VPN tunnels — not just EC2. NAT Gateway public IPs, unattached network interfaces, and load balancer public IPs all count too. The one exception: addresses you've brought into AWS yourself through Bring Your Own IP (BYOIP) aren't billed under this charge, since AWS isn't the one allocating them from its own scarce pool.

The billing shows up under Amazon Virtual Private Cloud in Cost Explorer, split into two usage types: one for addresses that are actively attached to something (PublicIPv4:InUseAddress) and one for addresses sitting unattached in your account (PublicIPv4:IdleAddress). If you've never seen a VPC line item on your bill before and suddenly do, this is almost always why.

The free tier still exists, but it's narrower than people expect

New AWS accounts get 750 hours per month of public IPv4 address usage for EC2 specifically, for the first 12 months. That covers one EC2 instance's public IP running continuously for a full month. It does not cover a NAT Gateway's IP, a load balancer's IP, or a second EIP on the same instance — each of those is billed from hour one, free tier or not. This is the single most common source of "why am I being charged when I'm on the free tier" confusion.

Finding every unattached Elastic IP in your account

Elastic IPs are allocated per region, and the console only shows you the region you're currently viewing. That's the number one reason people miss them: they clean up us-east-1 and never think to check eu-west-1, where a test environment lived for two weeks in 2023 and was never fully torn down.

Method 1: the EC2 console, region by region

1. Open the EC2 console and, in the left navigation pane, go to Network & Security > Elastic IPs.
2. Look at the Associated instance ID column. A blank entry means that address is unattached and is being billed as idle.
3. Click any address to see which network interface or instance it's actually tied to — sometimes an EIP looks orphaned but is quietly attached to an Elastic Network Interface (ENI) that isn't obviously visible, such as one left behind by a deleted NAT Gateway.
4. Switch regions using the region selector in the top-right corner and repeat. Do this for every region your account has ever touched, not just the ones you use today.

Method 2: Cost Explorer, to see what it's actually costing

The console tells you an EIP is unattached. It doesn't tell you what that's costing you over time. For that, open Cost Explorer, set the Service filter to Amazon Virtual Private Cloud, and group by Usage Type. Filter for anything starting with PublicIPv4:IdleAddress, set granularity to daily, and you'll see a flat line climbing steadily — that's the signature of a forgotten address nobody's touching.

Method 3: Trusted Advisor's Unassociated Elastic IP Addresses check

Trusted Advisor runs a dedicated check specifically for this: it flags any allocated Elastic IP address that isn't associated with a running EC2 instance, and it does this across your account automatically, with no setup required beyond having a support plan that includes Trusted Advisor's cost optimization checks. The report is deliberately minimal — it lists the region and the IP address, nothing more — so you'll still need the console to figure out what it was originally for before you decide whether to release it.

Working the AWS CLI across every region at once

If you're managing more than a couple of regions, clicking through the console one region at a time gets old fast. The CLI equivalent of the console check is aws ec2 describe-addresses --region us-west-2 (swap in whichever region you're checking), and the field to look for in the output is the same one you'd look for in the console: an address with no AssociationId is unattached and is the one costing you money for nothing.

Two things worth knowing before you go looking:

• There's a default quota. A new AWS account can typically allocate up to five Elastic IP addresses per region before hitting the account's default EIP limit. If you're wondering why you can't allocate a sixth address in a region, this is usually why — and it's also a decent forcing function to go release what you're not using before requesting a quota increase you might not actually need.
• Not every address in your account came from AWS's own pool. If you've brought your own IP ranges in through BYOIP, aws ec2 describe-public-ipv4-pools shows you which addresses belong to your BYOIP pool rather than AWS's default pool — useful for confirming which of your addresses are actually exempt from the hourly charge before you spend time investigating a bill that BYOIP addresses were never contributing to.

Releasing an Elastic IP without breaking anything

Releasing an EIP is simple in the console — select it, choose Actions, choose Release Elastic IP addresses. What trips people up isn't the release itself, it's not knowing in advance whether the address is actually free to give up, or discovering it won't release at all.

1. Check the address's tags first, if it has any. A tag like Environment: prod-failover is a strong signal to leave it alone even if nothing is currently attached — some failover architectures deliberately keep a spare EIP unattached, ready to be remapped during an incident.
2. Search your DNS zone (Route 53 or otherwise) for the IP address itself. If an A record still points at it, releasing it will break that record the moment someone else's AWS account gets allocated the same address later.
3. Check whether the address is referenced in any security group rules, firewall allowlists, or partner integrations outside AWS. An EIP that looks idle inside your account can still be the address a third party has whitelisted.
4. Once you've confirmed it's safe, release it from the console or with aws ec2 release-address --allocation-id eipalloc-xxxxxxxx if you're scripting a cleanup across regions.

Occasionally the console refuses to release an address at all, or grays out the Disassociate option even though nothing appears to be using it. The most common cause is a reverse DNS (rDNS) record still configured against the address — AWS will lock an EIP with an active rDNS entry until that record is removed. If you've confirmed there's no rDNS record and it's still stuck, opening a support case under the "Account and billing" category will get it looked at even without a paid Business or Enterprise support plan, since it's tied directly to a service you're being charged for.

Global Accelerator: the static IP you can't just switch off

AWS Global Accelerator gives you a pair of static IP addresses that route traffic into your application over AWS's own network backbone, and it's easy to set up and then forget once whatever it was fronting gets replaced. It bills a fixed fee for every hour, or partial hour, that an accelerator exists in your account, regardless of how much traffic it's carrying — and separately, each of its two static IPv4 addresses is billed under the same public IPv4 charge as everything else on this list.

The trap is the "disable" button. Disabling an accelerator stops the data-transfer charges, but it does not delete the accelerator or release its static IP addresses — both keep accruing their charges as long as the accelerator object still exists. There's currently no lighter-weight "pause and pay nothing" state; the only way to fully stop the charges is to delete the accelerator outright, and re-create it later if you need it again. If you're keeping an accelerator around "just in case," know that you're paying full price for that convenience the entire time.

Why idle load balancers cost more than people think

An Elastic IP left standing costs pocket change. An idle load balancer costs meaningfully more, because it bills on two dimensions at once: an hourly charge just for existing, and a usage-based charge on top of that.

An Application Load Balancer bills $0.0225 for every hour or partial hour it's running — that alone works out to roughly $16.40 a month, before it has processed a single request. On top of that hourly charge, AWS bills for Load Balancer Capacity Units, or LCUs, at $0.008 per LCU-hour. An LCU isn't one simple thing; it's the highest of four measured dimensions in a given hour: new connections per second, active connections per minute, gigabytes of data processed, and rule evaluations (the first ten rules processed are free). AWS charges you for whichever dimension was busiest that hour, not the sum of all four. Even an ALB that's carrying almost no real traffic will typically show at least a small LCU charge, because health checks against its target group still count as connections.

Network Load Balancers and Gateway Load Balancers follow the same two-part shape — a base hourly charge plus a usage-based capacity unit charge — with their own rates and dimensions specific to Layer 4 traffic. Classic Load Balancers, the oldest generation, bill differently again: an hourly charge plus a per-gigabyte data-processed charge, with no LCU concept at all. Whichever type you're running, the pattern is the same: the meter starts the moment the load balancer is created and keeps running until you delete it, whether or not it has any healthy targets behind it.

The blind spot in AWS's own idle load balancer check

This is the part worth sitting with, because it's easy to assume Trusted Advisor already has your idle load balancers covered. It doesn't, for most accounts.

AWS documents the "Idle Load Balancers" check plainly: it evaluates your Elastic Load Balancing configuration for load balancers that appear idle, flagging one if it has no active backend instances, no healthy backend instances, or fewer than 100 requests per day over the last seven days. But the documentation is equally plain about its scope — the check currently only examines Classic Load Balancer resources within the ELB service, and explicitly does not include Application Load Balancers or Network Load Balancers.

That matters because Classic Load Balancers are the legacy generation. AWS has been steering everyone toward Application and Network Load Balancers for years, for good reasons — better routing, better health checking, native container and Lambda target support. Which means the resource type Trusted Advisor actually checks for idleness is the resource type fewer and fewer accounts run, while the resource type almost everyone runs today — the ALB fronting a service that got decommissioned, the NLB left behind after a migration — gets no automatic check at all.

Ethan put it more bluntly when a client asked him the same thing. "People treat a Trusted Advisor green checkmark like a receipt that says everything's been reviewed. It's not that. It's a list of specific checks, and each one only covers what it was built to cover. This one was built for a load balancer type most of you stopped using around 2018."

Finding idle ALBs and NLBs Trusted Advisor won't tell you about

Since the built-in check won't flag these for you, finding them means combining the console with CloudWatch metrics yourself. It's more manual, but it isn't complicated.

Step one: check target group health in the console

Open the EC2 console, go to Load Balancing > Load Balancers, and look at each one's associated target groups. A target group with zero registered targets, or with targets that are all showing "unhealthy," is the clearest possible signal — that load balancer has nothing to route to and is billing you for the privilege of standing idle.

Step two: check RequestCount in CloudWatch

Even a load balancer with healthy targets can be effectively abandoned if nothing is actually calling it. Both ALBs and NLBs publish a RequestCount metric to CloudWatch, along with HealthyHostCount and UnHealthyHostCount. Open the metric, set the statistic to Sum, set the range to the last 7 days, and look at the total. There's one quirk worth knowing here: if a load balancer has genuinely had zero requests, CloudWatch won't show a flat line at zero — it simply won't report any data point for that period at all, since Elastic Load Balancing only publishes metrics when requests are actually flowing. A blank, dataless graph over a full week is itself the signal you're looking for.

Step three: cross-reference against Cost Explorer

Filter Cost Explorer by the Elastic Load Balancing service and group by resource where possible, or at minimum compare load balancer hours billed against what you'd expect from your actual running services. A load balancer racking up hundreds of billed hours a month that nobody on the team recognizes by name is worth a five-minute investigation before it becomes a permanent line item nobody questions.

Deleting a load balancer safely

1. Search your Route 53 hosted zones, and any DNS you manage outside Route 53, for records that alias or point to the load balancer's DNS name. If a domain still resolves through it, deleting it will break that domain the moment DNS propagates the failure.
2. Check for any CloudFormation stacks, Terraform state, or CDK apps that manage the load balancer as infrastructure-as-code. Deleting it out-of-band in the console will leave your infrastructure state out of sync and can cause the next deployment to fail or, worse, silently recreate it.
3. Confirm the target group has no registered targets you still need, and detach or note any listener rules that reference it, particularly if it shares a target group with another load balancer.
4. Delete the load balancer from the console under Load Balancing > Load Balancers > Actions > Delete, or via the AWS CLI's elbv2 delete-load-balancer command for ALBs and NLBs.
5. Release any Elastic IP that was dedicated to it, since deleting the load balancer doesn't automatically release EIPs it was using — that's a separate cleanup step, and exactly the kind of orphan the earlier sections cover.

NAT Gateways and the rest of the public IPv4 lineup

Elastic IPs, load balancers, and Global Accelerators aren't the only items on the standing-waste list, just the most common. Every NAT Gateway consumes a public IPv4 address for its gateway automatically, and AWS's per-hour public IPv4 charge applies to that address the same as anywhere else — so an unused NAT Gateway compounds two charges at once: its own hourly NAT Gateway fee, plus the public IPv4 charge for the address it's holding.

AWS's own Trusted Advisor cost optimization checks now cover several of these adjacent culprits directly: an Idle NAT Gateways check, an Inactive NAT Gateways check (specifically for gateways that processed zero bytes over the last 30 days), an Inactive VPC Interface Endpoints check, and an Inactive Gateway Load Balancer Endpoints check. Most of these newer checks require opting into AWS Compute Optimizer and Cost Optimization Hub, which isn't the default state for every account, so it's worth confirming those are switched on if you want the fuller sweep rather than relying on the legacy checks alone.

Automating cleanup so this doesn't come back

A one-time cleanup solves this month's bill. It doesn't stop the same pattern from happening again the next time someone spins up a test environment and forgets to tear it down. AWS's own networking team has published a reference pattern for exactly this: an AWS Lambda function that searches every region in your account for unassociated Elastic IPs, writes what it finds to a CSV in an S3 bucket, and optionally releases them automatically on a schedule. Running something like that monthly, even in report-only mode at first, turns this from a periodic panic into a routine.

Tagging helps too, even without automation. If every EIP, load balancer, and accelerator gets an owner and project tag at creation time, a future cleanup pass takes minutes instead of hours of archaeology trying to figure out whether something is safe to delete.

Built-in tools vs. paying for a cost platform — and when not to bother

For a single AWS account, or a handful of accounts you can keep in your head, everything covered in this article is free: Trusted Advisor's cost optimization checks, Cost Explorer, CloudWatch metrics, and Public IP Insights inside VPC IP Address Manager, which lets you monitor, analyze, and audit public IPv4 usage across regions and, once you set up an IPAM pool, across every account in an AWS Organization at once. That combination genuinely covers everything this article walks through, at no additional cost beyond what you're already paying for the resources themselves.

Third-party FinOps platforms earn their subscription fee once you're managing dozens of accounts across an organization, need cross-cloud visibility AWS's own tools don't provide, or want automated remediation workflows and approval chains that go beyond a scheduled Lambda function. If that's not where you are yet, don't add a subscription on top of a $30-a-month problem — the built-in tools will find the same waste, and the only thing you'll spend is the time to actually look.

Putting a number on a typical account's standing waste

Jake's shop, once he actually went looking, had three unattached Elastic IPs left over from the POS pilot that never launched, and one idle Application Load Balancer sitting in front of a staging environment that had been replaced by a different tool eight months earlier. Three EIPs at roughly $3.60 a month each, plus an ALB at roughly $16.40 a month base with a trickle of health-check LCU usage on top, came to a little over $27 a month — nothing that would show up on a monthly glance at the total bill, but $325 or so over a year, for infrastructure nobody was using and nobody remembered creating.

"That's the number that gets people," Ethan said. "Not the monthly figure — the annual one, once you actually add it up across every region and every forgotten project. It's never one big scary charge. It's fifteen small ones nobody ever looked at together."

Frequently asked questions

Does an Elastic IP cost anything while it's attached to a running EC2 instance?

Yes, since February 1, 2024. Before that date, one EIP attached to one running instance was free. Now every public IPv4 address bills $0.005 an hour regardless of whether it's attached and in use or sitting idle.

How much does one unattached Elastic IP actually cost per month?

Around $3.60 a month at $0.005 an hour, or about $43.80 a year, if it sits unattached for the entire period.

Why is my bill showing charges for public IPv4 addresses when I'm on the AWS Free Tier?

The EC2 free tier includes 750 hours a month of public IPv4 usage for the first 12 months, but that only covers an EC2 instance's own public IP. It does not cover a NAT Gateway's IP, a load balancer's IP, or a second Elastic IP on the same instance — those are billed from the first hour regardless of free tier status.

Does Bring Your Own IP (BYOIP) avoid this charge?

Yes. Addresses you bring into AWS yourself through BYOIP are exempt from the public IPv4 hourly charge, since AWS isn't allocating them from its own address pool. You can confirm which addresses in your account are BYOIP with the describe-public-ipv4-pools CLI command.

How many Elastic IP addresses can I have in one region?

A new AWS account typically has a default quota of five Elastic IP addresses per region. If you can't allocate a new one, check the console or run aws ec2 describe-addresses first — you may already be holding unattached ones that are eating your quota, not just your bill.

Where do I see exactly what an unattached Elastic IP is costing me?

Open Cost Explorer, filter Service to Amazon Virtual Private Cloud, group by Usage Type, and look for the PublicIPv4:IdleAddress line. Set granularity to daily to see whether the charge is steady, which usually means a genuinely forgotten address.

Will Trusted Advisor catch every unattached Elastic IP for me automatically?

Yes, if your support plan includes the cost optimization checks. The Unassociated Elastic IP Addresses check specifically flags any allocated EIP not associated with a running EC2 instance, across your account.

Why won't an Elastic IP release even though nothing seems to be using it?

The most common cause is a reverse DNS (rDNS) record still configured on the address; AWS locks release until that's removed. If there's no rDNS record and it's still stuck, open a support case under "Account and billing," which is available even without a paid support plan since it concerns a charge on your account.

Does Trusted Advisor catch idle Application or Network Load Balancers?

No. As documented by AWS, the Idle Load Balancers check currently only evaluates Classic Load Balancers within the Elastic Load Balancing service and explicitly does not include Application Load Balancers or Network Load Balancers.

How do I find an idle Application Load Balancer myself, then?

Check its target group for zero registered or all-unhealthy targets in the EC2 console, and check its CloudWatch RequestCount metric over the last seven days using the Sum statistic. If there's no data reported for the period, no requests were flowing.

Why does a CloudWatch chart for an idle load balancer show no data instead of a flat zero line?

Elastic Load Balancing only publishes metrics to CloudWatch when requests are actually flowing through the load balancer. If there's no traffic, there's no data point for that period, rather than a reported value of zero.

How much does an idle Application Load Balancer cost per month?

Roughly $16.40 a month from the base hourly charge of $0.0225 per hour alone, before any Load Balancer Capacity Unit usage is added. Health checks against a target group typically add a small amount of LCU usage even with no real traffic.

What's a Load Balancer Capacity Unit (LCU) and why does it matter for cost?

An LCU measures the highest of four dimensions an Application Load Balancer processes in a given hour: new connections per second, active connections per minute, gigabytes of data processed, and rule evaluations. You're billed for whichever dimension was busiest that hour, not the sum of all four.

Is it safe to just delete a load balancer that has zero registered targets?

Usually, but check DNS first. Search Route 53 and any external DNS for records that alias or point to the load balancer's DNS name before deleting it, since a broken alias typically surfaces as intermittent resolution failures rather than an obvious error.

Does disabling AWS Global Accelerator stop the static IP charges?

No. Disabling an accelerator stops its data-transfer charges but leaves the accelerator object, its fixed hourly fee, and both of its static IPv4 addresses in place — each address still billed under the same public IPv4 charge. The only way to fully stop the charges is to delete the accelerator.

Can I automate cleanup so unattached IPs and idle load balancers don't build back up?

Yes. AWS has published a reference pattern using an AWS Lambda function that scans every region for unassociated Elastic IPs, logs them to an S3 bucket, and can optionally release them on a schedule. Tagging resources with an owner at creation time also makes manual cleanup passes much faster even without automation.

Also Read:

AWS costs: The NAT gateway bill - the $32/month nobody planned

 AWS costs: Data transfer pricing - the map of what is free and what is not

 AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

 AWS costs: Cross-AZ traffic - the invisible cent per gigabyte

 AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list

AWS costs: S3 request pricing - when storage is cheap but touching it is not

AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering

AWS costs: Glacier retrieval - the bill for wanting your data back

Revision note. Written September 2026, covering the public IPv4 pricing model in effect since February 1, 2024, and current Elastic Load Balancing and Global Accelerator pricing. This will be revisited if AWS changes the per-hour rates or extends Trusted Advisor's Idle Load Balancers check to cover ALBs and NLBs. If you've just found a few hundred dollars of forgotten IPs, load balancers, or accelerators on your own bill, you're not the only one — almost every account carries some of this, and finding it is most of the way to fixing it.