Compute Optimizerにアイドル判定されたEBSボリューム、全部削除していいのか確認してみた
こんにちは！クラウド事業本部のおつまみです。
AWSのコスト最適化に取り組んでいますか？
今回、AWS Compute Optimizerの「アイドル状態のリソース」にEBSボリュームが大量に表示されたお客様から「これ全部削除していいですか？」というご相談を受けました。
実はアタッチされているのにアイドル判定されているものが多数混在しており、そのまま削除すると大変なことになります。
判定ロジックを正しく理解して、安全に削除候補を絞り込む方法をご紹介します。
3行まとめ
- Compute OptimizerのアイドルEBS判定は「アタッチ有無」ではなく「過去14日間のI/Oがゼロかどうか」が基準
- 停止中インスタンスにアタッチされているEBSはI/Oが発生しないためアイドル判定される
- アイドル判定 ≠ 即削除OK。削除前にアタッチ状態・I/O履歴・スナップショット取得の3つを確認する
Compute Optimizerのアイドル状態のリソースとは
AWS Compute Optimizerは、EC2・EBS・Lambda・ECS・Auto Scalingなどのリソース使用状況をCloudWatchメトリクスから分析し、最適なサイズやコスト削減の推奨事項を提示してくれるサービスです。
その機能の一つが「アイドル状態のリソース」です。過去の使用実績から「ほぼ使われていない」と判断したリソースを一覧表示し、削除によるコスト削減を提案してくれます。
アイドル判定のロジック
Compute OptimizerがEBSボリュームを「アイドル」と判定する条件は以下のとおりです。
- ルックバック期間（過去14日間）において、当該ボリュームへの読み取り・書き込みのI/Oがゼロ、またはほぼゼロであること
重要なのが、EC2インスタンスにアタッチされているかどうかは判定に関係ないという点です。
つまり、インスタンスにアタッチされていても実際にI/Oが発生していないボリュームは「アイドル」と判定されます。
「アタッチ済み＝使用中」は間違い
「EC2にアタッチされているならデータが読み書きされているはず」と考えがちですが、以下のようなケースではアタッチされているにもかかわらずアイドル判定されます。
停止中インスタンスにアタッチされているEBS
インスタンスが停止（stopped）状態ではI/Oが発生しません。そのため、停止中のインスタンスにアタッチされているEBSはすべてアイドル判定されます。
インスタンスが「使っていないから停止している」のか「業務上の理由で一時的に停止しているだけ」なのかは、Compute Optimizerには判断できません。
起動中インスタンスにアタッチされているが使っていないEBS
インスタンスが起動中であっても、対象ボリュームへのアクセスが過去14日間なかった場合はアイドル判定されます。例えば、以下のようなケースです。
- OSディスク（
/dev/sda1）とは別にアタッチしているデータディスクで、最近アクセスがないもの - バックアップ取得後にデタッチし忘れたボリューム
- 業務上必要だが利用頻度が低いアーカイブ用データを保持しているボリューム
ルックバック期間（デフォルト14日間）のたまたまアクセスがなかったもの
月次・週次などで定期的にアクセスするボリュームも、直近14日間にアクセスがなければアイドル判定されます。
アイドル一覧の中身を確認してみると
実際にお客様の環境でCompute Optimizerのアイドル一覧を確認したところ、表示されているボリュームのほとんどがインスタンスにアタッチ済みでした。
一方、本当に「デタッチ済み（ステータスが使用可能）」のボリュームはごくわずかでした。
このようにアイドル一覧の全件が削除候補ではなく、まず絞り込みが必要です。
削除候補を安全に絞り込む方法
ステップ1：まずデタッチ済みボリュームに絞る
最もシンプルな削除候補は「いずれのインスタンスにもアタッチされていないEBS（ステータス：使用可能）」です。
EC2コンソールの「ボリューム」画面で「状態」フィルターを「available」に設定すると一覧表示できます。
ステップ2：対象ボリュームがどのインスタンスに紐づいているか確認する
デタッチ済みではないボリュームを削除検討する場合は、そのボリュームがどのインスタンスに紐づいているかを確認します。
EC2コンソールの「ボリューム」画面から対象ボリュームを選択すると、「アタッチされたインスタンス」でインスタンスIDと紐づき状況を確認できます。
ステップ3：CloudWatchで最後にI/Oがあった時期を確認する
Compute Optimizerのルックバック期間は14日間ですが、CloudWatchでメトリクス期間を延ばすことで「最後にアクセスがあったのはいつか」を確認できます。
確認すべきメトリクスは以下のとおりです。
VolumeReadOps：読み取り操作数VolumeWriteOps：書き込み操作数
CloudWatchコンソールで対象ボリュームのIDを指定してグラフを表示し、最後にI/Oが発生した時点を確認してください。
ステップ4：削除前に必ずスナップショットを取得する
「使われていない」と判断して削除する場合でも、削除前に必ずスナップショットを取得することを強く推奨します。
万が一誤って削除してしまっても、スナップショットから復元できます。スナップショットのストレージコストは元のEBSに比べて大幅に安いため、コスト削減効果を維持しながら安全策を確保できます。
まとめ
Compute OptimizerのアイドルEBS判定のポイントをおさらいします。
- 判定基準は「過去14日間のI/Oがゼロ（またはほぼゼロ）」であり、アタッチ有無は関係ない
- 停止中インスタンスにアタッチされているEBSはI/Oが発生しないためアイドル判定される
- アイドル一覧にはアタッチ済みのボリュームが多数含まれており、全件が削除候補ではない
- 削除候補の絞り込みはまず「デタッチ済み（使用可能）」のボリュームから始める
- 削除前には必ずスナップショットを取得する
適切に整理することで月数万円規模のコスト削減につながるケースもありますが、誤削除のリスクと隣り合わせです。焦らず確認プロセスを踏むことが重要です。
最後までお読みいただきありがとうございました。
どなたかのお役に立てれば幸いです。
以上、おつまみ（@AWS11077）でした！
