GCS lifecycle 未設定

ルール ID: gcp.gcs.bucket.lifecycle-missing ・ カテゴリ: hygiene ・ 必要な読み取り: インベントリのみ(初回スキャンで検出) 計画中

ライフサイクルルールのないバケットでは、使われなくなったオブジェクトが自動整理されず、そのまま無期限に課金され続けます。このルールはその「蓄積が止まらない設定」を見つけます。

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

何を無駄とみなすか

ライフサイクルルールが 1 つも設定されていないバケット。古いオブジェクトの自動整理(削除や、より安いストレージクラスへの移行)が効かないため、不要になったデータの課金が放置した分だけ積み上がります。

判定条件

• バケットにライフサイクルルールが 1 件も設定されていない
• インベントリのみで判定できるため、初回スキャンから検出されます

必須 facts

• バケット名・ロケーション・デフォルトストレージクラス
• ライフサイクル設定の有無(ルール一覧)
• 取得できる場合: オブジェクト数・保存容量(規模の参考情報)

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

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

• 法令・監査要件で全オブジェクトを恒久保持するバケット
• アプリケーション側で独自のクリーンアップ処理を実装済みのバケット
• オブジェクトが少なく、自動整理を設定する効果がほぼないバケット

実行前の確認

• 命名・ラベルから用途と保持要件(法令・契約)を確認する
• バケットが IaC(Terraform 等)で管理されている場合は、コード側にルールを追加する
• バケットを利用しているチームに、削除・クラス移行してよい条件を確認する

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

Safety Tier: low(提案するのはライフサイクルルールの追加という設定変更のみ)

• まずストレージクラス移行(SetStorageClass)や、prefix 等で対象を限定した条件から小さく始めます
• 削除(Delete)アクションを含むルールは、対象となるオブジェクトを確認してから適用します
• ロールバック: ライフサイクル設定自体はいつでも変更・削除できます。ただしルールによって削除されたオブジェクトは元に戻らないため、削除ルールの適用は慎重に行います

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。クラス移行・削除の効果はストレージ課金に段階的に現れます。