AWSモニタリング/監視サービス
- Amazon Cloud Watch
- AWS Cloud Trail
- AWS Config
- AWS Personal Health Dashbord
以下、詳細説明
Amazon Cloud Watch
メトリクス、ログ、イベントの監視、収集する
メトリクス
- 標準メトリクス：CPU使用率やディスクI/Oなど
- カスタムメトリクス：アプリケーションごとのメモリ使用率やOS内部で取得する必要があるもの。カスタムメトリクスにはCloudWatchエージェントの導入が必要
Cloud Watchのアラーム設定
- 統計：メトリクスを指定の期間で集計した値。平均/最大/合計/90%タイルなどから選択
- 期間：統計を取得する時間のながさ。
- アラームを実行するデータポイント：アラーム実行のための閾値超過数。EX）「5/5」とした場合は5回連続して閾値が超過するとアラームが実行する
アラームステータス
- OK :定義した閾値を下回っている
- ALARM：定義した閾値を超えている
- INSUFFICIENT_DATA：アラーム開始直後であるが、メトリクスが利用できないかデータが不足している状態
ログの監視
CloudWatch Logsの利用：Amazon API Gateway、AWS Lamdaなどのマネージドサービスは標準でCloud Watch Logsへログ収集機能がある。EC2ではCloud Watchエージェントの導入が必要。
- メトリクスフィルター：ログのパターンマッチングをおこなう。
EX） アプリケーションログに「ERROR」もしくは「WARN」が発生したとき(OR条件)
EX）アクセスログの応答時間が5000ms以上のとき(数値比較)
EX）アクセスログに記載されたステータスコードが404かつリクエストが「*.html」のとき(AND条件、ワイルドカード条件)
イベントの監視
Cloud Watch Events：AWSリソースの変更を伴うシステムイベントをトリガーとして、対応したAWSサービスによるアクションの実行を自動するする。トリガーは以下の２つ
- 時間ベースのイベント：毎朝08:00に前日の業務レポートを作成しメールをおこなうAWS Batchジョブの実行
- システムイベントの例：EC2インスタンスが起動されるたびにセキュリティグループのルールを確認し、0.0.0.0/0のインバウンド通信が許可されていた場合はEC2インスタンスを終了するLamda関数を実行する。
AWS Cloud Trail
AWS Cloud TrailはAWSのAPI利用状況に関するログを記録することができる。
具体的には以下の状況に対して有用
- 特定インスタンスをシャットダウンしたユーザの特定
- セキュリティグループの設定を変更したユーザ特定
- 社外のIPアドレスかあら受信したAPI利用の有無を調べる
- アクセス権がないために拒否されたAPIリクエストの詳細を調べる など
収集したログは「証跡(Trail)」として、イベント履歴機能により証跡の検索や表示が可能。S3やCloud Watch LogsやCloud Watch Eventに吐き出して一元管理や監視も可能。
AWS Config
AWS Configはリソースの設定を記録して評価するサービス。CloudTrailで設定変更の履歴を確認できるが、大量のログの中から設定変更の証跡を分析する必要がある。
一方、Configの場合は設定変更に特化したサービスで時系列に変更点を確認できるためトラブルシュートやセキュリティ調査の際に役に立つ。また、変更の通知をトリガーにSNSに通知したりできる。
リソースの評価はAWS Configルールを設定して適切な設定内容の定義をおこなう必要がある。ルールは事前に設定されたマネージドルールと独自の設定をおこなうカスタムルールがある。
また評価のタイミングは２つある
- 設定変更：ルールの範囲に該当するリソースで設定が変更されると評価がトリガーされる
- 定期内：指定した時間間隔で評価する
ちな、マネージドルールは公式ドキュメントあるので別途参照する。
カスタムルールはLamda関数にコードを記述して実装する。
Configルールに準拠しないリソースがあった場合は修復アクションを実行することで修復可能。AWS System Manager Automationで自動サービスに事前定義された運用タスクを実行可能。
AWS Personal Health Dashboard
AWS利用者の環境に影響するAWSイベントの通知やメンテナンスへの対処方法が表示される。
具体的なユースケースを勉強したほうがいいかも。