Cleanup Idle Elastic Load Balancers

Opportunity Name:

Cleanup Idle Elastic Load Balancers

AWS Resource Type:

Elastic Load Balancer

Opportunity Summary:

Unused Elastic Load Balancers (ELBs) generate costs, even when they don’t receive any traffic. Since idle ELBs serve no useful purpose, they can be safely deleted to realize cost savings.

Opportunity Description

This FF finds Elastic Load Balancers that have been idle for at least 90 days and deletes them. 

Criteria for identifying the opportunity

This FF identifies idle Elastic Load Balancers (ELBs) that can safely be deleted by checking that the following conditions are true:

Application/Network/Gateway ELBs

  • The ELB was created > 30 days ago.
  • The ELB is in an “active” state.
  • The total number of bytes processed by the load balancer is zero for their entire lifecycle or the last 90 days.

Classic ELBs

  • The ELB was created > 30 days ago.
  • The total number of requests/connections received by the load balancer is zero for their entire lifecycle or the last 90 days.

Potential savings (range in % on annual basis)

An idle ELB costs approximately $200 per year. Removing the ELB eliminates this cost.

What happens when the Fixer is executed?

Steps for deleting Classic ELBs:

  1. The Fixer calls the DeregisterInstancesFromLoadBalancer API, passing the ELB’s resourceId as the LoadBalancerName parameter, and an array of instanceIds of the EC2 instances to be deregistered as the Instances parameter.
  2. Once the targets have been deregistered, the Fixer calls the DeleteLoadBalancer API, passing the ELB’s resourceId as the LoadBalancerName parameter.

Steps for deleting Application/Network/Gateway ELBs:

  1. The Fixer calls the DeregisterTargets API, passing the targetGroupId as the TargetGroupArn parameter, and an array of targetResourceIds as the Targets parameter.
  2. Next, the Fixer calls the DeleteTargetGroup API, passing the targetGroupId as the TargetGroupArn parameter.
  3. The Fixer then turns off delete protection by calling the ModifyLoadBalancerAttributes API, passing the ELB’s resourceId as the LoadBalancerARN, and setting the deletion_protection.enabled key to false.
  4. Finally, the Fixer calls the DeleteLoadBalancer API to delete the ELB, passing its resourceId as the LoadBalancerARN. Note that this also removes any configured Listeners

Is it possible to rollback once CloudFix implements the fixer?

There is no automated rollback - to rollback the fixer, the load balancer must be recreated manually.

Can CloudFix implement the fix automatically once I accept the recommendation?

Yes.

Does this fix require downtime?

No.

 

Additional Resources:

Comments

0 comments

Article is closed for comments.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request