エンジニアブログ

[AWS]ベストプラクティスに沿ってリソースチェック その2

2018.09.19

こんにちは。
simplineのmiddleです。

前回の続きを書いていきたいと思います。
どうぞよろしくお願いいたします。

 

★今回のお題

Trusted Advisorをどこまでtrustするか

その1 背景〜Trusted Advisorとは
その2 仕様〜まとめ ←本日はこちら
その3 おまけ「開かれたポート、無制限アクセス」編

 

★利用料金など

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になりました。)

 

 

というわけで今回はここまでです。
※次回は完全なるおまけです。
よろしくお願いいたします。

関連キーワード

この記事をシェアする

Facebook Twitter LINE はてなブックマーク

この記事を読んだ方に
おすすめの記事