The Amazon Web Services (AWS) cloud platform provides a managed load balancing service called Amazon Elastic Load Balancing (ELB). This service enables customers to provision and configure a load balancer with built-in security and monitoring.
There are several types of load balancers, one of which is the Application Load Balancer (ALB). The ALB resource receives inbound HTTP requests and routes them to a target service. Request routing is handled by creating user-defined rules, which include criteria based on:
While it's easy to provision ALBs, it's also easy for cloud resource costs to add up quickly. You'll want to ensure that your ALBs are actively being used, and are not simply provisioned and sitting idle. Even if an ALB is idle, you'll still incur costs for the resource while it's provisioned in your AWS account.
In order to identify idle ALBs in your AWS environment, you can use our SaaS tool called Stratusphere. Stratusphere can automatically discover idle ALBs across different AWS regions, accounts, and even across multiple AWS Organization structures. Without Stratusphere, identifying idle ALBs is still possible, but requires a significant amount of extra effort.
Like many other AWS managed services, the AWS ALB resource emits performance metrics into the Amazon CloudWatch metrics storage service. There are quite a few different metrics we can use to evaluate the status of an ALB, to see if it's actively being utilized. Let's explore a few of the built-in metrics below.
The Request Count is one of the more helpful metrics on the ALB resource. As shown in the example graph below, the request count hit up to around 17k on a per-minute period, and then dropped off sharply to around 450 requests per minute. The Request Count metric should be zero, over an extended period of time, if the ALB is truly idle.
Another helpful metric to evaluate whether or not an AWS ALB is active is the ProcessedBytes metric. In the example graph below, you can see that the ALB is processing about 450 KB of data per-minute.
In addition to ProcessedBytes, the Active Connection Count metric can show how many active connections there are, on a per-minute basis. If there are more than 0 active connections, for any period of time, then some client is accessing a service behind the ALB.
If there's a very small amount of requests, with large gaps, going through your ALB, you may need to identify which application is accessing the ALB. You can create an Amazon S3 object storage bucket and point your ALB's configuration to that S3 bucket. Simply right-click your ALB in the AWS Management Console and select the Edit Load Balancer Attributes option, to access the logging options under the Monitoring heading.
ALBs have two different types of logging available: access (request) logs, and connection logs. You can store both types of logs in the same S3 bucket. You'll need to configure your S3 bucket to allow the ELB service to write logs there, using this document.
⚠️ Take special note of the S3 bucket policy that needs to be applied in the documentation.
After configuring the logging bucket for an ALB, you will eventually see the logs written into the Amazon S3 bucket. You'll have to drill through several layers of S3 key prefixes in order to see the files themselves, like in the screenshot below. Each of the log files has GZIP compression applied to it, so you'll need to decompress these files using something like 7-Zip before you can read the raw log text.
Here's an example of the raw text you can see in one of the access logs.
http 2025-01-15T22:17:05.156864Z app/trevor01-alb/1c70e9ce48ba7a0a 5.170.192.240:48426 [2600:1f14:2a02:ff0:1a5e:522:8796:8f10]:80 0.000 0.000 0.000 404 404 95 308 "GET http://51.17.38.132:80/cgi-bin/luci/;stok=/locale?form=country&operation=read HTTP/1.1" "-" - - arn:aws:elasticloadbalancing:us-west-2:973081273628:targetgroup/trevor01-alb-target/df80c13ebc157078 "Root=1-678833e1-500d9b7a72660dce6e359a53" "-" "-" 0 2025-01-15T22:17:05.155000Z "forward" "-" "-" "[2600:1f14:2a02:ff0:1a5e:522:8796:8f10]:80" "404" "-" "-" TID_db771e360bf81c48be0b3119f642076d
By looking at the source IP address of an incoming request, you can help narrow down which workload is accessing the ALB.
Before you remediate an idle ALB in your AWS environment, you should consider the following potential risks.
You can remediate idle Application Load Balancers by deleting them from your AWS account. You'll need to identify which AWS account ID and AWS region the ALB belongs to. This information is available as part of the Amazon Resource Name (ARN) of the ALB resource.
Once you've used Stratusphere to identify the idle Load Balancers in your AWS account, you can delete them with the AWS Management Console. To delete an ALB from your AWS account, using the AWS Management Console, follow these steps.
You can also delete AWS ALBs using the AWS CLI automation tool.
NOTE: There are two different versions of the AWS ELB service. ALBs are managed using the "elbv2" service context, in the AWS CLI tool.
To list the ALBs in the current region, run this CLI command.
aws elbv2 describe-load-balancers
After listing the ALBs, you can copy the Amazon Resource Name (ARN) of a specific ALB that you want to delete, by selecting the text and using CTRL + C (Windows) or CMD + C (MacOS).
To delete an ALB with the specified name, in the current AWS region, use this command. Simply paste in the ARN of the ALB that you copied.
aws elbv2 delete-load-balancer --load-balancer-arn <paste>
Even though you launch CloudShell in a specific AWS region, you can also override the region where you want to delete an ALB. This avoids you having to launch CloudShell in a different region, as an additional step.
Simply add the --region parameter to one of your AWS CLI commands, to list the ALBs, or delete a specific ALB, in that region.
aws elbv2 describe-load-balancers --region eu-central-1
There are many other AWS CLI commands under the "elbv2" context. Feel free to explore these on your own.
You can use the official AWS PowerShell module to find and remove AWS ALBs from your accounts. Just like with the AWS CLI, you can use the AWS PowerShell modules from the pre-configured AWS CloudShell environment, within the AWS Management Console.
pwsh command, from the Bash shellTo list AWS ALBs, in the current AWS region, with the AWS PowerShell module, use the Get-ELB2LoadBalancer command. No additional parameters are required.
Get-ELB2LoadBalancer
To get ALBs from a different region, just add on the standard -Region parameter, which works on all AWS PowerShell commands.
Get-ELB2LoadBalancer -Region eu-central-1
If you'd like to delete all of the AWS ALBs in a particular region, you can use this command. Be warned that this is destructive and doesn't discriminate about which ALBs to remove. You can add the -WhatIf parameter at the end, to test the command before actually executing it.
Get-ELB2LoadBalancer | Where-Object Type -eq Application | Remove-ELB2LoadBalancer -Force
To filter out ALBs that don't meet certain criteria, you can add more filtration criteria to PowerShell's built-in Where-Object command. For example, if you only wanted to delete ALBs with a Name property that contains the text "stratusgrid" you could use this command.
Get-ELB2LoadBalancer |
Where-Object {
'Type' -eq 'Application' -and
'Name' -like '*stratusgrid*'
} |
Remove-ELB2LoadBalancer -Force
Feel free to explore the other Amazon ELB-related commands in the AWS PowerShell module. Just use this command to find all the PowerShell commands for managing the ELB service.
Get-Command -Module AWS.Tools.ElasticLoadBalancingV2
As you can see, it's easy to use Stratusphere to identify ALBs that are idle, and aren't providing you any business value. Removing these unused ALBs can reduce your cloud operational expenses and improve your business margins! StratusGrid engineers can also perform a much more in-depth analysis of your cloud costs, and then build and execute on an approved recommendations report. This frees up your internal engineering teams to continue focusing on building new innovations, while we run internal cost optimizations efforts! If you're interested in this engagement, please check out our success-based cost optimization offering!