空のバックエンド LB

ルール ID: gcp.lb.backend.empty ・ カテゴリ: zombie ・ 必要な読み取り: インベントリのみ(初回スキャンで検出) 計画中

転送先がひとつもないロードバランサは、トラフィックを一切さばけないまま forwarding rule の課金だけが続きます。このルールは、その「行き先のない LB」を見つけます。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

バックエンド(バックエンドサービスの backend / ターゲットプールのインスタンス)が空の forwarding rule。トラフィックを運べない状態のまま課金が発生します。

判定条件

• forwarding rule のバックエンドが空、かつ作成から 15 日以上経過(単発観測では open にしない)
• バックエンド構成を末端まで解決できた場合のみ判定します(解決できない構成は候補にしません)
• 除外: URL マップが defaultUrlRedirect / urlRedirect などのリダイレクトで応答する構成は、バックエンドが 0 でも利用中として除外します(HTTP→HTTPS リダイレクト専用 LB は正当な利用のため、URL マップの全アクションを解決してから判定します)
• forwarding rule の課金はプロジェクト単位でバンドルされるため、1 本あたりの削減額は**「推定不能」を明示**します(金額を捏造しません)

必須 facts

• forwarding rule の LB 種別
• 参照先(バックエンドサービス / ターゲットプール)の解決結果とバックエンド数
• 作成からの経過日数
• 取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

• blue-green デプロイや切替作業で、一時的にバックエンドが空になっている LB
• DR・切替待機用に、平常時はバックエンドを空にして温存している LB
• IP アドレスの確保だけを目的に維持している forwarding rule

実行前の確認

• LB の IP アドレスが静的予約かエフェメラルかを確認する(エフェメラルの場合、削除で IP を失う)
• DNS レコードや外部システムからその IP への参照が残っていないかを確認する
• IaC(Terraform 等)での参照有無と、デプロイパイプラインでの利用予定を確認する

非破壊テストとロールバック

Safety Tier: high(削除は復元に手順が要る操作)

1. forwarding rule と関連構成(バックエンドサービス / ターゲットプール定義)を書き出して保存する
2. IP を残す必要があれば静的予約に切り替えたうえで、2 週間観察してから削除する

ロールバック: 保存した定義から forwarding rule を再作成します。静的予約済みの IP であれば同じアドレスで復元できます。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。本ルールは削減額を事前に推定しないため、請求比較での確認が特に重要です。