# GCP Idle Load Balancer

> Flags regional and global load balancers whose forwarding rules carried near-zero requests, bytes and connections for 30 days.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-idle-load-balancer

---

## The hourly fee on a forwarding rule

A Google Cloud load balancer is billed through its forwarding rules. Google's
[network pricing](https://cloud.google.com/vpc/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

```bash
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

```text
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.

**Warning**
If you reserved the load balancer's IP address, releasing the forwarding rule leaves the static address unassigned, and Google bills unassigned static external addresses at a higher rate. Release it too unless you plan to reuse it.
