GCS soft delete 過剰

ルール ID: gcp.gcs.bucket.softdelete-excess ・ カテゴリ: rate ・ 必要な読み取り: インベントリ + ストレージ統計(権限が付くまで locked) 計画中

誤削除からの復元用に保持される soft delete 分のストレージが、live データに匹敵する規模で課金されているバケットを見つけます。削除・上書きが頻繁なバケットでは、保護のための保持分が本体並みの課金になり得ます。

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

何を無駄とみなすか

soft delete の保持容量が live 容量に対して過大なバケット。復元がまず必要にならないデータ(再生成可能な中間生成物・一時ファイル等)にまで保護コストを払っている状態です。

判定条件

• soft delete の保持量が live 容量の 50% 以上、かつ大容量のバケット
• 該当した場合、soft delete の無効化(または保持設定の見直し)の検討を提案します
• ストレージ統計の読み取り権限が付くまでは locked と表示し、判定しません

必須 facts

• live 容量と soft delete 保持容量
• soft delete 設定(有効/無効・保持期間)
• バケット名・ロケーション・ストレージクラス

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

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

• 誤削除・不正な削除への備えとして soft delete を意図的に有効化しているバケット
• 移行・大規模クリーンアップの直後で、保持分が保持期間の経過とともに自然に減っていく途中のバケット
• 削除済みデータの復元可能性がコンプライアンス上求められているバケット

実行前の確認

• バケットの用途とデータの重要度(復元が必要になり得るか)を確認する
• バージョニング等、soft delete 以外の保護手段の有無を確認する
• IaC(Terraform 等)での設定管理の有無と、バケット利用チームの合意を確認する

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

Safety Tier: medium(soft delete の無効化・保持期間変更は設定変更で、いつでも再有効化できます)

• いきなり無効化せず、保持期間の短縮という中間の選択肢も検討します
• ロールバック: 設定を再有効化します。ただし無効化していた期間に削除されたオブジェクトは保護されていない(復元できない)点に注意します

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。既存の保持分が掃けるまで、効果は段階的に現れます。