How to review an Azure idle load balancer
A load balancer may be idle when backend pools, health, flows, and workload context show it no longer serves a live path. Empty pools are stronger evidence than low traffic, but neither automatically proves deletion is safe.
Map frontends to their real traffic pathsWho reviews this signal?
- Accountable owner
- Network + application owner
- Review cadence
- Monthly
Check observation dates and read-only scope. Your team approves and implements changes outside Costframe.
How this finding happens
- →Backend compute or a cluster is removed while ingress infrastructure remains.
- →A blue/green or migration endpoint is retired incompletely.
- →A low-frequency DR or administrative endpoint is mistaken for abandoned infrastructure.
Collected evidence and verification limits
Checked when available
- ✓Load balancer, frontend, rule, probe, NAT and backend-pool configuration
- ✓Backend membership and health
- ✓Flow, byte, packet, and connection signals when available
- ✓Public IP, DNS, gateway, NSG, and IaC relationships
Not always verifiable
- —Low traffic may be normal for DR, admin, or seasonal endpoints.
- —Metrics may be unavailable or incomplete for a tier or observation window.
- —External DNS and allowlists may not be visible.
Missing or stale evidence is a limitation, not a passed check.
Why this finding might be wrong
These conditions lower confidence or require manual owner review before action.
- Disaster-recovery standby
- Low-frequency administrative endpoint
- Seasonal or event-driven service
- Migration endpoint waiting for a planned cutover
Plan the change and recovery path.
- Map frontends to DNS, certificates, rules, probes, backends, and downstream dependencies.
- Confirm the observation window covers expected traffic cycles.
- Disable or detach in a reversible stage where possible before deletion.
- Remove linked public IPs only after their independent dependency review.
Rollback / recovery
Restore the prior load-balancer configuration from IaC or an exported template and validate probes, flows, DNS, certificates, and backend health.
How savings are calculated
Net monthly saving includes only confirmed load-balancer processing/rule charges being removed; linked IP and data charges are modeled separately to avoid double counting.
Do not quote a quantified saving when the billing scope, pricing basis or required workload evidence is incomplete or stale. Treat a modeled amount as estimated until suitable billed outcomes support it.
Check the billed outcome
The meter stops and synthetic/user traffic remains healthy.
Map frontends to their real traffic paths
Review rules, NAT, probes and backend membership with the application owner. Use a window that includes administrative and disaster-recovery traffic. Save the configuration and test a reversible detachment where feasible before considering deletion.
Review frontend IP dependenciesIf the owner cannot resolve a dependency or recovery requirement, keep the candidate in review rather than treating it as approved.