Regional and global Google Cloud load balancers with near-zero traffic for 30 days

The hourly fee on a forwarding rule

A Google Cloud load balancer is billed through its forwarding rules. Google’s network pricing lists, for both global and regional forwarding rules at US prices, $0.025 per hour covering up to the first five rules and $0.01 per hour for each additional rule, plus data processing charges per GiB. Global and regional rules are counted separately, per project. At 730 hours a month, a single rule costs about $18.25. The rule charge does not depend on traffic, so a load balancer that fronts a decommissioned service keeps billing. Regional prices vary, so check your region’s table.

Listing forwarding rules and checking traffic

gcloud compute forwarding-rules list \
  --format="table(name,region,IPAddress,loadBalancingScheme,target)"

Add --global to list only global rules. For each rule, chart the metric that matches its type in Metrics Explorer over 30 days: https/request_count for external Application Load Balancers, tcp_ssl_proxy/new_connections and tcp_ssl_proxy/open_connections for TCP and SSL proxy load balancers, and l3/external/ingress_bytes_count or l3/internal/egress_bytes_count for passthrough ones, all under loadbalancing.googleapis.com.

Every traffic axis has to be quiet

ZopNight looks at up to nine traffic measures per forwarding rule: HTTPS request count, ingress and egress bytes for external and internal passthrough traffic, and new connections, open connections, ingress bytes and egress bytes for TCP and SSL proxies. Each measure it has data for must stay below 0.05 on both its average and its peak. The history must cover at least 30 days, and the forwarding rule must have a known cost. Regional and global load balancers are checked the same way, against whichever of these measures exist for them.

Why busy-looking silence still counts as traffic

Checking egress and open connections, not just requests and new connections, is what stops false alarms. A passthrough balancer in front of a download service can show almost no inbound bytes while sending a lot out, and a proxy in front of long-lived database or WebSocket connections opens few new connections while existing ones stay busy. Any single measure above the floor keeps the load balancer off the list. With no traffic data at all, or less than 30 days of it, there is no finding.

What deleting it saves

saving = current monthly forwarding rule cost
cost after deletion = 0

Removing an unused load balancer

1. Confirm in Cloud Monitoring that no traffic reaches the forwarding rule.
2. Check which backend services, instance groups or network endpoint groups it points at, and whether DNS still resolves to its IP address.
3. Get sign-off from the owning team.
4. Delete the forwarding rule, then its target proxy, URL map and backend service if nothing else uses them: gcloud compute forwarding-rules delete RULE_NAME --region=REGION, or --global for a global rule.