What triggers this finding
A load balancer older than 14 days with zero healthy targets, or older than 30 days with near-zero traffic (fewer than 100 requests for ALB/CLB, or under 1 MB processed for NLB).
Typical fix
Delete the load balancer if it is no longer routing production traffic. Confirm DNS and target groups are updated first.
Example savings
Hourly base charge — roughly $16–$22/month for ALB/NLB (LCU and data-processing charges may add more).
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
An hourly floor that traffic cannot lower
Elastic Load Balancing bills two components: a fixed hourly charge for the load balancer's existence, and a usage charge — LCU-hours on ALB and NLB, per-GB on the Classic balancer. Only the second responds to traffic. The first accrues identically whether the balancer serves ten million requests a day or none at all.
Parsivex prices the fixed component from the us-east-1 reference rates over 730 hours: $16.43 a month for an Application or Network Load Balancer at $0.0225 per hour, and $18.25 for a Classic Load Balancer at $0.025. Gateway Load Balancers are not priced and are skipped entirely.
The finding notes that LCU and data-processing charges are excluded, so actual savings may be higher — and it is worth understanding when that applies. For a balancer that is genuinely idle, LCU consumption is close to zero and the hourly charge is essentially the whole bill, so the estimate is accurate. It understates in the other case this detector catches: a balancer with no healthy targets but live inbound traffic is still consuming LCUs to generate its 503 responses, and removing it saves more than the base rate.
Two independent triggers with different age floors
The finding fires on either of two conditions, and they are not variations on one idea.
No healthy targets, once the balancer is at least 14 days old. This is a structural signal read from target health rather than from CloudWatch, which means it still applies when metric collection fails.
Near-zero traffic, once the balancer is at least 30 days old, measured over the last 30 days. The threshold depends on type: fewer than 100 requests for an Application or Classic balancer, or under 1 MB of processed bytes for a Network Load Balancer, which publishes no request count. If CloudWatch could not return metrics, this test is skipped rather than treated as zero.
Confirm each separately. Target health first:
aws elbv2 describe-target-health --target-group-arn <target-group-arn> \
--query 'TargetHealthDescriptions[].[Target.Id,TargetHealth.State,TargetHealth.Reason]' \
--output table
Then traffic, using the namespace and metric that matches the type — AWS/ApplicationELB with RequestCount, AWS/NetworkELB with ProcessedBytes, or AWS/ELB with RequestCount for Classic:
aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
--metric-name RequestCount \
--dimensions Name=LoadBalancer,Value=app/my-lb/0123456789abcdef \
--start-time 2026-07-13T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Sum
Zero healthy targets is sometimes an outage
This is the most important caveat on the page, and it is specific to the first trigger. A load balancer with no healthy targets is indistinguishable, from the outside, between infrastructure nobody cleaned up and a production service that is currently down. A health check misconfigured during a deploy, a security group that stopped allowing the check through, a target group whose instances all failed at once — every one of those produces exactly the signal this detector reports as waste. Read a no-healthy-targets finding as a question about whether the service is alive, and only then as a cost item.
Other legitimate cases span both triggers:
- Blue/green standbys. An idle balancer waiting for the next cutover, deliberately holding no targets between releases.
- Scale-to-zero environments. Development and preview stacks whose Auto Scaling groups drop to zero overnight and at weekends.
- PrivateLink service endpoints. An NLB backing a VPC endpoint service can show very low
ProcessedByteswhile consumers in other accounts depend on it. Deleting the balancer deletes the endpoint service and breaks them, and none of that is visible from this account's metrics. - Disaster-recovery and failover paths. Balancers in a standby region that carry traffic only during an incident.
- Certificate and redirect holders. Balancers kept for a TLS certificate or a domain redirect that fires rarely.
Deletion is the only way to stop the charge
There is no intermediate state. Removing listeners, draining targets, or scaling the target group to zero all stop traffic without touching the hourly charge — the balancer exists, so it bills. Deletion is the only action that changes the number, which is why there is no low-risk partial step to recommend here.
The consequence that catches people is the DNS name. An ALB or NLB's hostname is assigned at creation and never reissued; delete the balancer and that name is gone permanently. A replacement built five minutes later gets a different one, so every Route 53 alias, CNAME, hardcoded endpoint, mobile app configuration, and partner integration pointing at the old hostname needs updating. Unlike an Elastic IP, you cannot even attempt to reclaim the original.
Deleting an NLB that backs a VPC endpoint service breaks consumers in accounts you may not be able to see, and the failure surfaces on their side rather than yours. Check for an associated endpoint service before removing any internal NLB.
Target groups are the one piece that survives. They are separate resources, they are free, and deleting a balancer leaves them behind — so the target configuration is still there if you rebuild, and so a tidy-up should remove them separately rather than assuming they went with the balancer.