ログバケット保持超過

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

Cloud Logging のログバケットで、無料の 30 日を超える保持設定により課金対象の保持量が発生している状態を見つけます。「なんとなく長め」に設定された保持期間は、静かに課金を積み上げます。

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

何を無駄とみなすか

保持期間が無料の 30 日を超えて設定され、課金対象の保持量が発生しているログバケット。実際には参照されない古いログの保管に費用を払い続けている状態です。

判定条件

• ログバケットの保持期間設定が 30 日を超えており、課金対象の保持量が発生している
• _Required バケットと Locked なバケットは対象から除外します(保持設定を変更できないため)

必須 facts

• バケット名と保持期間の設定値
• _Required かどうか・Locked かどうか
• 取得できる場合: 課金対象の保持量

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

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

• 監査・法令・社内規程で 30 日超の保持が義務付けられているログ
• セキュリティ調査・フォレンジックのために意図的に長期保持しているログ
• 保持期間を短縮すると、既存ログのうち新しい保持期間を過ぎた分が削除される点そのものが危険要因です

実行前の確認

• そのバケットに入るログの保持要件(監査・法令・社内規程)を関係者に確認する
• 長期保存が必要なログは、保持短縮の前に別ストレージへのエクスポート経路を整える
• IaC(Terraform 等)で保持期間が管理されていないか確認する

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

Safety Tier: high(保持期間を過ぎたログの削除は復元できない操作)

• 短縮前に、必要なログをエクスポートしてバックアップします
• 一気に最小値へ短縮せず、段階的に短縮して影響(参照ニーズ)を観察してから次の段階に進みます
• ロールバック: 保持期間の設定値は元に戻せますが、削除済みのログは戻りません。バックアップの取得を必須手順とします

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。保持量が新しい保持期間の水準に収束するまで、効果は段階的に現れます。