Idle Application Load Balancers: The Hourly Charge for Doing Nothing

Imagine getting a bill at the end of the month for a piece of software that did absolutely nothing. Zero traffic, zero targets, just zero utility. Yeah, that would be incredibly frustrating. Right, and on AWS, that isn't really a glitch. That is just how application load balancers work.

Exactly. So today we are doing a deep dive into the provided AWS billing documentation and architecture guides to hunt down these exact types of zombie resources. Our mission is basically to figure out why your cloud bill is quietly creeping up and exactly how to stop it. It is a really fascinating problem, honestly. You set up an application load balancer, or ALB, and even if it is processing zero requests, like with zero healthy targets attached, it just bills you continuously.

I mean, I get why a database costs money when idle, you know, because it is holding data, but an ALB is just a router. Right, exactly. If no traffic is hitting it, it requires zero compute. So why is there a base charge at all? Well, it comes down to the unit math that AWS applies just for keeping the resource provisioned.

An ALB incurs a base hourly charge literally just for existing. Just for being there. Yeah, that is about $0.0225 per hour in the US East One region, plus any capacity units. But here is where it really starts to compound. Okay.

If that ALB is internet facing, it actually has to hold on to public IPv4 addresses to function. Oh, right. And AWS recently started charging for public IPv4 addresses because, well, we have literally run out of them globally. Exactly. They are treating them like a scarce commodity to encourage engineers to release them.

Right. So because of that scarcity, those public IPv4 addresses bill at an additional $0.005 per hour each. Wow. So you are paying the base hourly charge for the load balancer, plus the hourly charge for the IPs 24/7. It's basically like, I don't know, leaving a rented running generator in an empty parking lot.

You pay the hourly base rate regardless of whether you ever plug a single tool into it. That is a great way to look at it, except with AWS, you aren't just paying for the generator. Right. You are also paying rent on the empty parking space it's sitting in, which in this case is that scarce public IPv4 address. That makes perfect sense.

But if we connect this to the bigger picture of how engineering teams operate, how does a running generator just sit in the parking lot unnoticed? Surely someone spots the waste. You would think so, but it really just survives in the gaps of organizational ownership. Often a test environment is spun down, but the load balancer gets left behind. Oh, I see.

Nobody explicitly owns that specific idle resource anymore. And because it's doing nothing, it doesn't cross any CPU or traffic thresholds to trigger a system alarm. And I imagine when the invoice is generated, this fractional hourly trickle is practically invisible. It just gets completely buried inside a massive, aggregated, per-service AWS bill. Spot on, it is a needle in a very expensive haystack.

Okay. Let's say I want to find this silent waste in my own architecture right now. What is the actual signal? Like, where do I look? You can go into CloudWatch and look for a request count metric of exactly zero, but that is not enough on its own.

Why not? Because you then need to use the describe-target-health API action to confirm that there are absolutely no healthy targets attached to it. Ah, okay. And you want to look for that pattern over a rolling 14 to 30-day window to be safe. Okay.

So if I do that and I see zero requests and no targets over the last month, if it's genuinely doing nothing, can't we just run a dry run and delete it safely? No, I need to be very clear about the danger here. Deleting an ALB cannot be undone. Wait, really? Yes, you can never call a resource provably or mathematically unused, and no preview or dry run makes deleting it risk-free.

But why? What breaks if the metric shows zero traffic? It is completely idle. Because if you delete that ALB and realize you made a mistake, any replacement you provision gets a brand new DNS name. Oh, wow.

I didn't think about that. Yeah. A Route 53 record or an external CNAME controlled by a partner or a client somewhere could still be pointing to that exact original DNS name. So if you wipe it out, the routing is permanently broken until you somehow track down and update every single external dependency? Precisely.

You must find every reference to that DNS name before hitting delete, or you risk breaking external systems that you don't even control. Auditing hundreds of Route 53 records and external CNAMEs by hand just to clean up one load balancer sounds like a total nightmare. It is incredibly tedious to do manually. To flag this pattern automatically, you can use a free source-available scanner by running pip install cloudcostwise on your own machine. Nice.

Yeah, it runs read-only and sends absolutely nothing to CloudWise. Well, it's really good to know you don't have to hunt these down entirely by hand. So before you leave that rented generator running in the parking lot for another month, it is definitely worth checking those CloudWatch metrics. Absolutely. Which leaves you with an important question to ponder.

Beyond load balancers, what other zombie resources might be lurking in your environment right now, quietly draining your budget one fraction of a cent at a time?