Clean up unused Elastic Load Balancers (ELB/ALB/NLB) so you are not paying for inactive infrastructure and to reduce configuration clutter. The plan identifies load balancers that have no registered target groups or targets, guides you through a review and approval step, deletes only what you explicitly approve, and then validates that the deletions were performed correctly with no unintended impact.
First, all relevant AWS accounts and regions are confirmed and documented as in scope for the cleanup. Within each in-scope region, every load balancer is inventoried, including:
For each load balancer, the plan gathers core attributes such as name, ARN, type (Classic/Application/Network), scheme (internet-facing or internal), VPC ID, subnets or Availability Zones, state, and DNS name. It also retrieves useful tags (for example, Name, environment, application, owner, cost-center) to support later human review.
For ALBs and NLBs, all listeners and their associated target groups are listed. For each target group, the plan captures details such as ARN, name, target type (instance/IP/Lambda), protocol and port, VPC ID, and health check configuration. It then collects the registered targets themselves (instance IDs, IPs, or Lambda ARNs) along with their health status.
For Classic Load Balancers, the set of registered EC2 instances and their states is retrieved.
Using this data, each load balancer is categorized as one of the following:
Load balancers in the first two categories are flagged as unused candidates for deletion, while those that have active targets are excluded. A structured candidate list is produced, including key metadata (type, DNS name, VPC, tags, associated target groups, and target counts), ready for user review in the next step.
The plan then presents you with the structured list of candidate unused load balancers, including their type, DNS name, VPC ID, key tags (environment, application, owner), associated target groups, and target counts.
You are guided to review each candidate and consider whether it is truly unused, including any dependencies not visible in AWS configuration (for example, planned future use, external DNS records, or references in external systems). For every candidate, you explicitly decide to either:
Any load balancer whose usage cannot be confidently determined is either kept out of the deletion set or flagged for follow-up outside the scope of this plan. By the end of this phase, each candidate is clearly labeled as “approved for deletion” or “retain,” and a final structured approval list is produced containing only those load balancers you have explicitly approved for deletion, along with any timing or maintenance window constraints.
Using the final approval list, the plan proceeds to delete only those load balancers you have approved.
Immediately before deletion, it rechecks each approved load balancer to confirm that:
If any load balancer now shows signs of active use or newly registered targets, it is removed from the deletion list, and the reason is documented.
For the remaining approved load balancers, deletion is initiated. If organizational practice requires it, directly associated resources (like listeners or specific Classic Load Balancer attributes) are adjusted or removed to allow deletion to succeed.
Each delete attempt is tracked, including success or failure, timestamps, and any AWS error messages. Load balancers that fail to delete are documented with the reason (for example, dependent resources, protection settings, or transient issues) and whether retries or separate remediation are recommended. A summary is generated that lists all successfully deleted load balancers, those that could not be deleted, and suggested next steps.
To verify the outcome, the plan retrieves the list of load balancers that were approved for deletion and recorded as successfully deleted. It then re-enumerates all load balancers in the in-scope regions to obtain the current inventory.
For each load balancer approved for deletion, the plan checks that it no longer appears in the current inventory. If any still exist, their current state and configuration are examined and the reason they remain is documented (for example, prior delete failure or new dependencies), along with recommendations for remediation.
The pre-deletion and current inventories are compared to ensure no load balancers outside the approved list were removed. Where feasible, a sample of deleted load balancers is checked for lingering AWS configuration references (such as alarms or parameters), recognizing that non-AWS systems are out of scope.
Finally, a validation report is produced that summarizes: