Trusted Advisor — Idle Load Balancers

TL;DR: Every AWS account older than a year has at least one idle load balancer — a team migrated a service, sunset a feature, or rebuilt a stack, and the old ALB stayed up "just in case," billing ~$16–25/month at zero traffic. It's the highest-confidence, lowest-risk Trusted Advisor finding: a list of load balancers that almost certainly do nothing. Verify with DNS + IaC + CloudWatch, wait a week, delete.

The numbers

• Idle = no registered targets OR <100 requests/week (intentionally conservative thresholds).
• Base hourly fee applies whether or not traffic flows: Classic ELB ~$18/mo, ALB ~$16/mo, NLB ~$16/mo per enabled AZ (multi-AZ multiplies), GWLB ~$9/mo — LCU/byte charges go to ~$0 when idle but the base keeps running.
• A typical unaudited account yields 10–30 idle LBs = $150–800/month recovered indefinitely, with zero user-facing impact.
• Field examples: 47 idle ALBs after a microservices consolidation = $750/mo (~$9K/yr), cleaned in ~4 hours; a mystery 3-AZ NLB with no targets = $48/mo deleted after DNS+IaC+CloudWatch came up clean.

Do this

1. Open Trusted Advisor → Cost Optimization → Idle Load Balancers and sort by savings descending (multi-AZ NLBs surface first).
2. Run the 3-source check per LB: DNS (Route 53 public and private zones for records pointing at its name), IaC (grep repos for ARN/name/DNS name), CloudWatch (RequestCount flat at zero for 30 days).
3. Soft-delete migration leftovers by disabling listeners first — clients hitting the old endpoint get immediate errors that surface forgotten dependencies as alarms, not silent failures.
4. Tag pending-delete=<date>, post a "deleting these Friday unless you object" list, wait 7 days, then delete the LB, its target groups, and LB-only security groups.
5. Refresh Trusted Advisor and watch the count and savings update; add "delete old infrastructure" to your migration runbook so it doesn't re-accumulate.

Gotchas

• NLB cost scales with AZs — a 3-AZ idle NLB costs ~3× a single-AZ one, so it saves more than a careless per-row glance suggests.
• Internal-scheme LBs won't resolve from your laptop — check private hosted zones and any service mesh/registry, not just public DNS.
• Recently created LBs look idle because they haven't taken traffic yet — check the created-date and give anything under ~14 days more time.
• "Decoy" LBs kept only for a DNS name hardcoded in clients will look idle — search for the DNS name before deleting.
• Classic ELBs may want upgrading to ALB, not just deleting — verify the fronted service is truly gone.

Skip this if

• The LB is a deliberately-idle DR standby or a real low-traffic internal tool below the 100-req/week threshold — tag it (ta-ignore=..., purpose=dr-standby) and skip in reviews (but confirm a DR LB actually has targets wired).
• It keeps re-flagging and nobody will own the delete decision — force a 15-minute meeting with the dollar figure; if nobody will decide, that is the decision. Next-easiest cleanup of the same shape: Trusted Advisor — Unassociated Elastic IPs; the architectural cousins are NAT Gateway Consolidation and VPC Endpoints. Parent: Trusted Advisor Cost Optimization.