はじめに
2022/8/17 に利用可能になった AWS Trusted Advisor の新機能です。優先付された推奨事項をダッシュボードに表示し、ステータスを追跡する機能を提供します。
利用方法
Trusted Advisor Priority を利用するには以下の前提条件があります。
- Enterprise Support に加入済みであること
- AWS Organizations の Management Account にアクセスできること
- AWS Organizations ですべての機能を有効化し、Trsuted Advisor の信頼されたアクセスを有効にすること
さらに Trusted Advisor Priority を有効化するために、メール等でアカウントチームに依頼する必要があります。条件を満たしていても自動的に使えるようにはなりませんのでご注意ください。機能を有効化したあとに無効化することも可能です。
Trusted Advisor Priority の概要
Trusted Advisor Priority はアカウントチームによって特定され、優先付された推奨事項を組織レベルで集約し、ダッシュボードに表示します。アイテムとして登録されるのは Trusted Advisor や Security Hub により自動検出された推奨事項、またはアカウントチームが手動で登録した推奨事項です。
Trusted Advisor Priority を使用することで、アカウントチームと連携して推奨事項のステータスを追跡し、重大なリスクの軽減に取り組めるようになります。
以降、下記ドキュメントのスクリーンショットを一部引用させていただきます。そのため表示内容はサンプルです。
ダッシュボードと推奨事項の確認
機能が有効化済みの状態で Trusted Advisor コンソールメニューから Trusted Advisor Priority をクリックすると以下のようなダッシュボードが表示されます。
アカウントチームによって登録された推奨事項が「優先順位付けされたアクティブなレコメンデーション (Active priotized recommendations)」に表示されます。推奨事項の登録直後はステータスが応答の保留中 (Pending response) になります。
レコメンデーションの 1 つに VPC Endpoint Single AZ Configuration が登録されているので、こちらをクリックして詳細を確認します。詳細画面では、推奨事項の詳細や必要なアクション、影響を受けるアカウントやリソースについて確認することができます。またダウンロードボタンから Excel 形式で Export することも可能です。
推奨事項に対して確認、対応した結果を右上の承諾 (Accept)/却下 (Reject) ボタンから登録できます。
承諾 (Accept) の例
推奨事項をリスクと捉え、対応を開始する場合は承諾を行います。VPC Endpoint Single AZ Configuration のケースでは VPC エンドポイントが意図せずシングル AZ 構成となっており、マルチ AZ 構成に変更が必要な場合です。
指名及び役職を入力して、承諾をクリックします。
承諾、拒否いずれの場合も、氏名と役職の入力が必要です。運用を考えると、入力するのは作業者の氏名/役職ではなく、推奨事項を承諾/拒否すると判断した責任者の情報を入れるべきでしょう。
承諾を行うとステータスが進行中 (In progress) に遷移します。詳細画面の承諾ボタンが解決 (Resolve) に変わっているので対応完了後に再度氏名、役職を入力して解決をクリックします。
これによりステータスが解決済み (Resolved) となり、アカウントチームにも通知されます。ダッシュボード上はクローズタブのクローズド推奨事項として表示されるようになります。
却下 (Reject) の例
推奨事項についてリスクなしまたはリスクを許容する判断をした場合は却下を行います。VPC Endpoint Single AZ Configuration のケースでは以下のような理由が考えられます。
リスクなし: 対象のアカウントは開発環境のため、シングル AZ 障害によるシステムダウンがリスクとはならない
リスク許容: シングル AZ のリスクを理解した上でシステムの重要度やコストなど他の優先度を考慮し、AZ 障害時の可用性低下について許容する
いずれの場合も氏名、役職以外にその判断をした理由を記載できるようになっています。
却下をクリックするとステータスが 拒否 (Rejected) となり、アカウントチームにも通知されます。以後は承諾同様にクローズドタブに表示されるようになります。
注意点
2022 年 9 時点では 1 つの推奨事項に対し、承諾/却下のどちらかしか 1 つしか登録できません。例えば「アカウント A はリスクに対する対応が必要だが、アカウント B および C はリスクを許容する」といったように、アカウントやシステムの役割に応じて対応結果が変わることは十分に考えられますが、アカウント毎に対応結果を入力することができません。
このような場合、例えば却下の理由欄にアカウント別の対応サマリを記入するなど、ユーザー側で運用を考慮する必要があります。
委任された管理者アカウント
詳細設定のお客様の組織から、最大 5 つのメンバーアカウントを委任された管理者アカウントとして登録できます。最大数の制限があるものの、例えばビジネスユニット毎に委任管理者を設定し、Trusted Advisor Priority へのアクセスを許可するといった運用も可能です。
まとめと所感
Trusted Advisor はこれまでも組織ビューを使用することで組織レベルのチェック結果を集計し、レポートして出力することができました。一方で大規模な組織やアカウント数になれば、組織全体の検出結果は増えていきます。否が応でも優先度をつけて対応していかざるを得ません。
このような課題に関して Trusted Advisor Priority を使用すると、推奨事項のステータスを追跡し、その組織にとって重要度の高いリスクから対応することができます。Enterprise Support が前提となるため利用開始のハードルは高いものの、アカウントチームのプロアクティブな支援を受けながらリスク軽減に取り組めるのは、大規模な組織においては有用な機能であると感じました。
また Trusted Advisor や Security Hub からの検出結果だけでなく、アカウントチームが手動で推奨事項を登録できるのも活用の幅が広がる可能性を感じます。例えば組織内で Well-Architected Review が行われていないシステムがあると判明した場合に、担当のソリューションアーキテクトによって Well-Architected Review 実施の推奨が登録され、そのステータスおよび対応結果を管理するなどのユースケースが考えられます。
一方で承諾/却下の対応結果がアカウント毎に入力できないなどの制限もあり、今後のアップデートによる機能強化に期待したいです。
以上です。
参考になれば幸いです。