What it is
An Azure Load Balancer whose backend pool contains no members. The frontend IP, load-balancing rules, and health probes still exist, but there is no VM or NIC behind them to receive a connection. Inbound traffic to the frontend has nowhere to go and is dropped.
Why it happens
Backend membership on a Load Balancer lives in two separate places, which is what makes an empty pool easy to miss. IP-based backends are stored on the load balancer itself in loadBalancerBackendAddresses. NIC-based backends are not recorded on the load balancer at all; Azure only stores that association on the NIC side, in ipConfigurations[].loadBalancerBackendAddressPools. So a pool can look non-trivial in the portal yet have zero live members once the VMs behind it are deleted, moved, or rebuilt with new NICs that were never re-added.
Azure does not flag an empty pool as a problem, and the health probe has nothing to report because there are no instances to probe. The result is a load balancer that accepts a frontend and a rule but forwards to nothing, so the outage surfaces as dropped connections rather than a clear configuration error.
What it costs / blast radius
The primary harm is reliability: any client connecting to the frontend IP is silently dropped because no backend instance receives the traffic. If this load balancer fronts a production service, that service is unreachable for as long as the pool stays empty, and the symptom looks like a network problem rather than a missing backend.
The secondary harm is cost, and it is small. A Standard Load Balancer runs roughly $18/month base plus data-processing charges at list price. (Basic Load Balancer, which was free, retired on September 30, 2025, so remaining Basic instances should be migrated regardless.) The point here is the dropped traffic, not the bill.
See it
// IP-based backends live on the LB; NIC-based backends live on the NIC.
// This surfaces LBs with no IP members as candidates to verify.
Resources
| where type =~ 'microsoft.network/loadBalancers'
| extend pools = properties.backendAddressPools
| mv-apply pool = pools on (
summarize ipMembers = sum(array_length(pool.properties.loadBalancerBackendAddresses))
)
| where isnull(ipMembers) or ipMembers == 0
| project name, resourceGroup, subscriptionId,
sku = sku.name// Re-add the NIC/VM that should be behind the frontend...
az network nic ip-config address-pool add \
--nic-name vm-prod-nic --ip-config-name ipconfig1 \
--resource-group rg-prod \
--lb-name lb-prod --address-pool backend-pool
// ...or remove a load balancer that no longer fronts anything.
az network lb delete --name lb-prod --resource-group rg-prodHow StratoLens helps
StratoLens inventories every Load Balancer across every subscription and resolves backend membership both ways, checking the load balancer's own IP-based pool and reverse-looking-up the NICs that reference it, so a pool that only ever held NIC-based members is not mistaken for populated. Empty pools that are quietly dropping traffic get flagged automatically, with how long they have been empty and what they last pointed at.