こんにちは。
simplineのmiddleです。
前回の続きを書いていきたいと思います。
どうぞよろしくお願いいたします。
★今回のお題
Trusted Advisorをどこまでtrustするか
その１ 背景〜Trusted Advisorとは
その２ 仕様〜まとめ ←本日はこちら
その３ おまけ「開かれたポート、無制限アクセス」編
★利用料金など
Trusted Advisorは、サポートプランに応じて使える機能が変わります。
すべての項目を利用するには、エンタープライズもしくはビジネスである必要があります。
開発者とベーシックは下図の通り、「コアチェックおよび推奨」に限られます。
コスト削減したいために使うのに、何故お金をとるのだろう……というのが最初の率直な感想でした。
（Trusted Advisor自体がイコール有料というわけでもないですが。）
コスト最適化以外の項目も多数見てくれますし、サポートプラン選択にあたり指標の一つとするのもありでしょうか。
★通知
Trusted Advisorの結果は、Eメールで通知させることが可能です。
通知設定を行うと、結果が毎週届きます。
毎週＝1週間に1回というのが、まさに「アドバイザー」という印象を受けました。
▲Chinese/English/French/Japaneseがチョイスできました。
ほかサービスと組み合わせることで即時通知も可能です。
Trusted AdvisorのメトリクスはCloudwatchに送信できるので、アラームを利用できます。
■参考：
AWS Trusted Advisor のメトリクスおよびディメンション – Amazon CloudWatch
CloudWatch を使用して Trusted Advisor アラームを作成する – AWS サポート
※Trusted Advisor（グローバルサービス）のメトリクスは、バージニア北部リージョンでないと使えないので気をつけましょう。
ただ、「赤色状態になったルールが○個あるよ」というようなメトリクスは、使うとしたら閾値をどうしたものか……。
ベストプラクティスに完全に沿った構成とかだったら、活用できそうです。
ちなみに組み合わせという点では、「Trusted Advisorのチェック結果に基づき推奨アクションをとりたい」という場合も、作りこみすれば可能です。
■参考：
Trusted Advisor チェック結果を Amazon CloudWatch Eventsで監視する – AWS サポート
Trusted Advisor単独で自動アクション実行、等の機能はないので、そのへんもアドバイザー感を醸し出している気がします。
★まとめ
やはり、あくまでAWSのベストプラクティスに従ってチェック実施、というところがポイントでしょう。
ルールの基準はユーザ側でいじれない仕組みです。
要件によっては、そのベストプラクティスとは異なるケースもあるかと思います。
特に別環境からAWSへの移行はそれは顕著な気がしまして、「元々あるものを、AWSに移行したからといって、変えたくない」というのは割とよくあるのではないでしょうか。
ただ、AWS環境においてはやはり、「元々あるものを、AWSに移行したので、AWSというものに沿った仕様にする」というのがもしかしたら正解なのかもしれません……。
結果といたしましては、今回Trusted Advisorは監査に利用しないことになりました。
AWSはサービスが数多くあるので、その取捨選択はいろいろ考えさせられます。
別件ではSNS or SESということもありました！（これはSNSになりました。）
というわけで今回はここまでです。
※次回は完全なるおまけです。
よろしくお願いいたします。
