Load Balancer Backend Service
Does ZopNight manage Load Balancer Backend Service?
Backend services carry no meter of their own. Each is the routing layer that connects a load balancer's forwarding rules to instance groups or NEGs, with health checks and capacity settings. ZopNight maps every backend service via Cloud Asset Inventory to link balancers with the compute they front, flagging backends with 0 healthy targets.
Rules that fire on Load Balancer Backend Service
No active rule family targets Load Balancer Backend Service today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A backend service defines how a Google load balancer distributes traffic to instance groups or NEGs, including health checks and capacity settings. Misrouted or orphaned backends indicate dead load-balancing paths.
A backend service costs nothing: topology is the value
Unlike the forwarding rules in front of it, a backend service has no hourly meter. Its cost story is indirect: it determines where load-balanced traffic lands, which health checks probe it, and how capacity is spread, so its configuration decides whether the compute and rule charges around it are buying a working path or a dead one. When cost shows up here at all, it shows up as the balancer’s data-processing charges and the instances the backend keeps busy, both billed under their own types.
How ZopNight stitches backends to compute
ZopDev maps backend services via Cloud Asset Inventory to connect load balancers with the compute they front, and flags backends with no healthy targets. That mapping is what turns three separate inventories (forwarding rules, backend services, instance groups) into a navigable chain: which rule sends traffic to which backend, and which VMs or NEGs sit behind it. A backend has no lifecycle to schedule, so its role in the platform is topological: it explains what a balancer charge is actually attached to.
Dead paths a backend’s health state reveals
The flag worth acting on is a backend service whose target list is empty or entirely unhealthy. Three situations produce it: an instance group scaled to zero or deleted while the backend kept referencing it; a health check whose port or path drifted from what the application serves, marking live instances unhealthy and silently shifting traffic elsewhere; and migration leftovers where a new backend took over but the old one, and sometimes the rule pointing at it, was never removed. Each is either an outage in waiting or a cleanup candidate, and the health state distinguishes them faster than any billing line can.
Backend services in the console
Google Cloud console → Network services → Load balancing → Backends lists every backend service with its attached balancer and a health summary per instance group or NEG. A backend showing 0 of N healthy under a live forwarding rule deserves attention today, not at the next cost review.