You know that moment when you realize you’ve been paying for something you haven’t used for ages — like that gym membership that seemed like a great idea in January? Yeah, well, that can happen in the cloud too. Enter the Idle Load Balancer. It’s quietly running in the background, charging you hourly but not actually doing anything. Sure, the hourly cost seems small, but when you have a lot of these idle resources, those little amounts can snowball into significant wasted expenses. Addressing these seemingly small costs can lead to major savings across your cloud environment.

So, let me take you on a little adventure, where I ran an AWS Cost and Usage Report (CUR) query, uncovered these freeloaders, and learned how to clean them up — step by step, in a way that you can understand and maybe even enjoy! 😉

The Magic Query That Finds the Lazy Load Balancers

First off, what exactly is an idle load balancer? Imagine a traffic cop standing at an empty intersection, whistling in the wind. It’s not directing any traffic, but you’re still paying them by the hour. That’s what’s happening with idle load balancers — they’re supposed to distribute traffic between your servers, but they aren’t handling any.

By running a simple query using AWS CUR, you can pinpoint these lazy resources. The query checks load balancers that have been running for over 14 days but haven’t had any real activity — no traffic, just hourly charges.

Here’s the magic query (don’t worry, no need to memorize this):

SELECT bill_payer_account_id, line_item_usage_account_id, SPLIT_PART(line_item_resource_id, ':', 6) AS split_line_item_resource_id, product_region, pricing_unit, sum_line_item_usage_amount, CAST(cost_per_resource AS DECIMAL(16, 8)) AS sum_line_item_unblended_cost FROM ( SELECT line_item_resource_id, product_region, pricing_unit, line_item_usage_account_id, bill_payer_account_id, SUM(line_item_usage_amount) AS sum_line_item_usage_amount, SUM(SUM(line_item_unblended_cost)) OVER (PARTITION BY line_item_resource_id) AS cost_per_resource, SUM(SUM(line_item_usage_amount)) OVER (PARTITION BY line_item_resource_id, pricing_unit) AS usage_per_resource_and_pricing_unit, COUNT(pricing_unit) OVER (PARTITION BY line_item_resource_id) AS pricing_unit_per_resource FROM ${table_name} WHERE line_item_product_code = 'AWSELB' AND line_item_usage_start_date >= now() - INTERVAL '1' month AND line_item_line_item_type = 'Usage' GROUP BY line_item_resource_id, product_region, pricing_unit, line_item_usage_account_id, bill_payer_account_id ) WHERE usage_per_resource_and_pricing_unit > 336 AND pricing_unit_per_resource = 1 ORDER BY cost_per_resource DESC;

Now, you might be thinking, “Whoa, this looks complicated.” But don’t worry, the takeaway is simple: this query looks for load balancers that have been running without doing much for half the month or more. AWS Trusted Advisor might find idle Classic Load Balancers, but this query gives you the full picture — including the more modern Application and Network Load Balancers.

What Kind of Load Balancers Are We Talking About?

Before we get to the good stuff — cleaning them up — let’s break down the types of load balancers you may have in your cloud world. Imagine each one is like a different style of traffic cop:

  1. Classic Load Balancer (CLB): Think of this as the old-school traffic cop from back in the day. It’s reliable but simple — its only job is to wave cars through the intersection without any special consideration for what kind of car it is or where it’s going. If your cloud setup has been around for a while, chances are you’ve got some of these classic load balancers still standing, quietly doing their job but without the flexibility or modern capabilities of the newer models. It’s basic, and while it still works, it’s not exactly keeping up with the fast lane of today’s cloud traffic.
  2. Application Load Balancer (ALB): Now we’re getting into the fancy stuff. Imagine a traffic cop who not only directs traffic but also knows exactly where each car is headed and can send them down the right lane based on that. It’s like having a cop who can manage complex intersections, separate buses from cars, and make sure everything flows smoothly without anyone getting lost. ALBs are perfect for modern web applications, where you need advanced routing based on things like URLs, hostnames, or even the content of the request. If you’re running microservices or dynamic web apps, this load balancer is the cool, tech-savvy officer you need in your cloud police force.
  3. Network Load Balancer (NLB): This is your traffic cop on steroids — picture one handling the busiest, fastest highway in the city with the precision of a Formula 1 pit crew. The NLB is built for speed and efficiency, designed to handle extreme volumes of traffic without blinking. It’s all about low-latency, high-performance traffic management. It works at a lower level than the ALB, handling raw network connections rather than just web traffic. So, if you’ve got high-demand workloads like gaming servers, real-time data processing, or financial systems that need to respond instantly, this is your heavy-duty cop keeping everything in check at lightning speed.

So, How Do You Clean Them?

Here’s where things get interesting. You’ve found your idle load balancers, but you can’t just delete them right away. Nope, first you need to remove the listeners — think of these as the load balancer’s ears. Without them, the load balancer can’t hear or route any incoming traffic.

Step 1: Get the Listeners

You’ll need to ask each load balancer what ports it’s listening on. Depending on the type of load balancer, the command differs a bit (don’t worry, it’s simpler than it sounds):

Here’s how you get a list of listeners:

– For Classic Load Balancers (v1):

aws elb describe-load-balancers — load-balancer-names <load-balancer-name>

– For Application and Network Load Balancers (v2):

aws elbv2 describe-load-balancers — names <load-balancer-name>

Step 2: Remove the Listeners

Once you have the listener details, you can delete them with:

– For Classic Load Balancers (v1):

aws elb delete-load-balancer-listeners --load-balancer-name <load-balancer-name> --load-balancer-ports <port>

– For ALB and NLB (the cooler, newer types):

aws elbv2 delete-listener - listener-arn <listener-arn>

Step 3: Finally, Delete the Load Balancer

Now comes the fun part — deleting that load balancer that’s been quietly draining your wallet:

– For Classic Load Balancers:

aws elb delete-load-balancer — load-balancer-name <load-balancer-name>

– For ALB or NLB (v2):

aws elbv2 delete-load-balancer — load-balancer-arn <load-balancer-arn>

Approval: Better Safe Than Sorry!

Even though you’ve found an idle load balancer, you might want to double-check with the owner before deleting it. The worst-case scenario? They actually needed it, and now things might go sideways. That’s why approvals matter. But doing this manually each time is a hassle. Enter automation.

Automation Saves the Day!

Doing this once or twice is fine, but what if you want to make sure this is always done? Manually hunting down idle load balancers, checking for approvals, and deleting them gets old fast.

That’s where Wiv comes in. At Wiv, you get the tools to do all of this in one smooth, automated process. Discover, manage, get approvals, and delete idle load balancers — it’s all built into the system. No need to keep repeating the process yourself. Wiv takes care of it all, from discovery to remediation. You can even track the whole process, ensuring that your AWS environment stays efficient without the headache of manual cleanup.

Finding Idle Load Balancers is Easy, But How Do You Clean Them?

Wrapping Up: Why It’s All Worth It

Keeping your AWS environment tidy and cost-efficient doesn’t have to be a burden. With a simple query, a few CLI commands, and the power of automation, you can save money and time — and who doesn’t love that?

So, whether you thank God or AWS for helping you find those idle load balancers, cleaning them up just got a lot easier. And if you’re ready to level up, Wiv has your back with effortless, continuous automation.