Delete idle load balancers

An Elastic Load Balancer bills a flat hourly rate (roughly $16-18 per month per load balancer) from the moment it is created until it is deleted, regardless of whether any traffic flows through it or any application sits behind it. There is no pause option, no idle-rate tier, and no automatic expiry. AWS Trusted Advisor and Cost Optimization Hub surface load balancers with no healthy targets and near-zero traffic as a NET-003 wastage finding precisely because the cost is unconditional and the fix is clean.

An idle LB is defined by two signals: zero healthy registered targets (the target groups are empty or all instances behind them are unhealthy) and CloudWatch metrics (ProcessedBytes, RequestCount, ActiveConnectionCount) flat at zero for seven or more days. Seven days is the threshold scanners use because it filters out LBs that are legitimately quiet without generating false positives on low-volume internal tools.

The finance framing is straightforward: each idle LB is pure cost with no corresponding workload. The per-unit saving looks modest ($16/mo) but idle LBs accumulate silently across accounts and regions over months and years, compounding into the thousands of dollars annually for nothing. The remediation is either delete-and-save or document-why-kept, both of which are cleaner than continued silent spend.

Priya is the FinOps lead for a mid-sized SaaS company. The monthly wastage report flags 10 load balancers as NET-003 idle across four AWS accounts and three regions: a combined annual run-rate of just under $2,200 in hourly fees with no traffic to justify any of them.

Rather than treating this as a blanket delete, Priya runs the tiering check first. She asks engineering: does any of these have a legitimate reason to exist without traffic, such as a DR standby, a warm-path for a seasonal spike, or a pending cut-over? The team identifies one NLB that's being kept for a planned migration in six weeks; the other nine are genuinely orphaned. Priya notes the NLB as an intentional exception with a scheduled review date and approves the nine deletions.

Her finance pack entry is a single line: 'Nine idle load balancers deleted, saving $1,980/year. One retained with recorded justification and 6-week review.' The annual saving is modest on its own, but it's also the signal that the org doesn't have a lifecycle process, and Priya adds 'require lifecycle tag at LB creation' to the next governance sprint.

Idle load balancers are one of the cleanest categories of cloud waste from a financial modelling perspective: the cost is unconditional, the benefit is zero, and there is no risk-reward trade-off to weigh. Each idle ALB or NLB costs roughly $16-18 per month purely in the hourly base charge, with the traffic-based LCU component rounding to near zero. That makes the financial impact completely forecastable: there is no usage variable to estimate.

The compounding dynamic is what makes this worth escalating. Idle LBs don't generate a spike on the bill; they add a small increment each month and are never the largest line item. That makes them easy to miss in any given review cycle, which is precisely how a handful becomes a few dozen over a multi-year account lifetime. A mid-sized multi-account estate that has never run a systematic cleanup commonly carries $5k-$15k/year in idle LB spend, entirely invisible in monthly commentary because no single account shows a dramatic number.

There is one category that requires a cost-versus-risk conversation rather than a clean delete: a load balancer kept as a warm standby for disaster recovery or a deliberate pre-provisioned path for a known traffic event. These are legitimate, but they need to be recorded as intentional with a named owner and a review date; otherwise they are indistinguishable from forgotten infrastructure and should be treated as such until proven otherwise.

The governance multiplier is tag hygiene. An idle LB with no owner tag is both a cost leak and an accountability gap: there is no one to ask whether it is intentional and no one who will receive the alert when it shows up on the wastage report. Closing the idle-LB finding is an opportunity to enforce that every surviving LB has an owner, a team, and a lifecycle field, making future wastage reviews faster and the cost attribution cleaner.

A load balancer is a network entry-point for an application. AWS charges for it by the hour whether traffic is flowing or not. An idle load balancer is one that has been sitting in the environment with nothing behind it and no traffic reaching it: typically the leftover from a deployment, migration, or project that concluded without someone cleaning up the AWS resources.

The finding is a governance signal as much as a cost one. Idle load balancers accumulate when creation is easy but deletion is no one's explicit responsibility. The right response is a policy, not just a cleanup: resources should be created with a named owner and a clear lifecycle, and wastage reviews should surface what has been forgotten. The cost is recoverable; the pattern is worth fixing by design.

At one company, the infrastructure lead used to find idle load balancers in batches every six months: always a few dozen, always from projects or migrations that wrapped up without explicit cleanup. The quarterly cost review would flag them, someone would spend a few hours deleting them, and the cycle would repeat.

The change that broke the cycle wasn't a policy memo; it was making deletion a tracked step in the project close-out checklist. Every new load balancer now requires an owner tag and a lifecycle field at creation. When a project closes, the checklist includes 'confirm LB deleted or handoff documented.' The idle-LB finding dropped to near zero not because engineers are more diligent, but because the system no longer relies on diligence: it routes the question to the right person at the right time.

That's the executive frame: the idle LB is rarely malicious or negligent. It's a process gap. Fix the process and the cost takes care of itself.

The dollar figure on idle load balancers is rarely the headline number in a cloud budget review. What it signals is more important: resources are being created without a clear lifecycle, and no one is accountable for retiring them when the work they supported ends. That pattern repeats across every resource category and compounds over time.

The secondary impact worth noting is security posture. An orphaned load balancer is one no one is maintaining: listener TLS configurations age, security groups stay as permissive as they were on day one, and access logs accumulate with no review. The risk is low while nothing is attached to it, but the day a developer re-registers a target group into that forgotten LB, the attack surface has expanded with no one aware it happened.

The leadership question for this finding is not "how much did we save this month?" It's "do our creation and deletion processes work symmetrically?" Easy to create and hard to clean up is a structural problem. The idle-LB count is a lagging indicator of whether that asymmetry has been corrected.