Cloud Service
AWS Trusted Advisor
コスト・セキュリティ・耐障害性などをベストプラクティスに照らして自動点検し改善を助言するサービス。
- 1.アカウント全体を自動スキャンし、ベストプラクティスからの逸脱を検出する。
- 2.コスト最適化・セキュリティ・耐障害性・性能・サービス上限の観点で助言する。
- 3.利用できるチェックの範囲はサポートプランに依存する。
解決する課題
AWS の利用が広がると、使われていないリソースで無駄なコストが発生したり、公開してはいけないポートが開いていたり、単一 AZ 構成で冗長化が不足したりといった「設計や設定のミス」が積み重なります。これらを人手で漏れなく点検するのは現実的ではありません。
Trusted Advisor はアカウントを自動でスキャンし、次のような価値を提供します。
- ベストプラクティスからの逸脱を自動で検出し、一覧で示す
- 各チェックを「問題なし」「注意」「要対応」のように色で重大度を区別する
- 推定される節約額や、影響を受けるリソースの具体的なリストを提示する
主要概念と用語
- チェック: 個々の点検項目。各チェックは特定のベストプラクティスに対応する
- カテゴリ: チェックの分類。コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限(クォータ)の観点に分かれる
- ステータス(色): 各チェック結果の重大度。緑(問題なし)、黄(推奨事項・注意)、赤(要対応)で示される
- 推奨アクション: 検出された問題に対する具体的な改善案
- 推定節約額: コスト最適化チェックで提示される、改善した場合に見込める節約の目安
- サポートプラン: 利用できるチェックの範囲を決める契約区分。上位プランほど多くのチェックが使える
仕様・制限・クォータ
- 評価はリージョンをまたいでアカウント全体を対象とする。明示的にインフラを起動する必要はない
- 利用できるチェックの数や範囲はサポートプランに依存する。基本的なプランでは一部のチェックに限定され、上位プランで全カテゴリのフルセットが使える
- 結果は定期的に自動更新されるほか、コンソールから手動での再実行も可能
- 単独で課金される独立サービスではなく、サポートプランに紐づく機能として提供される
赤や黄のチェックがあっても、すべてが緊急とは限りません。重大度と自社の要件を照らし合わせ、優先順位をつけて対応するのが実務的です。
内部の仕組み
Trusted Advisor は、利用者がアタッチした IAM 権限の範囲で各リソースの構成情報を読み取り、AWS が定義したベストプラクティスのルールと突き合わせて評価します。利用者がエージェントをインストールしたり、追加のインフラを構築したりする必要はありません。
- 各チェックは独立したルールとして実行され、対象リソースのメタデータや設定を参照する
- 評価結果はチェックごとにステータスと影響リソースの一覧として保持される
- 一部の運用情報は他の AWS サービス(請求情報やサービスのクォータ情報など)と連携して取得される
設計パターン / ベストプラクティス
- 定期レビューの仕組み化: 月次などの運用サイクルでカテゴリ別に結果を確認し、対応状況を記録する
- 組織横断での集約: 複数アカウントを運用する場合は、組織管理の仕組みと組み合わせてアカウント全体の状況を俯瞰する
- 他ツールとの役割分担: 詳細なセキュリティ評価や構成準拠の継続監視は専用サービスに任せ、Trusted Advisor は横断的な気づきの起点として使う
- 自動通知: 結果の変化をイベントとして拾い、通知や起票につなげて放置を防ぐ
運用・監視
- コンソールのダッシュボードでカテゴリ別のサマリと、各チェックの詳細を確認できる
- チェック結果や使用状況の変化をイベントとして検知し、通知サービスや自動化につなげられる
- API や CLI から結果を取得できるため、定期的なレポート生成や独自の運用ダッシュボードへの取り込みが可能
- 対応が完了したら再実行し、ステータスが改善したことを確認する運用が望ましい
コスト
Trusted Advisor は単体で時間課金される独立サービスではなく、契約しているサポートプランの一部として提供されます。利用できるチェックの範囲がプランによって変わる点が重要です。
- 基本的なプランでは、セキュリティやサービスの制限など一部のコアなチェックに限定される
- 上位のサポートプランでは、全カテゴリにわたる多数のチェックを利用できる
- コスト最適化カテゴリのチェックは、未使用リソースや過剰なプロビジョニングの発見を通じて、結果的に支出削減に寄与する
「コスト最適化や耐障害性のチェックが見当たらない」場合、機能の不具合ではなくサポートプランの範囲外であることが多いです。必要なチェックがプランに含まれるかをまず確認してください。
セキュリティ
- 公開状態のセキュリティグループのポートや、過剰に開放された権限など、典型的な設定リスクを検出する助けになる
- Trusted Advisor 自体の閲覧・操作は IAM で制御できるため、結果を見られる利用者を最小権限で限定する
- 結果はベストプラクティスとの突き合わせであり、網羅的なセキュリティ評価の代替ではない。詳細な継続監視は専用のセキュリティサービスと併用する
Well-Architected の観点
- コスト最適化: 未使用・低稼働リソースの発見や、購入オプション見直しのきっかけを得られる
- セキュリティ: 公開ポートや権限設定など、よくある設定ミスを横断的に洗い出せる
- 運用上の優秀性: 定期点検を運用プロセスに組み込み、改善のループを回す起点になる
- 信頼性: 単一 AZ 構成やバックアップ不足など、耐障害性に関わる弱点に気づける
試験で問われるポイント
- 「ベストプラクティスに照らしてアカウントを自動点検・助言する」サービスといえば Trusted Advisor
- チェックのカテゴリは、コスト最適化・セキュリティ・耐障害性・パフォーマンス・サービスの制限の観点
- 利用できるチェックの範囲はサポートプランに依存する(上位プランで全チェックが使える)
- 詳細なセキュリティ評価や継続監視は別の専用サービスの役割であり、役割分担を問われやすい
関連サービス・比較
セキュリティに特化した評価サービスである Amazon Inspector とよく対比されます。Trusted Advisor は横断的な気づきの起点、Inspector は脆弱性の深掘りという役割の違いを押さえます。
| 観点 | Trusted Advisor | Amazon Inspector |
|---|---|---|
| 主目的 | 横断的なベストプラクティス点検 | 脆弱性の継続的な評価 |
| 対象範囲 | コスト・セキュリティ・信頼性など複数観点 | 主に計算リソースの脆弱性とエクスポージャ |
| 評価の深さ | 広く浅く気づきを与える | 特定領域を深く詳細に評価 |
| 代表的な使いどころ | 全体の健全性レビューの起点 | セキュリティ運用の継続監視 |
ハンズオン / CLI例
# 利用可能なチェックの一覧を取得(言語は英語指定の例)
aws support describe-trusted-advisor-checks \
--language en \
--query "checks[].{ID:id,Name:name,Category:category}"
# 特定チェックの結果を取得(ステータスと影響リソースを確認)
aws support describe-trusted-advisor-check-result \
--check-id <チェックID> \
--query "result.{Status:status,FlaggedResources:flaggedResources[].metadata}"
# 特定チェックを再実行して最新状態に更新
aws support refresh-trusted-advisor-check \
--check-id <チェックID>
AWS Service
AWS Trusted Advisorを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
管理・ガバナンス
比較で見る軸
クラウド: AWS / カテゴリ: 管理・ガバナンス / 難易度: basic
導入後に効く点
コスト最適化・セキュリティ・耐障害性・性能・サービス上限の観点で助言する。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- 管理・ガバナンス
- 難易度
- basic
- 関連資格
- CLF-C02 / SOA-C02
- 設計柱
- cost / security / operational
判断チェックリスト
- 自社の用途が「管理・ガバナンス / cost」に近いか確認する。
- 強みである「アカウント全体を自動スキャンし、ベストプラクティスからの逸脱を検出する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。