Idle Load Balancers and Reserved IPs: Small Line Items, Big Annual Waste

Big cloud waste gets the attention: the over-provisioned node pool, the zombie namespace. But there's a whole category of small waste that's almost more insidious, precisely because each item is too cheap to bother with. A reserved IP doing nothing. A forwarding rule pointing at a deleted backend. A load balancer with no healthy targets.

Individually: pocket change. Collectively, across every project and a few years of accumulation: a line item worth a real afternoon of cleanup.

The usual suspects

Reserved static IPs that aren't attached to anything. Here's the twist most people miss: GCP charges more for an idle reserved static IP than for one that's actually in use, roughly double the hourly rate. (An IP assigned to a forwarding rule is free; an idle reserved one is the premium-priced version.) So a detached static IP is the most expensive IP you can own, and it's doing precisely nothing. Every one on your account is pure waste at the top rate.

Idle load balancers. A forwarding rule has a small fixed hourly cost whether it serves a million requests or zero. After a migration, the old LB often lingers, pointing at an empty backend, healthy-target count of zero, serving nobody, billing forever.

Orphaned forwarding rules and target pools left behind when the thing they fronted got deleted piecemeal.

How to find them

• Static IPs: list reserved addresses where the status is RESERVED (not IN_USE). Each one is billing at the premium rate for nothing.
• Load balancers: look for forwarding rules whose backend services have zero healthy backends, or near-zero request counts over a fortnight.
• Cross-reference projects. This waste loves to hide in the projects nobody looks at: old sandboxes, deprecated environments, that one team's experiment.

Why it's worth doing

Two reasons beyond the direct savings:

1. Hygiene compounds. A tidy account is one where the next problem is easier to spot. Noise hides signal.
2. It's a confidence builder. These are near-zero-risk deletes. Knock out forty orphaned IPs and you've built the muscle (and the team trust) for the bigger, scarier optimisations.

The cleanup, safely

• For IPs: confirm RESERVED not IN_USE, check nothing's about to reattach, then release.
• For LBs: confirm zero healthy backends and zero recent traffic, then tear down the forwarding rule, target proxy, and backend service together. Partial deletes are how orphans are born.

How FeckBills helps

FeckBills runs dedicated detectors for exactly this long tail: gcp.idle-ip finds reserved-but-idle static IPs, and the orphaned-resource detectors catch the forwarding rules and snapshots that get left behind. Across --all-projects, it sweeps every project your credential can see (including the ones you forgot existed) and ranks the lot by £/mo.

Scan every project and clear out the long tail.