この記事は CrowdWorks Advent Calendar 2017 の1日目の記事です。
Trusted Asvisor とは
Trusted Advisor は AWS で利用している EC2 や RDS などのサービスをコストやセキュリティに関する Best Practice に基づいたアドバイスを自動的に行なってくれるサービスです。Best Practice に関しては Web で公開されております。
この機能を使うことで、普段の業務で開発用に立てたインスタンスをついそのままにしてしまった時や、甘めに設定してしまったセキュリティに関して警告を確認することができ、つい放置してしまったインスタンスが元で開発費を圧迫したりセキュリティインシデントが発生するのを軽減することができます。
プランについて
普通のAWS利用者だとしたらサポートプランをアップデートしていなければ Trusted Advisor は制限がかかっていて、セキュリティの一部項目以外は利用できない状態になっています。
すべてのチェックを行うにはビジネス以上のプランにする必要があり、料金も月 \$100 以上かかってしまうので個人利用でこのプランを利用するのはかなりの決断が必要そうです。しかし会社単位で考えるとビジネス以上にすれば \$100 でムダやセキュリティリスクを軽減する事ができるのでお得といえるのではないでしょうか。
おさえておきたいチェック項目
色々なチェック項目はあるのですが、おさえておきたいチェック項目は以下の項目です。
アイドル状態の Load Balancer
Load Balancer はアイドル状態でも結構課金されてしまうので、必要なければ削除しておきたいところです。
使用率の低い Amazon EC2 Instance
EC2 インスタンスは開発するときに実験で何個も立ててしまいがちです。立てるのは良いですが、消すのを忘れるということはよくあるのではないでしょうか。そういう時使用率の低いインスタンス一覧を表示してくれるので便利です。
セキュリティグループ 開かれたポート
無制限のアクセスを許可しているセキュリティグループの一覧を表示してくれるので、これを参考に必要なければ消すなりアクセスを制限するなどしていけます。基本的には制限したほうが安全ですのでここは要注意です。
Amazon S3 バケット許可
S3のバケットがグローバルに公開されている場合警告が出ます。S3 のバケットも割りとカジュアルに作ったりすることがあると思いますので、ここも確認して不要に公開されていないか確認しておいたほうが良さそうです。
コマンドラインからの利用
Trusted Advisor は他の AWS のサービスと同様に aws コマンドから利用できます。
$ aws support describe-trusted-advisor-checks --language ja
これで日本語の description のついたチェック一覧を取得できます。出力は以下のような形式です。
{
"checks": [
{
"category": "cost_optimizing",
"description": "少なくとも過去 14 日間常に稼働している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがあり、1 日の CPU 使用率が 10% 以下、かつ Network I/O が 5MB 以下である日が 4 日以上ある場合にアラートします。実行中のインスタンスに対しては 1 時間毎に使用料が発生します。設計上の考慮により意図的に稼働率を低く抑える場合もありますが、一般的にはインスタンスの台数とインスタンスサイズを調整することでコストを削減することができます。（執筆者注以下略",
"metadata": [
"リージョン",
"インスタンスID",
"インスタンス名",
"インスタンスタイプ",
"月間推定節約額",
"1日目",
"2日目",
"3日目",
"4日目",
"5日目",
"6日目",
"7日目",
"8日目",
"9日目",
"10日目",
"11日目",
"12日目",
"13日目",
"14日目",
"14日間の平均CPU使用率",
"14 日間の平均 Network I/O",
"使用率が低かった日数"
],
"id": "Qch7DwouX1",
"name": "使用率の低いAmazon EC2 Instances"
},
]
}
metadata についてはチェック項目によって異なっています。
ここで得られた id を用いてチェックの詳細を表示してみます。表示するには以下のコマンドを打ちます。
$ aws support describe-trusted-advisor-check-result --language ja --check-id Qch7DwouX1
出力結果は以下になります。
{
"result": {
"checkId": "Qch7DwouX1",
"status": "warning",
"flaggedResources": [
{
"status": "warning",
"resourceId": "見せられないリソースID",
"region": "見せられないリージョン",
"isSuppressed": false,
"metadata": [
"ap-northeast-1b",
"見せられないID",
"見せられないインスタンス名",
"見せられないインスタンスタイプ",
"$90.72",
"2.2% 0.23MB",
"2.2% 0.23MB",
"2.2% 0.23MB",
"2.2% 0.23MB",
"2.1% 0.23MB",
"2.1% 0.23MB",
"2.2% 0.23MB",
"2.1% 0.23MB",
"2.1% 0.23MB",
"2.2% 0.23MB",
"2.2% 0.23MB",
"2.2% 0.22MB",
"2.2% 0.23MB",
"2.1% 0.23MB",
"2.2%",
"0.23MB",
"14 日"
]
},
],
"timestamp": "2017-11-28T02:44:46Z",
"resourcesSummary": {
"resourcesFlagged": "見せられない数字",
"resourcesProcessed": "見せられない数字",
"resourcesSuppressed": "見せられない数字",
"resourcesIgnored": "見せられない数字"
},
"categorySpecificSummary": {
"costOptimizing": {
"estimatedMonthlySavings": "見せられない数字",
"estimatedPercentMonthlySavings": "見せられない数字"
}
}
}
}
このように様々なチェック結果をコマンドで取得することができます。さらに言えばコマンドで取得できるということは API があるということなので自分でプログラムを組んで Slack などと連携することでチェックの速報を流したり自動化することができます。夢が広がりますね。
CloudWatch での監視
CloudWatch でもメトリクスの監視ができ、しきい値を超えたら Slack への通知や、Lambda 関数のキックなどができるので定期的に監視するのであれば利用したいところです。
気をつけたいこととしては東京リージョンの CloudWatch では追加できず、バージニアリージョンだとできるということです。探し回らないように注意しましょう。
あと取れるメトリクスは各アラート基準に該当する要素の個数なので、詳しい情報が得られないことに気をつけてください。キックする Lambda で API を利用して詳細を得るのが良いと思います。
以下はSlackで通知した時の例です。
まとめ
以上かんたんですが Trusted Advisor についてまとめてみました。コストやセキュリティに関する診断を自動的に行なってくれているのでインフラ周りの見直しで重宝しそうです。
そして月並ではありますが、改めてこういうところにも API を提供している AWS ってすごいなと思いました。