未使用の予約

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

確保したのに消費されていない Compute Engine の容量予約を見つけます。予約は VM が 1 台も乗っていなくても、確保した容量分がオンデマンド単価で課金され続ける — 気づきにくく金額の大きい無駄です。

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

何を無駄とみなすか

消費数(inUseCount)がゼロのまま維持されている特定 SKU の容量予約。イベント前の一時確保が解除され忘れたケースや、予約の指定条件が厳しすぎて VM がマッチしないケースが典型です。

判定条件

• 特定 SKU の予約(specific reservation)である
• 消費数(inUseCount)が 0 である
• 30 日の時間ゲートを通過している(確保直後・立ち上げ準備中を候補にしないため)

必須 facts

• 予約の種別(特定 SKU であること)と対象マシンタイプ・ゾーン
• 予約枠(count)と消費数(inUseCount)
• 確約利用割引(CUD)との連結有無(契約に連結された予約は削除対象にしません)
• 経過日数(時間ゲートの判定)

取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

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

• 販売イベント・移行作業など、近い将来のために意図して確保している容量
• 予約の指定条件(特定予約の指名設定)と VM 側の設定が食い違い、使うつもりなのにマッチしていないだけのケース — この場合の正解は削除ではなく設定の修正です
• 直近まで消費されていた予約(消費ゼロになってからの正確な期間は観測できないため、経過日数で保守的に判定します)

実行前の確認

• 予約の作成者・所有チームに確保目的と利用予定を確認する
• 消費ゼロの原因が「不要」なのか「設定不一致」なのかを切り分ける
• IaC(Terraform 等)での参照有無を確認する
• 同じゾーン・マシンタイプの容量が将来も必要か(再確保できない場合の影響)を確認する

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

Safety Tier: high(削除後に同じ容量を再確保できる保証がありません)

1. 削除前に予約の構成(マシンタイプ・台数・ゾーン・共有設定)を記録する — 予約はデータを持たないため、これが実質のバックアップです
2. 利用予定なしの確認を関係者から取り、記録する
3. その後に削除する

ロールバック: 記録した構成で予約を再作成します。ただし同一ゾーンの容量が常に再確保できるとは限らない点を、削除前の確認で織り込みます。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。他のルールはルールカタログを参照してください。