AWS運用支援サービス ~CloudWatch / CloudTrail ~

どうも。
今回は運用支援をするためのサービスCloudWatch / CloudTrail について。

CloudWatch

 ->AWS内のリソースを取得する（メトリクス）
具体的にはEC2インスタンスのCPU使用率やLambda関数のごとのエラー回数などが定義されている。
AWSで用意されているメトリクスを標準メトリクスと呼ぶ

一方で、ユーザーが定義したメトリクスをCloudWatchに渡し作成することも可能で、カスタムメトリクスと呼ぶ。

CloudWatchの使用例

①Webサーバー用のEC2インスタンスのCPU使用率が〇〇％を上回った時
②Lambda関数の実行中に一定時間内に○回以上エラーが発生した場合
 ->①や②が発生した場合にSNSに連携しユーザーに通知するなどが可能

CloudWatch Logs

 ->アプリケーションログやApacheログを取得しモニタリングするサービス
※CloudWatch Logsを利用するためには独自のエージェントをインストールし、IAM権限を付与する必要あり

CloudWatch Logsの使用例

 ->収集したログに対してアラームを設定することが可能
例）取得したアプリケーションログに「ERROR」から始まる行があった場合にはアラームを通知する

CloudWatch Events

 ->ユーザー独自のトリガーとその後のアクションを定義するサービス。
独自のトリガーをイベントソース、後続のアクションをターゲットと呼ぶ。

CloudWatch Eventsの特徴・使用例

■イベントソースは大きく分けて2種類ある

①スケジュール
 ->「1週間おきに」「3日おきに」「毎週金曜の19時に」などの期間・時間ベースの定義方法

②イベント
 ->「AutoScalingがインスタンスを増減させたら」「CodeBuildのステータスが変わったら」などのAWSのリソース状態の変化をトリガーにする

■ターゲットには既存のAWSリソースに対するアクションを定義
 ->「Lambda関数をキックする」「CodePipelineを実行する」など
※複数のターゲットを定義することも可能

Event Bridge
 ->今後CloudWatch Eventsと統合予定。同じAPIを使用している

CloudTrail

 ->AWSに関する操作ログを自動的に取得するサービス

CloudTrailの特徴

 ->AWSマネジメントコンソール操作やCLIなどの操作によってAWSリソースを操作したり、データの取得ができたりするので、誤ってデータを削除する、データを持ち出すことが考えられる。よって「誰が」「いつ」「どのような操作を行ったか」を監視することが可能

CloudTrailで取得できるログの種類

 ->大きく分けて2種類ある

①管理イベント
 ->マネジメントコンソールのログイン、EC2インスタンスの作成、S3バケットの作成など

②データイベント
 ->S3のバケット上のデータ操作やLambda関数の実行など

※CloudTrailはの管理イベントはデフォルト設定で有効となっており、過去90日分のログが参照できるようになっている。ただ、データイベントはデフォルトで有効となっていないため、自身で設定する必要がある。