# Azure Load Balancer

> Standard-SKU Azure Load Balancer bills per rule and per GB of data processed, so an LB fronting an empty backend pool still pays for every configured rule. ZopNight reads SKU and backend-pool state through Resource Graph and pairs 60 days of Azure Monitor metrics with billing data to flag idle load balancers.

Source: https://zop.dev/integrations/azure/azure-lb
Updated: 2026-08-19

---

Azure Load Balancer distributes Layer-4 traffic across backend pools, with Standard SKU billed per rule and per GB processed. Load balancers with empty or dead backend pools keep billing without serving traffic.

## Rules and processed gigabytes: the Standard SKU meters

A Standard load balancer carries two meters: a charge per configured load-balancing and outbound rule, and a charge per gigabyte of data it processes. The rule meter is the one that keeps running when traffic stops. Five rules on a balancer that routes nothing cost the same as five rules on one carrying production load. Basic-SKU balancers were free but are retired, so every balancer in a modern subscription participates in this billing model, along with the Standard public IP it typically holds.

## Backend-pool state as a waste signal

Discovered via Azure Resource Graph with SKU and backend-pool state. Azure Monitor metrics over a 60-day lookback and Cost Management billing support idle-LB recommendations, and ML auto-tagging covers this type. A load balancer cannot be stopped or paused, so ZopNight treats it as a detection target rather than a scheduling one: the backend-pool state read at discovery time is the cheapest possible tell, because a pool with zero healthy members means the rules being billed are routing to nowhere.

## Load balancers that route nothing

The recurring shapes of waste: a balancer whose backend VMs were deleted, leaving an empty pool and a live rule meter; a balancer kept after a service moved behind Application Gateway or Front Door, quietly duplicating the entry point; and internal balancers created per-environment by templates, where the dev and test copies keep their rules configured year-round for workloads that stopped existing. In each case the fix is deletion or consolidation, and the attached public IP should be released in the same pass.

## Reviewing load balancers in the portal

Azure portal → Load balancers shows every balancer with its SKU. Open one and check Backend pools: a pool with no instances, or only deleted references, marks the balancer as a candidate. Cross-check its Metrics blade for processed bytes before removing it.
