How Much Does an Idle Load Balancer Cost (and How Do You Find Yours)?

You are scanning your AWS bill line by line and you hit LoadBalancer-Hours — or, if you look closely, a charge for an Application Load Balancer you are fairly sure nothing points at anymore. The app it fronted was decommissioned months ago. The target group behind it has no healthy instances. And yet, every hour, it quietly adds to the bill. A load balancer is one of the easiest things in AWS to leave running by accident, because unlike an EC2 instance you can't "stop" it — it either exists and bills, or it's deleted. This post explains exactly what an idle load balancer costs, how to prove one is unused, and how to remove it without taking down something that still matters.

Why am I still paying for a load balancer nothing is using?

A load balancer bills an hourly charge just for existing, completely independent of traffic. For an Application Load Balancer (ALB) that's roughly $0.0225 per hour in most US regions — about $22 per month, or ~$200 a year, whether it serves a million requests or zero. A Network Load Balancer (NLB) is in the same ballpark; a legacy Classic Load Balancer (CLB) is slightly more at ~$0.025/hour.

That flat fee is the part that surprises people. There is no "idle discount" and no way to pause it. The meter runs on provisioned time, not usage — the same trap as an idle NAT Gateway or a cache node nobody queries. On top of the hourly fee, an ALB also charges for LCUs (Load Balancer Capacity Units) based on real traffic, but that's exactly the part an idle balancer isn't generating. When a balancer is unused, you're paying almost entirely for the base hourly charge — money for a piece of plumbing that routes nothing.

One idle balancer is ~$22/month — annoying, not alarming. But they breed. Every torn-down staging environment, every blue/green deploy that left the old balancer behind, every preview environment spun up per pull request and never cleaned up, adds one more. A dozen forgotten balancers across a few regions and accounts is a few thousand dollars a year for routing that goes nowhere — and no single line item looks big enough to investigate.

What counts as "idle" for a load balancer?

"Idle" here is behavioural, and there are two distinct flavours — either one is enough to call a balancer waste.

The first and clearest signal is no healthy targets. If every target group attached to the balancer has zero healthy hosts, there is literally nothing behind it to route to. Any request that arrives gets a 503. A balancer in this state is almost always the leftover of something that was deleted out from under it.

The second is near-zero traffic over a sustained window. The balancer might have a target or two registered, but if it has processed essentially no requests for two weeks, nothing in production is actually using it. For an ALB the metric to watch is RequestCount; for an NLB it's ActiveFlowCount and ProcessedBytes. A flat line near zero across 14 days is your confirmation.

Two weeks matters, for the same reason it matters with idle EC2: a balancer fronting a service that only gets hit by a weekly batch job will look dead on a Tuesday. A 14-day window captures weekly cycles so you don't delete something that's rarely-but-genuinely used.

How do I find idle load balancers in my account?

Before deleting anything, confirm which balancers are unused. Start by listing them all so you know the scope:

# List every ALB/NLB with its type, scheme, and ARN
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[].[LoadBalancerName,Type,Scheme,LoadBalancerArn]' \
  --output table \
  --region us-east-1

For each balancer, check whether anything healthy sits behind it. Walk its target groups and count healthy targets — a balancer where every group returns zero healthy hosts is a prime candidate:

# For one balancer ARN: list its target groups, then check target health
aws elbv2 describe-target-groups \
  --load-balancer-arn <lb-arn> \
  --query 'TargetGroups[].TargetGroupArn' --output text --region us-east-1 \
| tr '\t' '\n' | while read -r tg; do
    healthy=$(aws elbv2 describe-target-health --target-group-arn "$tg" \
      --query "length(TargetHealthDescriptions[?TargetHealth.State=='healthy'])" \
      --output text --region us-east-1)
    echo "$tg  healthy_targets=$healthy"
  done

Then confirm the traffic story with CloudWatch. Pull RequestCount for an ALB over the last 14 days — a Sum at or near zero means nothing is routing through it:

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/my-alb/0123456789abcdef \
  --start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 \
  --statistics Sum \
  --region us-east-1 \
  --output table

For an NLB, use the AWS/NetworkELB namespace and ActiveFlowCount / ProcessedBytes instead. A balancer with no healthy targets and a flat-zero request count for two weeks is idle with high confidence.

How do I safely delete an idle load balancer?

Once you've confirmed a balancer is unused, deleting it is a single command — but a balancer is a network entry point, so check what points at it first.

With those checks done, delete it and clean up the orphaned target groups it leaves behind (target groups are free, but leaving them around just recreates the "what is this for?" confusion later):

# Disable deletion protection if it's on
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <lb-arn> \
  --attributes Key=deletion_protection.enabled,Value=false \
  --region us-east-1

# Delete the load balancer
aws elbv2 delete-load-balancer --load-balancer-arn <lb-arn> --region us-east-1

# Then delete each now-orphaned target group
aws elbv2 delete-target-group --target-group-arn <tg-arn> --region us-east-1

If you'd rather do it by hand the first time, the Console path is EC2 → Load Balancers → select → Actions → Delete. Either way, the hourly charge stops the moment the balancer is gone.

What else should I check while I'm in here?

An idle load balancer is rarely alone. If a balancer has no healthy targets, ask what happened to the targets — often the EC2 instances behind it were stopped but never terminated, so you're now paying for both the dead balancer and the idle boxes it used to route to (plus their EBS volumes). The load balancer is the visible symptom; the instances are frequently the bigger bill.

So while you have the account open, it's worth doing the same pass on compute — see how to find idle EC2 instances (and what they really cost) for how to separate genuinely idle instances from ones that are merely quiet. Cleaning up the balancer and the compute behind it together is how you actually reclaim the whole cost of a decommissioned service, instead of half of it.

There is usually a third piece. A balancer that fronted a public service held a public IPv4 address, and since 2024 AWS bills every one of those — so the teardown that leaves a dead ALB behind tends to leave an Elastic IP billing for nothing as well. It is a smaller number than the balancer, but it comes from the same abandoned stack, and you may as well take all three in one pass.

How do I find every idle load balancer across my account?

Checking one balancer by hand is quick. Doing it for every ALB, NLB, and Classic ELB, in every region, cross-referencing target health against 14 days of traffic to tell "dead" from "rarely used" — that's the tedious part, and it's exactly where these ~$22/month charges hide. It is also one line on a longer list; if you are working through the bill end to end, our guide to trimming an AWS bill in the right order covers which of these checks pay back first. That's what a scan is for. Parsivex checks each region, flags load balancers with no healthy targets or near-zero traffic, and separates them from the ones doing real but quiet work — then keeps watching, so a torn-down environment doesn't leave another idle balancer billing away next quarter.

For what this finding means once it shows up in your report, see Idle load balancer, or read how scans work before you connect an account.