参考

【Amazon CloudWatch】
サービスを継続して運用するために、管理者は例えばストレージがすべて使い切られる前に余剰を確保しておいたり、負荷が高くなり機能不全に陥る前に追加のリソースを用意したりと、状況に応じた適切な処置を行う必要があります。
Amazon CloudWatchは、AWSサービスやオンプレミス（自社運用）のシステムを監視し、しきい値（境界値）を超える・下回るなどした場合に管理者に通報するなど、サービスのリソース（CPU使用率やストレージの使用状況など）の状態に応じたアクションを取らせることができます。管理者はCloudWatchを利用することにより、サービスの安定した運用やパフォーマンスの向上、サービスの改善に役立てることができます。


CloudWatchには「CloudWatch」「CloudWatch Logs」「Amazon EventBridge（CloudWatch Events）」の3つの機能があります。


【CloudWatch】
CloudWatchが監視する様々なリソースの情報は「メトリクス」と呼ばれます。インスタンスのCPU使用率やディスクの使用状況（読み取り・書き込みの量）など、予め定義されているメトリクスを標準メトリクスと呼びます。標準メトリクスはサービスごとに提供されており、CloudWatchのダッシュボードから確認することができます。

以下は標準メトリクスとして監視可能な項目の例です（【】内がサービス名）。
【EC2】CPU使用率、ディスクの読み取り・書き込み量
【S3】バケットサイズ、ファイル（オブジェクト）数
【ELB】リクエスト数、リクエストの応答時間
【RDS】ストレージの空き容量、秒間の読み取り・書き込み操作の量

CloudWatchではこれらのメトリクスに対してアラームとアクションを設定できます。例えば「EC2インスタンスのCPU使用率が80%を超えたとき」というアラームに対して「管理者宛にメール通知」というアクションを設定すると、条件を満たしたときにアクションが実行されます。なお、メール通知はSNS（Simple Notification Service）というメッセージングサービスと連携して実現します。
EC2インスタンスについては、メール通知だけではなく、インスタンスの再起動・停止・終了・復旧というアクションも用意されています。例えば、必要な処理が完了したらインスタンスを停止・終了することでコストを削減できます。また、復旧アクションを選択すると、ハードウェア異常が発生した際に自動的に新たなインスタンスで復旧します。
なお、これらの監視間隔はデフォルトで5分です（基本モニタリング）。1分間隔で監視を行いたい場合は「詳細モニタリング」を有効にします。基本モニタリングは無料ですが詳細モニタリングは有料です。

●カスタムメトリクス
標準メトリクスとして用意されていない項目を監視したい場合、管理者は「カスタムメトリクス」を定義します。
例えばEC2インスタンスにおいて、CPU使用率やディスクの読み取り・書き込み量（bytes）などは標準メトリクスとして用意されていますが、メモリ使用量やディスクの空き容量（使用状況）に関する項目はありません。このような項目を監視したい場合、EC2インスタンスへ「CloudWatchエージェント」をインストールし、AWS CLIコマンドやAPIを用いて監視項目をCloudWatchへ送信します。
以下はEC2インスタンスの代表的な監視項目です。


●複合アラーム
複数のメトリクスがしきい値を超えたときに通知を出したい場合は「複合アラーム」を作成します。例えば「CPU使用率が80%を超えたとき」に通知するアラームと、「受信ネットワークトラフィック量が60MB/分を超えたとき」に通知するアラームが両方アラーム状態になった場合に、複合アラームを通知するという設定ができます。複合アラームを使用してアラームの通知条件を厳密にすることで、対応不要な通知を減らす効果が期待できます。

●CloudWatchダッシュボードの共有
CloudWatchのダッシュボードは「ダッシュボードの共有」機能を使用することで、AWSアカウントを持たない相手と共有することが可能です。これにより、新規にAWSアカウントやIAMユーザーを作成することなく、共有先のEメールアドレスを指定して、普段AWSを利用していないメンバーや社外の関係者とダッシュボード上の情報を簡単に共有することができます。

また、「ダッシュボードの共有」機能を使用した場合、共有を受けたメンバーにはそのダッシュボードの情報を参照するために必要な最小限の権限のみが自動的に付与されます。CloudWatchダッシュボード以外のリソース（ログやアラームの定義など）に対するアクセス権限は付与されないため、最小権限の原則に則った安全な共有を実現することができます。



【CloudWatch Logs】
CloudWatch LogsはAWSサービスやEC2インスタンスのOSやアプリケーションのログを収集し、一元管理するサービスです。例えば、CloudTrailにおけるAWSサービスの操作ログや、VPCフローログ（VPC利用時のIPトラフィック情報）などを収集することができます。収集したログは、メッセージの内容をフィルタリングして管理者に通知させることができます（例：EC2インスタンスのOSログで"Error"の文字列を1時間に5回検出した場合、管理者へメール通知する）。

なお、EC2インスタンス上のアプリケーションやOSのログを収集するには、対象のEC2インスタンスへ「CloudWatchエージェント」をインストールする必要があります。

さらに、フィルタリングしたログをAmazon Kinesis（※1）やAWS Lambda（※2）、Amazon OpenSearch Service（※3）などの別のサービスへ転送し、ログをリアルタイムに解析したり、ログの内容に応じてプログラムを実行させる、といった連携も可能です。
　※1: Kinesis ... ストリーミングデータ（継続的に発生するデータ）やイベントログなどのリアルタイム分析が可能なAWSサービス。
　※2: Lambda ... サーバーレスでプログラムの実行が可能なAWSサービス。他サービスと連携でき、イベントが発生したタイミングでプログラムを起動させることができる。Lambdaで起動するコードをLambda関数（Lambda Function）と呼ぶ。
　※3: OpenSearch Service ... フルマネージド型の検索・分析エンジンサービスであり、テキストの全文検索やログ分析などの用途に利用できる。

別のサービスへ転送するには、CloudWatch Logsのサブスクリプションフィルターで、データの転送先を設定します。


●CloudWatch Logs Insights
2018年に追加された機能で、収集したログのインタラクティブな検索や分析を行うことができます。CloudWatch Logsの管理コンソールでは単語検索によるフィルタリングを行えますが、CloudWatch Logs Insightsではクエリの実行にも対応しており、例えば「特定のアプリケーションが一定期間に出力した"Error"を含むメッセージをカウントする」など柔軟なログ解析が可能です。


【Amazon EventBridge（CloudWatch Events）】
Amazon EventBridgeは、AWS上のリソースの状態変化やスケジュールに応じてアクションを実行することができるサービスです。EventBridgeを利用すると、管理者は以下のような運用ができます：
・EC2インスタンスが起動状態（running）から停止状態（stopped）になったとき、再起動する
・毎日決まった時刻にアプリケーションのログを収集・圧縮するLambda関数を呼び出す

これらのイベントルールを定義する際、トリガーとなるものを「イベントソース」と呼び、行う処理のことを「ターゲット」と呼びます。


ターゲット（アクション）としては、既に定義されているAPI（"EC2:RebootInstances"など）を呼び出したり、他サービスと連携したアクションをとることができます。特にLambda関数を使えばアクションを独自に定義することができますから、例えば毎日定時に決められたスクリプトを実行する、というルールを作成することも可能です。

また、EventBridgeは、AWS環境の脅威を検知するサービス「Amazon GuardDuty」と連携することもできます。脅威を検知した際に管理者宛にメール通報をさせたり、特定した脅威に対してアクションをとるLambda関数を定義して呼び出す、といった運用を行うことで、AWSサービスやAWSアカウントのセキュリティを高めることができます。

なお、Amazon EventBridgeの元はCloudWatchの機能の一つである「CloudWatch Events」でした。EventBridgeはCloudWatch Eventsをベースに機能が追加されているため、CloudWatch EventsのAPIやルールなどは継続して利用できます。