【学習ノート】AWS SAA取得に向けて(CloudWatch,CloudTrail)

運用支援サービス

CloudWatch

定期的にリソース状態を取得し、問題があれば運用者へ通知する
CloudWatchには安定運用をサポートする以下3つの機能がある

• CloudWatch
• CloudWatch Logs
• CloudWatch Events

CloudWatch

CloudWatchのメイン機能
AWSリソース状態を定期的に取得し、この状態をメトリクスと呼ぶ

• 取得対象の例
  • EC2のCPU利用率
  • Lambda関数ごとのエラー回数

上記の例のようにaws側であらかじめ定義されているメトリクスを標準メトリクスと呼ぶ
<標準メトリクスの一覧>
一方、利用者が定義した値をCloudWatchへ引き渡すことで独自のメトリクスを作成できる。
これをカスタムメトリクスと呼ぶ。
これらのようなメトリクスを選択し、アラームを定義することができる。

• アラーム設定の例
  • 対象EC2インスタンスのCPU利用率が80%を上回るとき
  • 定期実行されるLambda関数が一定期間に3回以上エラーを出したとき

アラーム条件をみたした時、SNSへ通知するような設定も可能。
その場合、SNSからLambda関数を呼び出してEC2の設定を変更したり、運用担当者へメールを送信したりといった設定が可能。

CloudWatch Logs

アプリケーションやApacheなどのログをモニタリングするサービス
収集したログに対してアラームを設定することができ、アプリケーションログに「ERROR」から始まる行があった場合、といったように閾値を設定できる。
CloudWatchと同様にアラームをトリガして処理を実行することが可能
CloudWatch　Logsの導入により、アプリケーションレイヤーの監視も可能となる。

• 利用準備
  • 独自エージェントをインストールが必要
    • エージェントを介してCloudWatchへログを送信する
  • ログ送信元のEC2インスタンスへCloudWatchのIAM権限を付与する

CloudWatch Events

独自のトリガと何かしらの後続アクションとの組み合わせを定義するサービス
より疎結合な形でサービス間の連携をはじめ、後からターゲットを追加することも可能

• イベントソース
  • 大きく2つの独自トリガー
    • スケジュール
      • 期間・時間ベースのトリガー定義
    • イベント
      • AWSリソースの状態変化をベースとしたトリガー定義
• ターゲット
  • 後続アクション

CloudTrail

• AWS上の操作ログを取得するサービス
  • 「誰が」「いつ」「どこで」「どのような操作をしたか」といった監査のログ
• CloudTrailで扱うログは以下の2種類
  • 管理ログ
    • コンソールログイン、EC2インスタンス作成など、AWS上の操作ログ
    • デフォルトで有効になっている
  • データログ
    • S3バケット上のファイル操作、Lambda関数の実行など
    • デフォルトでは無効になっている
• 取得したログはデフォルトで90日間コンソール上で確認できる
  • 90日以前のログは証跡を作成することでS3へ保存することができる
    • 有料になります。 AWS CloudTrail の料金
• CloudWatch Logsと連携して取得したログを、設定したキーワードで監視し、必要に応じて通知することも可能
  • 例としては特定の操作を行ったログが出力されたらメール通知するなど