2026.09.29 AWS

Trusted Advisorの自動化｜APIとEventBridgeで推奨事項を通知する実装

Q: list-recommendationsで取れない手動更新はどうすればよいですか？

AWS Support APIの refresh-trusted-advisor-check を --region us-east-1 付きで呼び、 describe-trusted-advisor-check-refresh-statuses で完了を待ちます。自動で更新されるチェックのIDを渡すと InvalidParameterValue が返るので、エラーになったチェックは更新対象から外してください。チェック名は変わることがあるため、コードではIDで指定するのが公式の推奨です。

Trusted Advisorの自動化｜APIとEventBridgeで推奨事項を通知する実装

Trusted Advisorの推奨事項をコンソールで眺める運用は、アカウントが2つ3つを超えたあたりで回らなくなります。そこでAPIから取りに行き、状態が悪化したら通知する仕組みを組むことになりますが、手を付けて最初に当たるのは、新旧2系統のAPI、番号だけが返ってくる詳細データ、バージニア北部にしか届かないイベントという3つの壁です。この記事では、AWS CLIとboto3で推奨事項と対象リソースを取得し、EventBridgeで通知するまでを、公式リファレンスの記述に沿ってコード付きで組み立てます。Trusted Advisorそのものの定義やチェックの内訳、料金はAWS Trusted Advisorとはの解説記事にまとめてあるため、ここでは扱いません。

まとめ：Trusted Advisorの自動化で先に決める取得経路と通知の受け口

結論を先に置きます。新しく書くコードは、2022-09-15版のTrusted Advisor API（CLIではaws trustedadvisor、boto3ではtrustedadvisorクライアント）で組んでください。旧来のAWS Support API経由のdescribe-trusted-advisor-*系は動き続けていますが、チェックIDの扱いやエンドポイントの制約が多く、新規に選ぶ理由は手動更新（refresh）くらいしか残っていません。

次に、通知はEventBridgeとAPIポーリングの二段構えにします。EventBridgeのイベントはus-east-1にしか来ず、しかも配信はベストエフォートです。イベントを速報に、日次のAPI取得を正本にする分担がいちばん事故が少ない構成です。

最後に前提条件。APIもEventBridgeルールも、Business Support+、Enterprise Support、Unified Operationsのいずれかに加入したアカウントでないと使えません。Basic Supportのままなら、この記事の実装は動きません。プランの料金とBasicで見える範囲は無料で使える範囲とサポートプラン別の料金を整理した記事で確認してください。

Trusted Advisor APIとSupport APIの違いと新規実装で選ぶ側

Trusted Advisorをプログラムから触る手段は2つあります。名前が似ているので、最初にどちらのドキュメントを読んでいるかを確かめる癖をつけてください。

Trusted Advisor APIが返す推奨事項とチェックの関係

Trusted Advisor APIの開始ガイドによると、推奨事項の参照に使う操作はListChecks、ListRecommendations、GetRecommendation、ListRecommendationResourcesの4つです。リソースを結果から外すBatchUpdateRecommendationResourceExclusionもここに含まれます。

押さえるべき構造は「チェック」と「推奨事項」の分離です。チェックは評価ルールの定義で、ARNはarn:aws:trustedadvisor:::check/1iG5NDGVreのようにアカウントIDを持ちません。推奨事項はそのチェックを自分のアカウントに当てた結果で、ARNにアカウントIDが入ります。ListRecommendationsのリファレンスは、このAPIがグローバルな推奨事項を返すため、リージョンごとに呼び出す必要がないと明記しています。旧APIとの大きな違いがここです。

Support APIのdescribe系が今も残る理由とus-east-1固定の制約

旧来の経路はAWS Support APIの一部として提供されています。RefreshTrustedAdvisorCheckのリファレンスには、Trusted Advisorの操作を呼ぶには米国東部（バージニア北部）のエンドポイントを使う必要があり、米国西部（オレゴン）と欧州（アイルランド）のエンドポイントは対応していないと書かれています。--regionを付け忘れた東京リージョン既定のCLIから呼ぶと失敗する、という詰まり方はこれが原因です。

それでも旧APIを残すのは、チェックの手動更新が新APIに無いからです。更新を依頼して完了を待つ流れはSupport APIでTrusted Advisorを使う公式ガイドに載っており、状態はnone・enqueued・processing・success・abandonedの5つ、ポーリング間隔は10秒が推奨です。自動で更新されるチェックのIDを渡すとInvalidParameterValueが返ります。

新旧どちらのAPIにも必要なサポートプランと未加入時に返る例外の違い

どちらのAPIも、Business Support+、Enterprise Support、Unified Operationsのいずれかが条件です。違うのは未加入時の返り方。新しいTrusted Advisor APIはAccessDeniedException（HTTP 403）を返し、Support APIはSubscriptionRequiredExceptionを返します。

403はIAM権限不足と同じコードなので、ポリシーを何度見直しても直らない、という時間の溶かし方をしがちです。IAMを疑う前に、請求コンソールで対象アカウントのサポートプランを確認してください。組織単位のListOrganizationRecommendations系はさらにTrusted Advisor Priorityの有効化が要り、無効なら同じく拒否されます。

AWS CLIでlist-recommendationsを実行して推奨事項を一覧する手順

まずはCLIで1回叩いて、返ってくる形を目で確かめます。スクリプト化はそのあとで十分です。

IAMポリシーに付けるtrustedadvisorアクションと読み取り専用の範囲

参照だけなら、付けるアクションは次の4つで足ります。書き込み系（除外の更新やライフサイクル変更）を含めないことで、通知用のLambdaに誤って結果を書き換えさせる事故を防げます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TrustedAdvisorReadOnly",
      "Effect": "Allow",
      "Action": [
        "trustedadvisor:ListChecks",
        "trustedadvisor:ListRecommendations",
        "trustedadvisor:GetRecommendation",
        "trustedadvisor:ListRecommendationResources"
      ],
      "Resource": "*"
    }
  ]
}

Support APIの手動更新も使うなら、support:RefreshTrustedAdvisorCheckなどSupport側のアクションが別に必要です。サービスのプレフィックスがtrustedadvisorとsupportに分かれている点が、新旧APIの違いをそのまま映しています。

–pillarと–statusで絞り込みerrorの推奨事項だけを数える

list-recommendationsのCLIリファレンス（2026年9月29日時点でAWS CLI 2.37系の表記）では、--pillarにcost_optimizing・performance・security・service_limits・fault_tolerance・operational_excellenceの6値、--statusにok・warning・errorの3値を指定できます。日本語の名前で受け取るなら--language jaです。

$ aws trustedadvisor list-recommendations \
  --status error \
  --language ja \
  --region us-east-1 \
  --query "recommendationSummaries[].[pillars[0],name,resourcesAggregates.errorCount]" \
  --output table

CLIはページネーションを自動で処理するため、件数が多くても全件が返ります。resourcesAggregatesにはerror・warning・ok・excludedの件数が入り、どの推奨事項から手を付けるかをここで決められます。セキュリティの柱だけを見たい朝会用なら--pillar securityを足すだけです。

list-recommendation-resourcesで対象リソースを引く

一覧で見つけた推奨事項のARNを渡すと、指摘されたリソースが1件ずつ返ります。ListRecommendationResourcesのリファレンスでは1ページの上限が5,000件で、推奨事項一覧の200件とは桁が違います。

$ aws trustedadvisor list-recommendation-resources \
  --recommendation-identifier "arn:aws:trustedadvisor::123456789012:recommendation/55fa4d2e-bbb7-491a-833b-5773e9589578" \
  --status error \
  --region us-east-1 \
  --query "recommendationResourceSummaries[].[regionCode,awsResourceId,exclusionStatus]" \
  --output text

結果のregionCodeで、東京と大阪とバージニアに散ったリソースを1回の呼び出しで拾えます。exclusionStatusがexcludedの行は、意図的に除外したリソースです。検証用の公開バケットのように指摘を承知で残すものは除外しておかないと、通知が毎回同じ行で埋まります。

boto3で全推奨事項とリソースを集計してCSVに出すPython実装

CLIで形を確かめたら、日次で回すスクリプトに落とします。ここで効いてくるのが、リソースの詳細が番号キーで返る仕様です。

metadataが番号キーで返る仕様とListChecksで列名を引く方法

リソースのmetadataは{"0": "14", "1": "123.12", "2": "webcms-dev-01"}のような形で、何の値なのかが書かれていません。列名はListChecksのリファレンスが示すとおり、チェック側のmetadataに{"0": "Region", "1": "Security Group Name"}のような見出しとして入っています。

つまり推奨事項のcheckArnをキーにチェックの見出しを引き、番号同士を突き合わせれば表になります。列の並びはチェックごとに違い、RDSのリザーブドインスタンスのチェックでは16列あります。番号の位置を決め打ちしたコードは、チェックが改訂された時点で黙って別の値を読み始めるので、必ず見出しから解決してください。

nextTokenを回して全件を取るboto3のコードと上限値の扱い

次のスクリプトは、errorとwarningの推奨事項について、対象リソースと列名付きの詳細をCSVで標準出力に書きます。引数の名前はboto3のlist_recommendationsリファレンスに合わせています。

import csv
import sys

import boto3

# Trusted Advisor APIはグローバル。サンプルではus-east-1を明示する
ta = boto3.client("trustedadvisor", region_name="us-east-1")


def pages(method, key, **kwargs):
    """nextTokenが返らなくなるまで呼び続けて要素を順に返す"""
    while True:
        resp = method(**kwargs)
        yield from resp.get(key, [])
        token = resp.get("nextToken")
        if not token:
            break
        kwargs["nextToken"] = token


# チェックARN → 列見出し（{"0": "Region", ...}）
headings = {
    c["arn"]: c["metadata"]
    for c in pages(ta.list_checks, "checkSummaries", language="ja", maxResults=200)
}

writer = csv.writer(sys.stdout)
writer.writerow(["pillar", "recommendation", "status", "region", "resource", "detail"])

for status in ("error", "warning"):
    for rec in pages(ta.list_recommendations, "recommendationSummaries",
                     status=status, language="ja", maxResults=200):
        cols = headings.get(rec.get("checkArn"), {})
        for res in pages(ta.list_recommendation_resources, "recommendationResourceSummaries",
                         recommendationIdentifier=rec["arn"], maxResults=1000):
            if res["status"] == "ok" or res.get("exclusionStatus") == "excluded":
                continue
            meta = res.get("metadata", {})
            detail = "; ".join(
                f"{cols.get(k, k)}={v}" for k, v in sorted(meta.items(), key=lambda kv: int(kv[0]))
            )
            writer.writerow([",".join(rec.get("pillars", [])), rec["name"], res["status"],
                             res.get("regionCode", ""), res.get("awsResourceId", ""), detail])

maxResultsはListChecksとListRecommendationsが1〜200、ListRecommendationResourcesが1〜5,000の範囲です。範囲外を渡すとValidationExceptionになります。呼び出しが多い組織ではThrottlingException（HTTP 429）も返り得るため、本番ではboto3のConfig(retries={"mode": "adaptive"})を渡してリトライを任せてください。

checkArnを持たない推奨事項もある点に注意が要ります。headings.get()で空の辞書に落としているのはそのためで、列名が引けない行は番号のまま出力されます。

sourceの値で分かる推奨事項の出どころと他サービスとの重複の見分け方

推奨事項のsourceにはta_checkのほか、compute_optimizer・security_hub・aws_config・cost_explorer・well_architected・cost_optimization_hubなど14種類の値が入ります。Trusted Advisorの一覧には、他サービスが算出した結果も混ざっているということです。

通知を組むときにここを見落とすと、同じEBSボリュームの指摘がCompute Optimizer側とTrusted Advisor側の両方から届きます。すでにCompute OptimizerのレコメンデーションやSecurity Hubの検出結果を別経路で通知しているなら、スクリプトにsource="ta_check"を足してTrusted Advisor固有の指摘だけに絞るほうが、受け手の負担は小さくなります。

EventBridgeでチェックの状態変化を通知するルールの作成手順

日次のスクリプトだけでは、夕方に開いたセキュリティグループに翌朝まで気づけません。状態変化を即時に拾う側をEventBridgeで足します。

Check Item Refresh Notificationのイベントパターン

EventBridgeのTrusted Advisorイベント一覧によると、sourceはaws.trustedadvisorで、直接届くイベントはCheck Item Refresh Notification、Pursuit Weekly Digest、Pursuit Daily Digestの3種類です。detail-typeを指定しないと集計系のダイジェストまで届くので、状態変化だけを拾うパターンに絞ります。

{
  "source": ["aws.trustedadvisor"],
  "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
  "detail": {
    "status": ["ERROR", "WARN"]
  }
}

ここで大文字小文字が変わる点に注意してください。EventBridge連携の公式手順が挙げるイベント側の状態はERROR・WARN・OK・INFOの4つで、APIのerror・warning・okとは綴りも数も違います。APIの値をそのままパターンに書くと、何も一致しません。特定のチェックだけに絞るなら、公式サンプル集のTrusted Advisor Toolsのように"check-name": ["Amazon EBS Snapshots"]をdetailに足します。

バージニア北部にルールを置き東京のイベントバスへ転送する構成

同じ公式手順には、Trusted Advisorはグローバルサービスのため、すべてのイベントが米国東部（バージニア北部）のEventBridgeに送られるとあります。東京リージョンにルールを作っても一致は永久に起きません。通知の処理系を東京にまとめているなら、us-east-1にルールを置き、東京のイベントバスへ転送します。

$ aws events put-rule \
  --name ta-error-warn \
  --region us-east-1 \
  --event-pattern file://ta-pattern.json

$ aws events put-targets \
  --rule ta-error-warn \
  --region us-east-1 \
  --targets "Id"="tokyo-bus","Arn"="arn:aws:events:ap-northeast-1:123456789012:event-bus/default","RoleArn"="arn:aws:iam::123456789012:role/eventbridge-forward-to-tokyo"

別リージョンのイベントバスをターゲットにするときは、events:PutEventsを許可したIAMロールの指定が要ります。転送先の東京側では、同じパターンでもう1本ルールを作ってLambdaやSNSにつなぎます。リージョン間の転送は通常のイベント配信と課金の扱いが異なるため、件数の見積もりはAmazon EventBridgeの料金と課金の落とし穴をまとめた記事で確認してください。

ベストエフォート配信を補う日次のAPIポーリングとの二段構え

公式手順は、Trusted Advisorのイベント配信がベストエフォートで、必ずEventBridgeに届くとは限らないとも明記しています。EventBridgeだけで監視を完結させると、届かなかった1件が誰にも見られないまま残ります。

そこで役割を分けます。EventBridgeは「速報」、前章のboto3スクリプトを毎朝EventBridge Schedulerで回す日次レポートは「正本」です。日次レポートのlastUpdatedAtが前回実行より新しい行だけを差分として通知すれば、イベントの取りこぼしを翌朝までに回収できます。AWSの障害やメンテナンス通知も同じ二段構えで組むなら、AWS Health Dashboardの通知自動化とAPI実装の記事がリージョン配置まで同じ考え方で書いています。

Trusted Advisor自動化を自前で組むべき条件と見送る場面

ここまでの実装は半日あれば動きます。ただ、動くことと組むべきかどうかは別の話です。

Basic Supportのまま月1回の目視で済ませてよい範囲

アカウントが1つか2つで、見たいのがサービスクォータとセキュリティの一部チェックだけなら、自動化は組みません。APIとEventBridgeルールのためにBusiness Support+へ上げると、アカウントあたり最低29USD/月の固定費が乗ります（AWS Support Plansの公式ページ、2026年9月29日確認）。月1回コンソールを開いて手動更新する運用で足ります。

逆に、すでにBusiness Support+以上に入っているなら話は逆転します。同ページはBusiness Support+で500を超えるチェックが使えると記載しており、API利用の追加料金もありません。払っている範囲の機能を眺めるだけで終わらせるのは損で、この場合は日次レポートまでは作ってください。

自動修復までつなぐTrusted Advisor Toolsを本番で使わない理由

公式のTrusted Advisor Toolsには、低使用率のEC2インスタンスを停止する、アクセスキーの露出を検知してキーを削除する、といったLambdaのサンプルが並びます。ライセンスはApache 2.0で、動かすこと自体は簡単です。

本番環境では、停止や削除まで自動でつなぐ使い方は採りません。低使用率の判定は過去の利用率から機械的に出るため、月末だけ動くバッチサーバーや待機系のインスタンスも対象に入ります。自動で止めてよいのは、タグで対象を明示した開発環境だけに限ってください。本番は通知で止めて、人が判断する経路を残します。露出したアクセスキーの無効化のように、放置の損害が誤停止の損害を明らかに上回るものだけが例外です。

通知の受け手がいない組織で通知の自動化だけを先に作ってしまう失敗

もう1つの失敗は、通知を誰が受けるかを決めずに仕組みだけ作るパターンです。warningまで全件流すと、初週で数十件がSlackに並び、2週目には誰も読まなくなります。最初はerrorかつセキュリティとサービスクォータの柱だけを流し、warningは日次レポートに回すところから始めてください。

アカウントが10を超える、指摘を翌営業日までに直す体制が社内に無い、の両方に当てはまるなら、足りないのはコードではなく受け手の体制です。監視と一次対応をどこまで外に出すかの判断材料はAWS運用保守の委託範囲と費用の記事にまとめました。通知の設計から受け手の運用まで一緒に組み立てたい場合は、インフラ構築（AWS・Google Cloud・Azure）でご相談を受けています。

よくある質問

Trusted Advisorの自動化を組むときによく出る疑問に答えます。

Trusted Advisor APIはBasic Supportでも使えますか？

使えません。公式ドキュメントは、Business Support+、Enterprise Support、Unified Operationsのいずれかに加入していないアカウントから呼ぶとAccess Deniedの例外が返ると明記しています。EventBridgeでTrusted Advisorのルールを作る場合も同じ条件です。Basic Supportで見られるのはコンソール上のサービスクォータと一部のセキュリティチェックで、自動更新も付きません。

Trusted AdvisorのAPIはどのリージョンで呼べばよいですか？

新しいTrusted Advisor APIはグローバルな推奨事項を返すため、リージョンごとに呼び分ける必要はありません。本記事のコードではus-east-1を明示しています。旧来のAWS Support API経由の操作は米国東部（バージニア北部）のエンドポイントが必須で、オレゴンとアイルランドは非対応です。EventBridgeのイベントもバージニア北部にしか届きません。

list-recommendationsで取れない手動更新はどうすればよいですか？

AWS Support APIのrefresh-trusted-advisor-checkを--region us-east-1付きで呼び、describe-trusted-advisor-check-refresh-statusesで完了を待ちます。自動で更新されるチェックのIDを渡すとInvalidParameterValueが返るので、エラーになったチェックは更新対象から外してください。チェック名は変わることがあるため、コードではIDで指定するのが公式の推奨です。

EventBridgeのルールを作ったのに通知が来ないのはなぜですか？

確認する順番は3つです。第1にルールのリージョンで、us-east-1以外では一致しません。第2にパターンの状態値で、イベント側はERRORやWARNの大文字表記です。APIのerrorやwarningを書いていないかを見てください。第3に配信の性質で、Trusted Advisorのイベントはベストエフォートのため、日次のAPI取得で取りこぼしを回収する設計にしておきます。

複数アカウントの推奨事項を1回でまとめて取得できますか？

組織単位のListOrganizationRecommendations系はTrusted Advisor Priorityが有効な場合だけ動き、Priorityの利用にはEnterprise SupportかUnified Operationsが要ります。Business Support+の組織では、各メンバーアカウントに読み取り専用のロールを置き、管理用アカウントからAssumeRoleで順に呼んで結果を1つのCSVにまとめる方法が現実的です。