セキュリティサービス部 佐竹です。
本日は、2025年11月21日に発表された AWS Compute Optimizer における新機能「Automation」及び「Automation Rules」について解説します。今回のアップデートにより、Compute Optimizer 自体が推奨事項を自動的に適用（実行）することが部分的に可能になりました。
- はじめに
- Compute Optimizer Automation で何が可能になったのか？
- 自動化における重要な注意点
- 実際にマネジメントコンソールから設定を行う
- AWS の本アップデートに関連する情報
- まとめ
はじめに
これまでも本エンジニアブログでは、コスト最適化の要となる AWS Compute Optimizer のアップデートを数多く取り上げてきました。
Savings Plans や Reserved Instances を購入する前の「土台作り」として、リソースの適正化（Rightsizing）は非常に重要です。しかし、推奨事項が出たとしても「数が多すぎて手動で対応しきれない」「開発環境だからコスト削減したいが、調整コストなどの手間がかかる」といった悩みが残ります。「何をやればいいのか」が分かったとしても、「実際にそれが実行できるかは別」ということです。
今回のアップデートは、そうした「作業コスト」の課題を解決するための機能です。
一方で、自動化にはリスクも伴います。本ブログでは、機能の概要だけでなく、運用上の注意点についても掘り下げて解説しつつ、実際の設定も詳細にご紹介します。
Compute Optimizer Automation で何が可能になったのか？
最初にまとめ
AWS Compute Optimizer の「Automation」機能を使用することで、推奨された最適化アクションを定期的なスケジュールで自動実行できるようになりました。
ただし、現時点で対象となるのは Amazon EBS ボリュームのみです。EC2 インスタンスサイズの変更などはまだ対象外である点にご注意ください。
具体的に自動化できるアクションは EBS ボリュームに関する以下の2つです。
- 未アタッチ EBS ボリュームをスナップショット作成後に削除
- 32日以上 EC2 インスタンスに接続されていない「アイドル状態」のボリュームを検知し、スナップショットを取得した上で削除します。
- EBS ボリュームタイプのアップグレード(最新化)
- 旧世代のボリュームタイプ（
gp2,io1）を、より高性能かつ安価な新世代（gp3,io2）へ変更します。
- 旧世代のボリュームタイプ（
現時点で達成可能な自動化のメニューはこの2種のみとなっています。
なおこのうちの後者「Upgrade EBS volume type」は古い世代を最新世代にしてくれるのみであり、同世代内の IOPS やスループットの最適化調整は対象外のようです。つまり、gp3 で IOPS やスループットを下げるような推奨があったとしても、それを Automation Rule で自動化することは現状できません*1。
Automation Rules の仕組み
この機能は「Automation Rules（自動化ルール）」を作成することで動作します。
ルールは以下の要素で構成されます。
- スコープ: アカウント単位、または AWS Organizations による対象アカウントの指定（管理アカウントから制御）
- アクションタイプ: 対象とする推奨事項の種類（現時点では、「削除」、または「アップグレード」の2種）
- 対象: リージョン、タグ（Resource Tags）、ボリュームタイプ等によるフィルタリング（絞り込み）
- スケジュール: 毎日、毎週、毎月の3種の実行スケジュール
例えば、「開発環境（AWS アカウント ID を指定）の未アタッチボリュームは、毎週月曜日に自動的に削除する」といった運用が、エンジニアの手を煩わせることなく実現できるようになります。これは FinOps の観点からも非常に有用な機能と言えるでしょう。
なお個人的には、削除前のスナップショット作成はオプションで外せたらなと思いました。スナップショット自体もコストが発生するためです。
自動化における重要な注意点
次に運用上の注意点を記載します。
お客様環境でこれらを有効化される前に、以下の仕様上の制約とリスクを理解してからご利用ください。これらを知らずに本番環境へ適用すると、思わぬトラブルを招く可能性があります。
1. EBS 変更の「6時間ルール」の制約
Amazon EBS には「ボリュームの変更後、次の変更まで最低6時間待機しなければならない」という仕様があります*2。
ボリュームを変更した後は、少なくとも 6 時間待機し、同じボリュームにさらに変更を加える前に状態が
in-useまたはavailableであることを確認してください。https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-modify-volume.html
Compute Optimizer の自動化によって EBS ボリュームの設定変更が実施された直後に、何らかの理由でさらに設定を変更しようとしたり、元の状態に戻そうとしても、6時間が経過するまではエラーとなり操作できません。
2. ロールバック時の「ボリューム ID」変更
自動化されたアクションには「ロールバック（切り戻し）」機能が用意されていますが、ボリューム削除後のロールバックには注意が必要です。
ボリューム削除の自動化は「スナップショット作成 → ボリューム削除」というプロセスで行われます。これをロールバックする場合、作成されたスナップショットから「新しいボリューム」として復元されます。
つまり、削除前の「ボリューム ID」とは異なる ID で復元されることになります。
CloudFormation などの IaC (Infrastructure as Code) でボリューム ID を管理している場合や、アプリケーション側でボリューム ID をハードコードしている場合、ロールバックしただけではシステムが復旧しません。コードの修正や紐付けの変更が必要になるため、「ボタン一つで元通り」とはいかないケースがあることを認識しておく必要があります。
3. ロールバックの不可能性
前述の通り、ボリューム削除のロールバックは「自動作成されたスナップショット」に依存します。
もし、運用担当者が「不要なスナップショット」としてこの自動作成されたスナップショットを手動で削除してしまった場合、Compute Optimizer からのロールバックは不可能になります。
4. 推定削減額はあくまで「推定」
コンソール上に表示される「Estimated monthly savings（推定月間削減額）」は、あくまでアクション実行時の予測値です。「画面に表示された金額がそのまま削減されるわけではない」という点は、社内報告などの際にご注意ください。
推奨される導入ステップ
以上の注意点を踏まえ、いきなり全環境へ適用するよりかは、特定のアカウントをいくつかピックアップし、小さく検証を開始されるのが良いでしょう。
なお、アカウントを選択する画面で別途説明しますが、AWS Organizations の root や OU を指定できないため、組織での有効化ではアカウント ID を都度指定しなければならない点が少々手間です。
実際にマネジメントコンソールから設定を行う
では実際に、AWS Compute Optimizer Automation を組織単位で有効化してみます。
まずは前提となる事前準備からです。
Automation の有効化
Enable Automation
まずは最初に、Automation の有効化を組織単位で行います。このため、本設定は AWS Organizations における、Compute Optimizer の Delegated Admin で実施します。
「Enable Automation」のボタンを押下したら、以下の画面が表示されます。
ここで「Enable Automation」を押下します。
これで有効化が完了しました。次に組織において本機能を利用するアカウントを追加します。「Add accounts」を押下して進めます。
今回は全アカウントを対象にした後、「Add」で追加します。
「Enable account for Automation」を押下して完了です。なお、この作業により各アカウントにサービスリンクロールが作成されるとのことです。
また一度有効化したら、この画面から該当アカウントを除外し、削除することはできないようでした。
代わりに「Opt-in status for organization member accounts」の画面から「Actions」→「Disallow Organization Rules」により、組織のルールを拒むことが可能となっています。これ（None allowed の設定）が実質「Disable」として機能します。
Account management
施した設定は画面左下の「Account management」から確認が可能です。
タブには「Compute optimizer」と「Automation」とがありますが、これらのうち「Automation」タブが先ほど行った設定を確認する画面です。
「Compute optimizer」のタブと見比べてみると、管理アカウント（今回、管理アカウントが Compute Optimizer の Delegated Admin を兼ねています）が Automation に含まれていないことがわかります。
このことからもわかる通り、マネジメントアカウントは組織レベルの「Automation Rules」の対象外のようです。ですが、「My account rules (後述)」を用いることで、マネジメントアカウントの管理も可能です*3。
Automation rules
Automation rules は前提として「Organization rules」と「My account rules」に分かれます。
前者が「組織レベルで有効化されているルール」であり後者が「そのアカウントでのみ有効化されているルール」です。
では、画面右上の「Create Automation rule」を押下し実際にルールを作成しながら各設定の説明を行っていきます。
Rule scope
最初に、「①Rule type」を選択します。「Organization-level rule」と「Account-level rule」とがあります。
これは、先ほどの「Organization rules」と「My account rules」にそのまま対応します。今回は「Organization-level rule」で設定します。
「Organization-level rule」の場合のみ「②Member accounts」と「③Apply rule」が選択できます。
「②Member accounts」は AWS アカウントを一覧から選択するものです。これは先に記載した通り、OU 等は選択できません。
そして特殊な設定が2種類存在する「③Apply rule」です。これは少々設計で重要になってくる設定項目のため、詳細を説明します。
Compute Optimizer Automation では、条件に合致するルールが複数ある場合、以下の順序で評価し、最も上位のルール1つだけを適用します。上から順にではなく、たった1つだけです。
- 最優先: Organization rules の Before member account rules
- 次点: Member account rules（各メンバーアカウント自身で設定しているルール）
- 最後: Organization rules の After member account rules
つまり「③Apply rule」とは「組織としての強制力を優先するか、各アカウントの自主性（裁量）を優先するか」を定める設定です。
「Before member account rules」は強制的なルールになります。「メンバーアカウント側でどんな設定をしていようと、管理アカウントが決めたこのルールを最優先で適用する」という強い設定となるため、ガバナンスを強制するためにはこちらの機能が最適です。
「After member account rules」は各アカウントルールよりも後の判定になるため、「セーフティネット」や「デフォルト設定」とし機能します。「メンバーアカウント側で独自のルールを設定しているならそれを尊重（優先）する。もし設定していないなら、管理アカウントのこのルールを適用する」という控えめな設定として実装が可能となります。
ということで、今回は「Before member account rules」で進めていきます。
Action types
Action types は、必ず1つは選択する必要がある設定で、先に記載した2種類のアクションから選択が可能です。
- Snapshot and delete unattached EBS volume
Optimize cost while preserving your data by snapshotting and deleting volumes unattached for 32+ days. - Upgrade EBS volume type
Improve performance and optimize cost by upgrading EBS volumes to the latest generation volume type (e.g. gp2 to gp3, io1 to io2).
今回は両方にチェックを入れて進みます。
Rule criteria - optional
Rule criteria はオプション設定です。
Specify criteria to refine which recommended actions will be automatically implemented.（翻訳：自動的に実装される推奨アクションを絞り込むための基準を指定します。）と記載がある通り、この設定で対象を絞り込むことができます。
例えば、特定のリージョンだけに絞り込むことや、タグによって特定のタグが付与されたリソースのみに効果範囲を狭くすることが可能となります。
今回は、この設定は「東京リージョン」のみを指定することにします。
Preview matching actions - optional
Preview matching actions は、設定した Rule criteria 等が、どのリソースに作用するのかをチェックすることが可能な機能です。
対象があると、上画像の通り「どのリソースにどのアクションが実行されるのか？」を前もって確認することができます。
このあたりは、AWS Security Hub CSPM の Automation に似ていますね。
Schedule
Schedule 設定は、実行タイミングの設定です。
Frequency では Daily, Weekly, Monthly が選択可能です。Time window では設定変更が行われる時間の「幅」を設定します。時間の幅は「最低60分」である必要があります。
Daily で行うのが最もコスト最適化効果の高い設定になりますが、本番環境等では土日等に変更を行いたいという場合もあると考えられます。
そのような場合にも柔軟に設定が可能です。
Rule name and description と Rule status
ルールの名称を決定し、記載します。
また「Rule status」を先に設定した状態でルールを作成できます。「Inactive」で作成を行えば、無効化されたルールとして作成されるため（突然の実行の懸念がなく）安全に配慮した Deploy が可能となります。
最後に「Create Automation rule」を押下してルールを作成します。
作成されたルールの確認
一覧に「Rule order」があるように、Order 順にルールが実行されるため、複数ルールを併用する場合は順番についても考慮した設計が必要です。
AWS の本アップデートに関連する情報
リリースニュース
ブログ
AWS 公式ドキュメント (User Guide)
まとめ
本ブログでは AWS Compute Optimizer の新機能「Automation」及び「Automation Rules」について解説しました。
エンジニアが手動で行っていた「ゴミ掃除（未アタッチボリュームの削除）」や「地道なコスト削減（gp3 や io2 への移行）」を自動化できることは、運用の効率化において非常に大きな意味を持ちます。
特に、組織全体で Before member account rules（メンバーアカウントの設定より優先されるルール）を活用し、「開発環境のリソースは強制的に削除する」といったガバナンスを効かせる運用は、無駄なコストを抑止する強力な手段となるでしょう。
ただ「32日間」の期間は、「14日間」や「7日間」など、もう少し短く調整することが可能となる機能に改善されればと感じます。32日間は少々長い気がするのは、私だけでしょうか？
本機能は、まずは開発環境やステージング環境など、本番環境以外のアカウントで検証を行ってみて頂ければ幸いです。
では、またお会いしましょう。
*1:IOPS やスループットの最適化調整は、是非とも早く実装して欲しいです
*2:これは有名な仕様で、Elastic Volumes の制限事項です
*3:ただし、基本的には管理アカウントにはワークロード（リソース）を作成しないことがベストプラクティスとなっています
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
