Amazon CloudWatch による監視・ログ分析・運用自動化

CloudWatch を監視の中心に置く

システム監視は、サービスが期待どおり動いているかを継続して観察し、異常を検出したあとに調査・通知・復旧へつなげる運用活動です。監視対象はサーバーやネットワークだけではありません。OS のリソース使用率、アプリケーションの応答時間やエラー、DNS やロードバランサーの状態、認証失敗や不審なアクセスといったログ上の兆候も含みます。

監視から得られる情報は、障害対応だけでなく、性能改善、キャパシティ計画、セキュリティ調査、監査要件への対応にも使います。「今、サービスが遅いか」を数値で把握することと、「誰がどの設定を変えたか」を後から追うことは別の問いです。AWS では CloudWatch がメトリクス・ログ・アラームを中心とした運用可視化を担い、CloudTrail は API 操作の証跡、AWS Config はリソース構成とその変更履歴を扱います。目的に応じて組み合わせます。

CloudWatch は AWS サービスが発行する標準メトリクスを集約するほか、アプリケーションや CloudWatch Agent からカスタムメトリクスとログを受け取ります。収集したデータはグラフやダッシュボードで可視化でき、しきい値や異常検知をアラーム条件にし、SNS 通知や対応アクションへ結び付けられます。

メトリクスで数値の変化を追う

**メトリクス（metric）**は、測定値を時間に沿って記録した時系列データです。CPU 使用率、リクエスト数、レイテンシー、キュー内のメッセージ数などを定期的に記録し、「値がいつ、どの程度変わったか」を把握します。CloudWatch のメトリクスは通常、名前空間（namespace）、メトリクス名、ディメンションの組み合わせで識別します。ディメンションは、例えば環境名やリソース ID など、データを分類する名前と値の組です。

多くの AWS サービスは標準メトリクスを CloudWatch に自動送信します。一方、アプリケーション固有の処理件数や業務上の成功率など、標準メトリクスだけでは分からない値はカスタムメトリクスとして発行します。CloudWatch Agent を使えば、EC2 のゲスト OS やオンプレミスサーバーから追加のシステムメトリクスを収集できます。AWS リソースの標準メトリクスと、OS 内部やアプリケーション固有のカスタムメトリクスは、収集元と設定要否が異なります。

メトリクスは一定の**期間（period）**ごとに集約して確認します。平均値だけでなく、合計、最小、最大、サンプル数、パーセンタイルなど、問いに適した統計量を選ぶことが重要です。例えば平均レイテンシーが正常でも、一部のリクエストだけが極端に遅いことがあります。その場合は p95 や p99 といったパーセンタイルを確認すると、裾の遅延が見えやすくなります。

標準メトリクスはサービスとメトリクスごとに発行頻度や粒度が定められます。高解像度メトリクスが必要な場合は、対応するカスタムメトリクスを短い間隔で発行し、アラーム側の期間もその粒度に合わせます。短い期間で評価するほど検知を早められますが、ノイズやデータ量、コストも考慮します。

CloudWatch Logs の構造と保存

CloudWatch Logsは、AWS リソース、アプリケーション、EC2 やオンプレミスのサーバーなどからログを集約し、検索・分析・保持するマネージドサービスです。障害時の原因究明、アプリケーション挙動の確認、セキュリティ調査、保持期間に関する要件への対応に利用できます。

ログデータの基本単位と階層は次のとおりです。

用語	意味	例としての見方
ログイベント（log event）	タイムスタンプとメッセージからなる個々の記録	ある時刻に記録された「決済要求の検証に失敗した」という一件
ログストリーム（log stream）	同じロググループ内で、特定のログ送信元から届くイベントのまとまり	1 台のアプリケーションサーバーが出力したログ列
ロググループ（log group）	ログストリームをまとめ、保持期間やアクセス制御等を管理する単位	本番環境の注文 API のログストリーム群

ロググループごとに保持期間を設定できます。監査や調査で必要な期間を満たす一方、不要なログを無期限に残さないよう、保持ポリシーを決めます。アクセス権限や暗号化も含めて、ログを扱う範囲を設計します。

Logs Insights でログを調べる

CloudWatch Logs Insightsは、Logs に保存されたイベントを対話的に検索・集計する機能です。対象ロググループと時間範囲を選び、クエリを実行してエラーの傾向、特定の操作が起きた時間帯、リクエスト属性ごとの偏りなどを調べます。CloudWatch Logs Insights には専用の Logs Insights QL があり、用途やデータソースに応じて OpenSearch Service SQL や PPL も選択できます。単にSQLと同じ文法だと考えず、使用するクエリ言語の仕様に合わせます。

例えば、モバイルアプリのバックエンドで一時的なタイムアウトが増えたとき、API の構造化ログから対象期間の status、path、elapsedMs を抽出し、パス別の発生数や遅延分布を集計します。時系列のメトリクスだけでは見えない「どのリクエスト属性で問題が偏っているか」を絞り込めます。クエリの結果は、修正後の確認や運用ダッシュボードへの追加にも利用できます。

Logs Insights は対話的な調査に向いています。クエリ対象、期間、絞り込み条件を明確にし、必要なフィールドだけを選んで集計すると、原因調査を効率化できます。AWS サービスや JSON 形式のアプリケーションログではフィールドを自動検出できる場合がありますが、ログ形式に依存するため、出力設計を一貫させることが重要です。

大量データを別の分析基盤で処理したい場合、CloudWatch Logs から Amazon S3 へ期間を指定してエクスポートし、Athena などで分析する方法があります。ただし、エクスポートしたファイル内のイベントが時刻順に並ぶ保証はなく、データがエクスポート可能になるまで時間がかかる場合があります。定期的・継続的なアーカイブや近リアルタイム処理には、S3 エクスポートを常時転送手段として使わず、ログサブスクリプションなど用途に合った連携を選びます。

メトリクスフィルターでログを数値化する

**メトリクスフィルター（metric filter）**は、ロググループに取り込まれるイベントから指定したパターンに一致するものを検出し、その件数やイベント中の数値を CloudWatch メトリクスとして発行します。ログ内の条件を継続的に数値監視へ変換できるため、ログ検索を都度実行しなくてもアラームやグラフに使えます。

例として、予約サービスのログに InventoryConflict というイベントが記録される場合を考えます。このパターンをメトリクスフィルターで数え、5 分間の発生数をカスタムメトリクスにします。発生数が運用上許容できる水準を超えた場合に、CloudWatch アラームから運用チームへ通知できます。JSON ログから数値フィールドを抽出する設計なら、件数だけでなく処理対象数や遅延値などをメトリクス化することもできます。

フィルターは作成後に取り込まれるログイベントに適用され、過去ログをさかのぼってメトリクス化するものではありません。また、ログ自体が届かない期間と、ログは届いているが一致イベントがない期間は意味が異なります。既定値を設定するか、アラーム側で欠損データをどう扱うかを明示しないと、グラフに値がない状態を「エラーが0件」と誤認することがあります。

CloudWatch アラームで状態を判定する

CloudWatch アラームは、メトリクスまたは対応するクエリ結果を監視し、定義した条件に基づいて状態を遷移させます。評価では、監視するメトリクス、統計量、期間、しきい値、評価する期間数、およびそのうち何点がしきい値を超えれば違反とするか（M-out-of-N）を組み合わせます。単一の瞬間値で反応するのではなく、継続時間や評価点数を設けることで、一時的な揺らぎによる誤通知を抑えられます。

メトリクスアラームの代表的な状態は次の3つです。

状態	意味	運用上の確認
OK	評価データがしきい値条件に違反していない	正常状態。ただし監視対象の範囲が正しいかは別途確認する
ALARM	条件を満たすデータポイントが評価期間内にある	通知やアクションを開始し、関連ログや依存先を調べる
INSUFFICIENT_DATA	状態を判断するだけのデータが不足している	リソースが停止中か、メトリクス送信・権限・ディメンション等に問題がないか確認する

例えば、予約 API の 5 分間のエラー率が一定水準を超えた状態が複数評価点続いたときに ALARM とし、SNS トピックへ通知する設計にできます。アラーム状態変化を契機に、対象に応じて EC2 アクション、Auto Scaling アクション、Systems Manager の OpsItem 作成などを利用できるケースもあります。通知と自動復旧は同じではありません。アクションの権限・対象・安全性を確認し、誤った停止やスケール操作を起こさないようにします。

評価対象のメトリクスが届かないときの扱いは設計上の論点です。例えば、アイドル状態では値を発行しないリソースもあります。欠損を breaching、notBreaching、ignore、missing のどの考え方で扱うかは、メトリクスの意味に合わせて選びます。データがないことを常に障害、あるいは常に正常とみなすのではなく、「送信が止まったこと自体を検知すべき監視か」を判断します。

アラームの**異常検知（anomaly detection）**は、履歴に基づいて通常の範囲を推定し、固定しきい値だけでは表しにくい季節性や日内変動を監視する選択肢です。固定しきい値はSLOや明確な上限に適し、異常検知は通常パターンからの逸脱に適します。両者の特性を理解して選びます。

アラームはダッシュボードに配置して、関連メトリクスと合わせて確認できます。複数条件をまとめる複合アラームを使うと、個別アラームのノイズを抑えて、複数の兆候がそろった場合だけ通知する構成も可能です。

Lambda を含む柔軟な処理をアラーム状態変化から開始する場合は、アラームそのものに任意の Lambda 実行を割り当てるのではなく、CloudWatch アラーム状態変更イベントを EventBridge ルールで捕捉し、Lambda などのターゲットへ渡す構成を使えます。アラームはメトリクス評価、EventBridge はイベント配送を担当するという役割分担です。

EventBridge でイベントをアクションにつなぐ

Amazon EventBridgeは、AWS サービスやアプリケーションのイベントを受け取り、ルールに一致したイベントをターゲットへ配送するイベント駆動型サービスです。イベントパターンでイベント内容を照合し、条件に合ったとき Lambda 関数、SNS トピック、SQS キューなどのターゲットに処理を委ねます。1つのルールから複数ターゲットを実行する構成も可能です。

例として、ファイル変換サービスが変換ジョブの完了イベントを発行したら、EventBridge ルールで result=FAILED のイベントだけを選び、Lambda の再試行判定処理と運用通知へ送る構成が考えられます。これは「イベントが発生したことと、その内容」に反応する設計です。

CloudWatch アラームと EventBridge ルールは役割が異なります。アラームはメトリクス等を期間・評価条件に基づいて判定し、OK / ALARM などの状態を持ちます。EventBridge は発行されたイベントをパターンにより振り分け、ターゲットへ配送します。メトリクスのしきい値監視を作る場面ではアラーム、リソース状態やアプリケーションイベントに応じて処理を起動する場面では EventBridge が中心です。

従来の EventBridge スケジュールルールには rate や cron 表現による定期実行があります。ただし、現在AWSは新しい定期タスクには Amazon EventBridge Scheduler の利用を推奨しています。Scheduler は繰り返し実行に加えて一回限りのスケジュール、柔軟な実行時間枠、再試行や失敗イベント保持を設定できます。試験や既存システムの文脈ではスケジュールルールも知っておき、新規設計では Scheduler を選ぶという現在の推奨と区別します。

CloudWatch Agent で OS 内部とサーバーログを収集する

AWS サービスが提供する標準メトリクスだけでは、OS 内のメモリ使用量、ファイルシステムの空き容量、プロセス状態などを十分に把握できないことがあります。CloudWatch Agentを EC2、オンプレミスサーバー、対応するコンテナ化アプリケーションに導入すると、ゲスト OS の追加メトリクスやログを収集し、CloudWatch Metrics と CloudWatch Logs に送信できます。アプリケーションが StatsD や collectd で公開するメトリクスを取り込む構成もあります。

CloudWatch Agent の導入・運用は、概ね次の流れです。

1. 対象サーバーが CloudWatch と必要に応じて Systems Manager にアクセスできる IAM ロール／認証情報を用意する。
2. Agent パッケージを取得し、インストールする。Systems Manager を使う場合は Distributor で配布し、Run Command などから設定や開始を自動化できる。
3. 設定ファイルで収集するメトリクス、ログファイル、送信先、ロググループ等を指定する。
4. Agent を起動し、CloudWatch のメトリクスとロググループにデータが届くことを確認する。
5. 必要なダッシュボード、フィルター、アラームを作成して継続運用する。

AMI に Agent があらかじめ含まれる場合もありますが、すべてのイメージで利用可能と決めつけず、対象イメージと Agent の状態を確認します。Systems Manager 経由で管理するには、対象インスタンスが Systems Manager のマネージドノードとして接続できること、Agent やインスタンスプロファイル、ネットワーク到達性などが整っている必要があります。

Agent 用 IAM 権限の分離

Agent はメトリクスやログを送信する権限を必要とし、Systems Manager で設定を配布する場合は、その管理操作に必要な権限も加わります。AWS 管理ポリシーには収集・送信向けの CloudWatchAgentServerPolicy、設定ファイルを Parameter Store に保存する用途を含む CloudWatchAgentAdminPolicy、Systems Manager のマネージドノード機能向けの AmazonSSMManagedInstanceCore があります。

Agent の設定を Parameter Store に登録するセットアップ担当者と、稼働中の Agent が継続的にデータ送信する役割は分離できます。初期設定を終えた後も管理者向け権限を常時付与するのではなく、運用時に必要な送信権限と Systems Manager 管理権限のみを割り当てます。構成によって必要な権限は異なるため、ポリシーの内容と対象 API を確認し、最小権限で設計します。

CloudWatch Agent が収集できる代表例には、CPU、メモリ、ディスク使用率、ディスク I/O、ネットワーク統計、アプリケーションログ、OS／システムログ、HTTP アクセスログがあります。具体的なメトリクス名や利用可否は OS、Agent の設定、アプリケーションのログ形式に依存します。メトリクス送信には CloudWatch の PutMetricData、ログイベント送信には CloudWatch Logs の PutLogEvents に相当する権限が関わり、設定ファイルの登録には Systems Manager Parameter Store 側の権限が別途必要になる場合があります。

Agent を稼働させた後は、Logs のフィルターパターンで警告や業務固有の失敗を抽出し、メトリクスフィルターで数値化できます。ダッシュボードに OS メトリクス、アプリケーションログ由来のメトリクス、アラーム状態を並べると、インフラとアプリケーションの兆候を横断して確認できます。

監視機能を選び分ける

必要なこと	主に使う機能	判断のポイント
AWS サービスやアプリの数値を時系列で追う	CloudWatch Metrics	標準メトリクスで足りるか、カスタムメトリクスが必要かを確認
ログの個別イベントを検索・集計する	CloudWatch Logs / Logs Insights	対象ロググループと時間範囲を選び、クエリで原因を絞り込む
ログのパターンを継続的に数値監視する	メトリクスフィルター	新たに取り込まれるログをカスタムメトリクスへ変換
しきい値や異常を継続評価し、状態変化を通知する	CloudWatch Alarms	期間、統計、M-out-of-N、欠損データの扱いを決める
AWS／アプリケーションイベントを条件で振り分ける	EventBridge	イベントパターンとターゲットを設計する
OS 内部メトリクスやサーバーファイルログを送信する	CloudWatch Agent	インストール、設定、IAM 権限、Systems Manager 管理を整える
誰が AWS API を呼び出したか調べる	AWS CloudTrail	操作証跡を確認し、CloudWatch の性能監視と混同しない
構成変更やルール適合性を評価する	AWS Config	リソース構成スナップショットや変更履歴を確認する

試験で問われる設計判断

• CPU 使用率など既存の数値のしきい値監視が必要なら CloudWatch メトリクスアラームを検討します。通知先に SNS を使う場合、SNS トピックの購読・権限も成立している必要があります。
• アプリケーションログ内の特定エラー数をアラームにしたいなら、メトリクスフィルターでログパターンを数値化し、そのメトリクスにアラームを設定する方法が代表的です。ログを一度調査するだけなら Logs Insights のクエリが適します。
• OS 内のメモリやファイルシステムの値を取りたい場合は、標準の EC2 メトリクスだけでは取得できないことがあるため、CloudWatch Agent の設定を検討します。
• イベント内容を条件に処理を起動したい場合は EventBridge のイベントパターンとターゲットを設計します。定期起動の要件では EventBridge Scheduler を優先して検討します。
• 障害時に原因を追いたい場合は、メトリクスで発生時間と影響範囲を特定し、該当時間帯の Logs Insights でリクエストやエラーを調べます。API 操作の主体や変更内容は CloudTrail、構成の変化は AWS Config と照合します。
• **アラームが INSUFFICIENT_DATA**の場合は、直ちにサービス障害と判断せず、メトリクスが発行される条件、Agent の稼働、IAM 権限、ネットワーク、ディメンション、リソースがアイドル状態かを確認します。
• 大量ログを S3 に保管・分析したい場合は、保持期間・エクスポート待ち時間・S3 の保存設計を考慮します。継続配信や近リアルタイムの処理要件を、定期エクスポートで満たそうとしないことがポイントです。

CloudWatch の要点は、数値を測る（メトリクス）、記録を調べる（ログ）、条件に応じて状態を変える（アラーム）、**イベントから処理を起動する（EventBridge）**という役割を混同しないことです。収集元に応じて標準メトリクス、Agent、アプリケーションログを選び、IAM 権限・欠損データ・保持期間・通知先まで含めて監視を設計します。