![[アップデート] AWS Compute Optimizer Automation がリリースされ、自動的にEBSコストが最適化できるようになりました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-5685abd1f86a5c1417c7a873a0c00108/7ba27ac332a6fb85f8d4deec17bd1ee6/aws-thinkbox-sequoia-3?w=3840&fm=webp)
[アップデート] AWS Compute Optimizer Automation がリリースされ、自動的にEBSコストが最適化できるようになりました！
こんにちは、クラウド事業本部 コンサルティング部の荒平(@eiraces)です。
AWS re:Invent 2025ももう少しですね。ここで個人的にかなり熱いアップデートが放り込まれて来ました！
その名も AWS Compute Optimizer Automation です。
(機械翻訳)
本日、Amazon Elastic Block Store (EBS) ボリュームを大規模に最適化できる AWS Compute Optimizer の新機能、自動化ルールをご紹介します。自動化ルールを使用すると、アタッチされていない EBS ボリュームのクリーンアップと最新世代のボリュームタイプへのボリュームのアップグレードのプロセスを効率化できるため、コストを節約し、クラウドインフラストラクチャ全体のパフォーマンスを向上させることができます。
自動化ルールを使用すると、最適化の推奨事項が条件に一致する場合に、定期的なスケジュールで自動的に適用できます。特定の地域をターゲットにする AWS リージョンや、本番環境と開発環境のワークロードを区別するためのリソースタグなどの条件を設定できます。ルールを毎日、毎週、または毎月実行するように設定すると、AWS Compute Optimizer は新しい推奨事項を条件に照らして継続的に評価します。新しいダッシュボードでは、時間の経過に伴う自動化イベントの概要、詳細なステップ履歴の確認、達成された節約額の見積りが可能です。アクションを元に戻す必要がある場合は、同じダッシュボードから直接行うことができます。
未アタッチのEBSボリューム削除やgp2→gp3などのアクションを自動でやってくれる ということのようです。
事情がなくディスクを最新世代に移せていない環境もよく見るので、なかなか筋が良さそうな新機能ですね！多くのリージョンで既に対応しており、日本では東京・大阪どちらも利用できます。
早速有効化してみた
百聞は一見に如かず。まずはやってみるということで、オンボーディングのページから Enable Automation をクリックしてみます。
注意文が出てきました。AWS Compute Optimizer Automation の動作に必要なサービスリンクロールが作られるよ〜とのことなので、 Enable Automation をクリックして進めます。
機能を有効にしてすぐ、レコメンドが表示されました。私が半年以上放置しているEBSですね。
Snapshot and delete unattached EBS volume とのことなので、スナップショットを取って消したほうがいいんじゃない？と仰せのようです。
推奨事項を実行（EBSの削除）
新機能を試すためせっかくなので、 Confirm and apply をクリックしてみます。
確認画面はEBSのID…ではなく confirm でした。
（サービスごとにちょっとずつ違いますよね）
Automation eventsという欄に先程設定したタスクが挿入され、イベントステータスが Ready となりました。
以下のドキュメントにもありますが、10件までのロールバックに対応しています。取り返しのつかないミスが減りそうです。
数分経ってステータスを確認すると、「失敗(The automation did not complete successfully.)」と表示されており、原因不明のエラーになっていました。
他のアカウントでも同様のエラーが出て上手く行かないようで、後日試して追記したいと思います。
自動化ルールを作成する
どういう基準で最適化するのかは組織それぞれあるため、自動化のルールが定義できるようになっています。
ルール内では、以下の項目が設定できます。
- アクションタイプ
- スナップショットを取得し、アタッチされていないEBSを削除する
- EBSボリュームタイプをアップグレードする（gp2→gp3, io1→io2など）
- ルールクライテリア
- 現在のボリューム容量
- 現在のボリュームタイプ
- 最適化金額
- ルックバック期間
- リージョン
- EBSのARN
- タグ
- 再起動が必要かどうか
- スケジュール
- 日次・週次・月次
- タグの適用
- ルールのステータス
- 有効・無効
ルール クライテリアは複数の条件が設定可能で、例えば以下のように「gp2かつ再起動が必要な100GB以上のボリューム」など指定することができます。
クライテリアは一応オプション扱いで設定しないことも可能ですが、指定しない場合はすべてのリージョンのすべてのリソースに対して変更を行うことになりため、最低限絞っておくことをオススメします。
アカウント内のgp2をgp3に変更するルールを設定してみました。
ルールが複数ある場合は優先度を付けられるほか、すぐに使わない場合は非アクティブにすることも可能です。
おわりに
手作業が減らせそう、かつ持続できるコスト最適化機能が利用できるようになり嬉しいですね。
なんとCompute Optimizer Automationは Organizationsにも対応 しており、組織内のEBSコスト最適化の一助になりそうです。
画面を確認すると、管理アカウント側で有効にして、メンバーアカウントを追加する方式でした。
自動化ルールは組織から適用する場合、メンバーアカウントでの自動化ルールの先とするか、後にするかは指定できるようです。
このエントリが誰かの助けになれば幸いです。
それでは、クラウド事業本部 コンサルティング部の荒平がお送りしました！
追記
同時刻で弊部のたかくにさんがこの機能について記事を書いてくれていたので、以下も参照ください。（被った）
