Idle load balancers and IPs are easy to create and easy to forget. A load balancer is spun up for a service that later moved, scaled to zero or was decommissioned, but the balancer is left running because nothing prompts its removal; a static IP is reserved for an instance that was since terminated, and the address keeps billing precisely because it is no longer attached to anything. Both share the same trap: they are priced on an hourly reservation rather than on use, so an endpoint with zero traffic and a reserved address with no target cost exactly the same as a busy one. Individually the amounts look small, which is why they survive, but across a large estate the count runs into the hundreds and the total is real money for capacity that does nothing.
This article is part of our complete guide to cloud rightsizing and waste elimination, the cluster pillar it links up to. It is one of the most reliable wins in the broader hunt for idle cloud resources across providers, where networking artifacts are a category teams routinely overlook.
Load balancers and reserved IPs bill on an hourly reservation, not on use. An endpoint with no traffic and an address with no target cost the same as busy ones. Find the zero-use ones and remove them.
Step 1: Inventory every load balancer and reserved IP
Eliminating idle load balancers and IPs starts with a complete inventory, because you cannot remove what you have not listed. Enumerate every load balancer across all accounts, subscriptions, projects and regions, since these artifacts hide in regions teams forgot they used, and every reserved or static IP alongside it. The clouds name them differently, Elastic Load Balancers and Elastic IPs on AWS, Load Balancers and reserved public IPs on Azure, forwarding rules and static external IPs on Google Cloud, load balancers and reserved public IPs on OCI, but the inventory question is the same: list them all with their region, their attachment state, and the traffic or target behind each. A multi-account estate almost always turns up balancers and addresses nobody on the current team remembers creating, which is exactly the population this exercise targets.
Step 2: Identify the idle ones by traffic and attachment
With the inventory in hand, classify each artifact as in-use or idle using two simple tests. For load balancers, check the traffic and healthy-target metrics over a representative window: a balancer carrying no requests and fronting no healthy targets is idle, and one fronting a target group that scaled to zero and never came back is idle in practice. For IP addresses, the test is attachment: a reserved or static IP not associated with a running resource is unattached, and on most providers an unattached reserved address is billed specifically because it is idle, the opposite of the usual model where attached addresses are free. Sorting the inventory by these two signals separates the endpoints doing real work from the ones billing for nothing, and the idle column is your removal list. This is the same evidence-based approach as auditing a cloud environment for waste, focused on networking.
| Artifact | Idle signal | Action |
|---|---|---|
| Load balancer, no traffic | Zero requests over the window | Confirm owner, then delete |
| Load balancer, no healthy targets | Target group empty or all unhealthy | Restore target or remove the balancer |
| Unattached reserved IP | Not associated with any resource | Release the address |
| IP on a stopped instance | Reserved address billing while target is down | Release or reattach as intended |
| Orphaned forwarding rule | Points at a deleted backend | Remove the rule and its IP |
Paying by the hour for endpoints that point at nothing?
Our cloud cost audit inventories every load balancer and reserved IP across your estate, flags the idle ones by traffic and attachment, and proves the saving against a clean baseline on AWS, Azure, GCP and OCI. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Step 3: Confirm ownership, then remove safely
Before deleting, confirm that an idle-looking endpoint is genuinely safe to remove, because a few load balancers are idle by design: a standby for failover, a balancer fronting a service that is seasonal or scaled to zero on purpose, or an address held deliberately so it can be reattached to a known target. Trace each candidate to an owner, confirm the endpoint is not a deliberate standby, and where ownership is unclear, follow the process in tackling untagged and unowned resources to find the responsible team before acting. Once confirmed, remove the load balancer and release the address, and for reserved IPs that exist only to keep a known value, consider whether the value truly needs to persist or whether it can be released and re-requested when the target returns.
Step 4: Stop them coming back with a standing sweep
A one-time cleanup of idle load balancers and IPs is worth doing, but the population regrows as services move and instances terminate, so the durable fix is a standing sweep. Schedule a recurring check that lists load balancers with no traffic and no healthy targets, and reserved IPs with no attachment, and routes the findings to the owning team for action. Most providers expose the traffic, health and attachment signals through their monitoring and resource APIs, so the sweep can be automated to flag idle networking artifacts as they appear rather than waiting for the next audit. This is the networking slice of building a continuous waste detection process, and it keeps a category that regrows steadily from quietly rebuilding on the bill. Verify the current hourly load balancer and idle-IP pricing for each provider in its documentation as of May 2026 when sizing the saving, since these rates change.
The Cloud Waste Audit Framework includes the idle networking checklist and the queries we use to surface zero-traffic load balancers and unattached IPs across an estate.
The short version
Idle load balancers and unattached IPs are pure hourly waste, billed on reservation rather than use. Inventory every load balancer and reserved IP across all accounts and regions; identify the idle ones by zero traffic, empty or unhealthy targets, and lack of attachment; confirm ownership so you do not remove a deliberate standby, then delete the balancers and release the addresses; and stand up a recurring sweep so the population does not regrow. Verify current pricing before sizing the saving. It is one of the cleanest cuts on a cloud bill because the waste is unambiguous. When you want every idle networking artifact found and removed with the saving proven down, that is part of what our rightsizing and waste elimination service delivers.