## TL;DR

The agent flagged the load balancers as orphaned and tried to delete them, but their target groups are still referenced, so the delete fails with ResourceInUse. Delete in dependency order: deregister targets, delete listeners and rules, delete the target groups, then delete the load balancer. The error is the dependency graph asserting itself; honor the order.

## Error

```text
agent flagged orphaned load balancers  -  "ResourceInUse" on the target groups blocked cleanup
```

## Steps

1. Confirm the block: the delete failed with ResourceInUse naming the target groups. Expected: the dependency is identified.
2. Verify the load balancer is truly orphaned (no production traffic, no active listeners serving real backends). Expected: the orphan flag is confirmed, not just assumed.
3. Delete the listeners and listener rules first. Expected: the load balancer has no listeners.
4. Delete the target groups, then delete the load balancer. Expected: each delete succeeds in order.
5. Verify no orphaned target groups or listeners remain. Expected: the full resource chain is gone.

## When to use

- Load-balancer cleanup fails with ResourceInUse on target groups.
- The agent flagged orphaned load balancers.
- Deleting network resources in dependency order.

## When not to use

- The load balancer serves live traffic (do not delete).
- Listeners are actively in use (a different dependency).
- The flag itself is wrong and the LB is needed.

## Tool compatibility

AWS Elastic Load Balancing (ALB/NLB; current 2026 releases). Applies to cleanup agents.

### Variant phrasings

### "target group in use" blocking lb deletion

Delete listeners first, then target groups, then the LB.

### orphaned alb won't delete

Walk the dependency chain in reverse.

### cleanup failed on lb dependencies

Order matters: listeners, target groups, load balancer.

## Why it happens

Load balancers are composite resources: listeners reference target groups, and target groups reference the LB. AWS refuses to delete a resource with live references, which is the ResourceInUse error. Cleanup agents that delete the top-level resource first hit the wall; deleting leaf-first follows the dependency graph and succeeds. The pre-check (confirm truly orphaned) matters because the same error protects live infrastructure.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DuLy9AfDPjLsUUjk0dOAqg