10月1日に、AWS Well-Architected Agentのプレビューが発表されました。
告知にはTrusted AdvisorとWell-Architected Toolの次世代版と書かれています。普段Trusted Advisorの指摘を見て、対応するかどうかを判断している立場としては、何が変わるのかが気になるところです。
先に書いておくと、この記事は実際に動かす前に、前提条件とTrusted Advisorとの関係をドキュメントで整理したメモです。読んでいるうちに、自分の思い込みと違う点がいくつか出てきました。
AWS Well-Architected Agent is now available in preview – https://aws.amazon.com/about-aws/whats-new/2026/10/aws-well-architected-agent/
AWS Well-Architected Agentとは？
ざっくり言うと、AIを使ったクラウド最適化のサービスです。
コスト、セキュリティ、レジリエンス、パフォーマンスの4つの柱で環境を継続的に分析して、優先度付きの推奨事項を出してくれます。
推奨事項が出る単位はこの3つです。
- リソース
- アプリケーション（ベータ）
- アーキテクチャ
アプリケーション単位はまだベータ扱いでした。
What is AWS Well-Architected Agent (preview)? – https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent.html
まずは前提条件を確認
サポートプランはBusiness+以上が必要
最初に引っかかったのがサポートプランです。ドキュメントでは、Business+以上のプランが必要と書かれています。
| サポートプラン | 利用可否 | プロファイル上限 | プロファイルあたりのアプリケーション上限 |
|---|---|---|---|
| Developer | 不可 | – | – |
| Business | 不可 | – | – |
| Business+ | 可 | 2 | 7 |
| Enterprise On-Ramp | 可 | 10 | 30 |
| Enterprise Support | 可 | 10 | 30 |
| Unified Operations | 可 | 10 | 30 |
AWS Well-Architected Agent Quotas and limits – https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-quotas.html
告知文には「AWS Support planが必要」としか書かれていなかったので、最初は有償プランなら使えるものだと思っていました。実際にはBusinessは対象外です。
名前が似ているので、契約しているプランがBusinessなのかBusiness+なのかは確認しておいた方がいいです。
プロファイルは米国リージョンに置かれる
もう一つ、プロファイルを置けるリージョンは米国の3つに限られます。
- バージニア北部
- オハイオ
- オレゴン
スキャン対象は全商用リージョンなので、東京リージョンのリソースも分析できます。ただ、プロファイルとそのデータは米国リージョンに置かれます。社内のデータ所在のルールによっては、ここで相談が必要になるかもしれません。
Trusted Advisorとの関係
一番知りたかったのはここです。
ドキュメントのRelated servicesを読むと、Trusted Advisorを置き換えるというより、その指摘を入力として取り込む位置付けでした。
Related services – https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-related-services.html
Trusted Advisorの他にも、次のサービスのシグナルを取り込むそうです。
- Compute Optimizer（EC2、Lambda、RDSの適正サイズ）
- Security Hub CSPM
- Resilience Hub
- Cost Optimization Hub
- Cost Explorer
その上で、プロファイルに登録したビジネス目標に沿って優先度を付けて、他の柱への影響やトレードオフも添えて出す、という説明です。
自分の理解ではこんな感じです。
- Trusted Advisor：個々のチェック結果を出す
- Well-Architected Agent：それらを束ねて、何から手を付けるかを提案する
なお、プロファイルを作らなくてもTrusted Advisor由来のベースラインの推奨事項は見られる、とGetting startedに書かれていました。
SSMランブックは自動生成されるわけではなかった
ここは想定と違いました。
テーマを考えた時点では、推奨事項ごとにSSMランブックやCLIスクリプトが自動生成されるものだと思っていました。
Implement recommendationsを読むと、修正の方法は推奨事項の出どころによって2つに分かれています。
Implement recommendations – https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-implement-rec.html
| 推奨事項の出どころ | 修正方法 | エージェントによる実行 |
|---|---|---|
| Trusted Advisorのチェック由来 | 用意済みのSSMランブック | 同意すればワンクリックで実行。定期実行も可 |
| エージェントのAIが生成したもの | ガイド付きの手順（コンソール、CLI、SDK） | 実行しない。利用者が確認して自分で実行する |
SSMランブックは生成されるのではなく、Trusted Advisorのチェックに対応するものが最初から用意されている、という扱いです。
一方で、AIが生成する推奨事項は、CLIコマンドやboto3のコードを含む手順書（SOP）として出てきます。エージェントがそれを代わりに実行することはありません。
手順書は、対象リソースの実際の名前やARNを使ってフェーズごとに分かれるそうです。たとえば対象のS3バケットが4つあれば、バケットごとにフェーズが分かれます。
ダウンロードもできるので、変更管理のチケットに添付する使い方が想定されているようです。日本の現場では変更作業の前に手順書を作ってレビューを通すことが多いので、その下書きとして使えるかどうかは、実物を見て判断したいところです。
動かす前に気になった設定まわり
Getting startedを読んで、つまずきそうだと感じた点をメモしておきます。
アプリケーションコンテキストがないと定期生成が動かない
プロファイルを作っただけでは、プロファイルが無効扱いになります。アプリケーションコンテキストを1つ以上登録しないと、定期の推奨事項も生成されません。
ドキュメントでは Important として書かれていますが、手順の途中にあるので見落としそうです。
分析対象アカウントのアクセスロールは手動で作る
実行ロール（ExecutionRoleForWellArchitectedAgent）はコンソールから作れます。一方で、各ワークロードアカウント側のアクセスロールは、IAMコンソールで自分で作る必要があります。
信頼ポリシーに書く実行ロールのARNは、作り方によって service-role/ のパスが付くかどうかが変わる、という注意書きもありました。AssumeRoleの失敗で時間を使いそうな箇所です。
Cost Explorerは一度有効にすると無効にできない
Cost Explorerを有効にすると、実際のコストデータを使えます。無効のままだと公開価格からの推定になります。
リソース単位の日次データには別途料金がかかるので、検証アカウントで有効にするかは少し迷いました。
推奨事項の生成は週1回
最初の推奨事項は、セットアップ後24時間以内に出るそうです。
その後は週1回の更新で、1回の生成で出る推奨事項は最大30件です。定期生成には7日のクールダウンもあるので、設定を変えてすぐ結果を見る、という試し方はしづらそうです。
所感
ドキュメントを読んだ範囲では、Trusted Advisorが不要になるというより、その上に優先度付けと手順書作りが乗るサービスだと感じました。
SSMランブックが自動生成されると思い込んでいたので、AIが生成した手順は自分で確認して実行する前提だと分かったのは収穫でした。
一方で、Business+以上という条件があるので、個人の検証アカウントで気軽に試せるサービスではなさそうです。
次は実際に推奨事項を出して、Trusted Advisorの指摘と1件ずつ突き合わせてみたいと思います。あわせて、IaCテンプレートを渡すアーキテクチャレビューのほうも試してみたいです。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
