AWS でのクォータモニタを試してみた

AWS Trusted Advisor はお客様の AWS 環境を分析し、ベストプラクティスに沿うためのレコメンデーションを提供します。チェック項目は以下の 5 つに分類されます。

• コストの最適化：AWSコストを削減する方法について提供
• パフォーマンス：使用率の高いリソースを特定するなど、パフォーマンス改善する方法について提供
• セキュリティ：AWS におけるセキュリティベストプラクティスについて提供
• 耐障害性：AWS リソースの可用性と冗長性を高める方法について提供
• サービス制限：サービスクォータの確認
  

コスト最適化を例に挙げると、Amazon EC2 リザーブドインスタンスの活用や利用率の低いインスタンスの検出などがチェックされます。なお、全項目をチェックするには、AWS ビジネスサポート以上のプラン契約が必要になります。AWS ベーシックサポートと AWS デベロッパーサポートの場合は、一部のセキュリティ項目とサービスクォータのみが確認されます。Trusted Advisorによってチェックされる項目や、ベーシックサポートで確認できる項目については「AWS Trusted Advisor のベストプラクティスチェックリスト」をご確認ください。

サービスクォータについては、制限の 80 %に達した場合黄（警告）、上限に達した場合赤（エラー）が表示されます。また、Trusted Advisor についてより詳しく知りたい方は、AWS Black Belt Online Seminar をご確認ください。

AWS ソリューション「AWS でのクォータモニタ」は、24 時間毎に Trusted Advisor を更新してリソースの使用率を追跡し、上限に近づいた場合は通知を行う構成となっています。確認されるクォータ項目については「サービス制限 - AWS Support」をご覧ください。また、同時にデプロイされる Lambda 関数 vCPU チェッカーが 5 分毎に実行され、Amazon EC2 のクォータが重点的に確認されます。

通知先はメールだけでなく、Slack も選択することができます。なお、本ソリューションは、Trusted Advisor がグローバルサービスであるため、バージニア北部リージョンにデプロイする必要があります。

以下の画像は、今回デプロイするソリューションのアーキテクチャ図となっています。

本ソリューションは、プライマリアカウントとセカンダリアカウントで構成されます。プライマリアカウントは、クォータの監視を行い、制限の 80 % に達していた場合メールもしくは Slack にて通知をするアカウントです。また、すべての監視履歴を Amazon DynamoDB に保存します。セカンダリアカウントは、クォータの監視を行い、その結果をプライマリアカウントに送信するアカウントです。

クォータ監視対象のアカウントが複数ある場合、全てをプライマリアカウントとして本ソリューションを利用することもできます。一方で、収集した情報や通知機能を集約することによって、運用管理の負担を減らすことが可能になります。そこで、本ソリューションでは 1 つのプライマリアカウントに通知機能を実装し、他アカウントはセカンダリとしてそれを利用する構成を推奨します。すでに通知機能を集約したアカウントを保有している場合、そのアカウントをプライマリとする構成が一般的となっています。

このテンプレートをデフォルトで使用した場合、以下のようなワークフローが立ち上がります。

上記アーキテクチャ図のワークフロー 6 - 8 は、セカンダリアカウントで同様のチェックを行い、その結果をプライマリアカウントに集約するプロセスを表しています。

なお、Amazon EC2 インスタンスのクォータ制限はインスタンス数ではなく、使用している vCPU 数ベースに対して行われます。 vCPU 数ベースのクォータの詳細は Amazon Elastic Compute Cloud エンドポイントとクォータをご確認ください。

いくら便利なソリューションといえど、やはりコストは気になりますよね。以下に本ソリューションのプライマリ・セカンダリアカウントにおける月額予想コストをまとめました。それぞれのアカウントが月額数ドル単位でご利用できることが分かるかと思います。また、上記アーキテクチャ図のワークフロー 2、Lambda 関数による vCPU クォータのモニタリング頻度 (デフォルト : 5 分) を下げることでコストを節約することができます。

プライマリ・セカンダリアカウントそれぞれのデプロイ手順についてご紹介します。

補足：Slack 通知のための設定

Slack を使用して通知を行う場合は、Incoming Webhook の設定が必要です。詳細は、実装ガイドをご確認ください。設定が完了したら、発行された URL と送信先チャンネル名を CloudFormation のパラメータに設定します。

また、Lambda 関数に関連した CloudWatch Logs や DynamoDB は CloudFormation スタック削除後も残ってしまうので、別途削除する必要があります。

以上で今回デプロイされたリソースが削除されました。

いかがだったでしょうか？今回は AWS ソリューションの「AWS でのクォータモニタ」について紹介しました。本ソリューションを使用することで、クォータの切迫を検出し早期の引き上げリクエストが可能になります。なお、クォータ引き上げのリクエスト方法については、「リファレンスガイド AWS サービスクォータ」をご確認ください。

また、AWS ソリューションを利用することで、お客様がお困りなポイントを簡単に解決できることを理解していただけたと思います。既に他の AWS ソリューションの 紹介記事 もありますので活用していただけると幸いです。最後に、今後 AWS ソリューションの紹介記事が続々登場するので builders.flash の購読もお忘れなく！