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 more than the configured lookback period ago (default 90 days, adjustable from 7–90 days).
• The total number of bytes processed by the load balancer is zero for the last 90 days.

Classic ELBs

• The ELB was created more than the configured lookback period ago (default 90 days, adjustable from 7–90 days).
• The RequestCount metric for the load balancer is zero for 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. If the load balancer is a Network Load Balancer and it is the only NLB behind a VPC endpoint service configuration, the Fixer calls the DeleteVpcEndpointServiceConfigurations API to remove that endpoint service. If the endpoint service is shared with other load balancers, it is left in place.
2. The Fixer calls the DeleteListener API for each listener configured on the load balancer, passing the listener’s ARN as the ListenerArn parameter.
3. Next, the Fixer calls the DeleteTargetGroup API for each target group attached to the load balancer, passing the targetGroupId as the TargetGroupArn parameter. Target groups that are also attached to other load balancers are skipped and left in place.
4. 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.
5. Finally, the Fixer calls the DeleteLoadBalancer API to delete the ELB, passing its resourceId as the LoadBalancerArn.

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:

• CloudFix Knowledge Base
• AWS Documentation