EBS idle

ルール ID: aws.ebs.volume.idle ・ カテゴリ: zombie ・ 必要な読み取り: インベントリ + 利用メトリクス 計画中

アタッチはされているのに、実際にはほとんど読み書きされていない EBS ボリュームを見つけます。マウントしたまま忘れられたデータ置き場は、未アタッチのボリュームより見つけにくい無駄です。

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

何を無駄とみなすか

インスタンスにアタッチされているが I/O がほぼゼロのボリューム。使われていなくても確保容量分のストレージ課金が続きます。

判定条件

• 30 日間の read/write ops の p99 ≤ 5 ops/時

欠測の扱い: メトリクス系列が取得できない・欠けている場合、それは「観測不能」であって idle ではありません。欠測を idle と解釈して候補にすることはしません。

必須 facts

• ボリュームのアタッチ状況とアタッチ先インスタンスの状態
• 30 日間の read ops / write ops(p99)— 系列の存在自体を確認する
• サイズ・ボリュームタイプ
• 取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

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

• 月次・四半期など観測窓より長い周期でのみ読み書きされるアーカイブ・バックアップ用ボリューム
• フェイルオーバー時にのみ使われる待機系のデータボリューム
• 参照頻度は低いが保全義務のあるデータ(監査ログの保管先など)

実行前の確認

• 命名・タグ・マウントポイントから用途とオーナーを確認する
• アタッチ先インスタンスの利用者に、低頻度アクセスの実態(バッチ・アーカイブ用途か)を確認する
• IaC(Terraform / CloudFormation 等)での参照有無を確認する

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

Safety Tier: high — 削除は復元に手順が要る操作です。バックアップ取得と観察期間を必須とします。

1. スナップショットを取得する
2. アタッチ先インスタンスからデタッチする(削除はまだしない)
3. 2 週間観察し、影響の申告がないことを確認してから削除する

ロールバック: デタッチ段階なら再アタッチ、削除後はスナップショットからのボリューム再作成。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。取得したスナップショットのストレージ課金が新たに発生するため、差し引きで検証します。