Detect and remove orphaned load balancers by inventorying every load balancer across regions and accounts, checking each for registered healthy targets, and confirming it handles no real traffic. A load balancer with zero healthy targets and no request traffic over a trailing window is an orphan. Before deleting, verify nothing in DNS or application config still references it, then tag, notify the owner, and quarantine it for a grace period to be safe. Individually small, orphaned load balancers accumulate across a large estate into meaningful recurring zombie spend, and the fix is a low-risk deletion.
Last updated: June 2026
An orphaned load balancer is a load balancer that still exists and bills but no longer serves any purpose, because it has no healthy registered targets, receives no traffic, and nothing points to it. They are left behind when the instances or containers they fronted are torn down but the load balancer itself is not, so it keeps charging its hourly rate to route traffic to an empty backend. This is the Cut step of FinOps applied to zombie spend: clear idle and orphaned resources, the cost that buys nothing, before you ever commit to a reservation.
This article is part of our rightsizing and waste elimination cluster. For the full picture start with the complete guide to cloud rightsizing and waste elimination, the pillar this piece links up to. Orphaned load balancers are one species of idle resource; another is covered in how to build an automated resource scheduler for non-prod.
What is an orphaned load balancer?
An orphaned load balancer is one that bills but does nothing useful: it has no healthy registered targets, sees no traffic, and is referenced by nothing. They appear when an application is decommissioned or rebuilt and the compute behind the load balancer is deleted while the load balancer is overlooked. Each one continues to charge an hourly rate plus capacity-unit or usage fees, as set out in the Elastic Load Balancing pricing page, for routing requests that never come. The Azure Load Balancer and Google Cloud load balancing equivalents bill the same way.
How do I find load balancers with no healthy targets?
List every load balancer across all regions and accounts, then check each one's target groups or backend pools for registered, healthy targets and cross-check its traffic metrics. A load balancer with zero healthy targets and no request traffic over a trailing window is an orphan candidate. AWS Trusted Advisor and the Cost Optimization Hub flag idle load balancers automatically, and the same logic, target health plus CloudWatch request-count metrics, can be scripted across accounts. The key is to check both health and traffic, because a load balancer can briefly have no healthy targets during a deploy without being an orphan.
How do I detect and remove orphaned load balancers, step by step?
Follow these six steps to find orphaned load balancers and remove them without breaking anything.
- Inventory all load balancers. List every load balancer across regions and accounts, including application, network, and classic types on AWS and the Azure and Google Cloud equivalents, so nothing is missed.
- Check target and backend health. For each load balancer, check whether its target groups or backend pools have any registered, healthy targets. Zero healthy targets is the first signal of an orphan.
- Check traffic metrics. Look at request-count and processed-bytes metrics over a trailing window to confirm the load balancer is handling no real traffic, not just briefly between deploys.
- Confirm no DNS or dependency points to it. Verify no DNS record, application config, or other resource still references the load balancer before you act, so you do not remove something dormant but needed.
- Tag, notify, and quarantine. Tag the candidate, notify the owning team, and remove it from rotation for a grace period rather than deleting immediately. Quarantine catches the rare false positive safely.
- Delete and prevent recurrence. Delete confirmed orphans, then add a recurring check so new orphaned load balancers are caught automatically instead of accumulating until the next audit.
Paying every hour to route traffic to nothing?
Our cost audit inventories every load balancer across your accounts, identifies the orphans by health and traffic, removes them safely, and adds the recurring check that keeps them from coming back. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Are idle load balancers expensive enough to bother with?
A single load balancer is a modest line item, but they accumulate, and across many regions and accounts the total is real. Each one bills an hourly rate plus usage or capacity-unit charges every hour of every month for zero value, and a large estate routinely hides dozens of them. Because the fix is a safe deletion rather than a re-architecture, the return relative to effort is high, which is why orphaned load balancers sit alongside unattached storage and idle databases on the standard waste checklist. Finding them once and adding a recurring check stops them from rebuilding silently.
How do I safely remove an orphaned load balancer?
Confirm it has no healthy targets and no traffic, verify nothing in DNS or application config still references it, then tag it, notify the owning team, and quarantine it for a grace period before deletion. The quarantine step is what makes removal safe: a load balancer that is dormant but still needed will be noticed during the grace period before anything is lost. After deletion, add a recurring orphan check so they are caught automatically. The same detect, quarantine, delete, and prevent pattern applies to idle databases, covered in how to find idle managed databases across AWS, Azure, and GCP.
The Cloud Waste Audit Framework includes the orphaned-resource detection queries and the quarantine-before-delete runbook. It is the downloadable companion to this article.
Frequently asked questions
What is an orphaned load balancer?
An orphaned load balancer is a load balancer that still exists and bills but no longer serves a purpose, because it has no healthy registered targets, receives no traffic, and nothing points to it. They are commonly left behind when the instances or containers behind them are deleted but the load balancer itself is not. Each one keeps charging an hourly rate plus capacity-unit fees for doing nothing.
How do I find load balancers with no targets?
List every load balancer across all regions and accounts, then check each one's target groups or backend pools for registered, healthy targets, and cross-check its traffic metrics. A load balancer with zero healthy targets and no request traffic over a trailing window is an orphan candidate. AWS Trusted Advisor and Cost Optimization Hub flag idle load balancers, and the same checks can be scripted with the provider APIs.
Are idle load balancers expensive?
Individually a load balancer is a modest line item, billed at an hourly rate plus usage or capacity-unit charges, but they accumulate. Across many regions and accounts, dozens of orphaned load balancers each running every hour add up to a meaningful recurring cost for zero value. Because the fix is a safe deletion, the return on finding them is high relative to the effort.
How do I safely remove an orphaned load balancer?
Confirm it has no healthy targets and no traffic, verify nothing in DNS or application config still references it, then tag it, notify the owning team, and quarantine it for a grace period before deleting. The quarantine step catches the rare case where a load balancer is dormant but still needed. After deletion, add a recurring check so orphans are caught automatically rather than rediscovered in the next audit.
The short version
Detect and remove orphaned load balancers by inventorying them all, checking each for healthy targets and real traffic, confirming nothing references it, then quarantining before deleting and adding a recurring check. They are low-risk zombie spend that accumulates across a large estate. When you want every orphan found and removed and the recurring check in place, that is exactly what our rightsizing and waste elimination service delivers.
Written by Morten Andersen and reviewed by Fredrik Filipsson, applying the See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.