EC2 を1台立てて、アプリが動いた。そこで「本番でも止まらないように監視しておいて」と頼まれると、手が止まります。 CloudWatch を開くとグラフが大量に並んでいて、どれを見ればよいのか分からない。ログはどこに出ているのか、アラームはいつ鳴るのか、そもそも何をもって「異常」とするのかも決まっていない。
この記事は、Amazon CloudWatch を「メトリクス・ログ・アラーム・ダッシュボード」の4つの役割に分けて、何を見れば何が分かるかを整理します。
この記事の結論
- Amazon CloudWatch は、AWS のリソースとアプリの状態を数字とログで集め、異常に気づくためのサービスです。
- メトリクスは時間ごとの数字で、「いつから・どれくらい」おかしいかが分かります。
- ログは出来事の記録で、「何が・なぜ」起きたかを調べるときに読みます。
- アラームはメトリクスを見張り、決めた線を越えた状態が続いたときに通知や自動の対応を起こします。
- EC2 のメモリやディスクの使用率は標準のメトリクスに無く、CloudWatch エージェントで送る必要があります。
Amazon CloudWatch とは（何を集める場所か）
Amazon CloudWatch は、AWS のリソースと、その上で動くアプリケーションを監視するサービスです。公式ドキュメントは「AWS のリソースと AWS 上で実行しているアプリケーションをリアルタイムで監視する」と説明しています。 多くの AWS のサービスは、何も設定しなくても自分の状態を CloudWatch に送っています。利用者は、そこに自分のアプリの数字やログを足していきます。
たとえるなら、CloudWatch は建物の管理室です。壁には電気・水道・室温の 計器 が並び（メトリクス）、机には出来事を書き留めた記録簿があり（ログ）、決めた線を越えると鳴る警報器があり（アラーム）、よく見る計器だけを1枚の盤にまとめた表示板があります（ダッシュボード）。
たとえから正確な言葉に戻すと、4つの役割は次のとおりです。
| 役割 | 何を持つか | 分かること | 代表的な使い方 |
|---|---|---|---|
| メトリクス | 時間ごとの数字（CPU 使用率・要求数・エラー数） | いつから・どれくらいおかしいか | 傾向を見る、アラームの材料にする |
| ログ | 出来事の記録（アプリのエラー文・アクセスの記録） | 何が・なぜ起きたか | 原因を調べる、語の出現回数を数える |
| アラーム | メトリクスとしきい値と、鳴ったときの動作 | 人が見ていない間の異常 | 通知する、台数を増やす、インスタンスを復旧する |
| ダッシュボード | 選んだグラフを並べた1枚の画面 | 全体の様子をひと目で | 障害時に最初に開く、定例で見る |
FROM SIGNAL TO ALERTデータの通り道
リソースの数字とログが貯まり、アラームが見張って知らせる
-
リソース
EC2・Lambda・アプリ
-
メトリクス
時間ごとの数字
-
ログ
出来事の記録
-
アラーム
しきい値と比べる
-
通知
SNS で人に届く
メトリクスとは何か（数字で分かること）
メトリクス は、ある値を時間の順に並べたものです。「このインスタンスの CPU 使用率が、1分ごとに何 % だったか」のような数字の列を指します。 メトリクスは 名前空間（どのサービスの値か。EC2 なら AWS/EC2）と ディメンション（どのリソースの値か。インスタンス ID など）で区別されます。
標準で届く値と、届かない値
EC2 は、CPU 使用率・ネットワークの入出力・ディスクの読み書き・ステータスチェックといった値を、既定で5分ごとに CloudWatch へ送ります。 詳細モニタリング を有効にすると、1分ごとに送られるようになります。
一方で、メモリの使用率やディスクの空き容量は、既定では届きません。これらは OS の中でしか分からない値だからです。 見たいときは、インスタンスに CloudWatch エージェント を入れて、OS の中から値を送ります。同じエージェントで、アプリのログファイルを CloudWatch Logs へ送ることもできます。
自分のアプリの数字を足す
「注文数」「ログイン失敗の回数」のような業務の数字は、アプリから カスタムメトリクス として送れます。 CloudWatch が1秒単位で保存する高解像度のカスタムメトリクスもあり、秒単位の値は3時間まで、その後は1分以上の粒度で読むことになります。
古い数字は粗くなる
メトリクスはいつまでも同じ細かさで残るわけではありません。1分ごとの値は15日間、5分ごとの値は63日間、1時間ごとの値は455日間（15か月）読めます。 「半年前の障害の瞬間を1分単位で見たい」はできないので、振り返りに使う数字は障害の直後に残しておきます。
CHECK 1ここまでの確認
EC2 のインスタンスでメモリの使用率を CloudWatch で見たいとき、必要なことは?
答えと解説
答え: 2. インスタンスに CloudWatch エージェントを入れて、OS の中の値を送る
メモリやディスクの使用率は OS の中の値なので、EC2 の標準のメトリクスには含まれません。エージェントで送ります。「メトリクスとは何か」の章を読み直してください。
ログとは何か（ログでしか分からないこと）
メトリクスは「エラーが増えた」ことは教えてくれますが、「どんなエラーか」は教えてくれません。それを読むのが CloudWatch Logs です。
ロググループとログストリーム
ログは ロググループ という入れ物にまとめられます。ふつうはアプリや関数ごとに1つです。その中に、送り手ごとの流れ（ログストリーム）が並びます。 Lambda の関数が出力したログや、API Gateway のアクセスログ、エージェントが送ったアプリのログは、ここに届きます。
保持期間は既定で「無期限」
ロググループのログは、既定では期限切れにならず残り続けます。保持期間は1日から10年の間で選べます。 ログは保管している量で料金がかかるので、「いつまで要るか」を決めて保持期間を設定しておくのが、料金の止め忘れの対策になります。
読む・数える・流す
- 読む（Logs Insights） … 専用のクエリで、ログを絞り込み・集計します。「直近1時間の 5xx を、パスごとに数える」ような調べ方です。
- 数える（メトリクスフィルター） … 「ERROR」のような語がログに出た回数を、メトリクスに変えます。変えたメトリクスにアラームを付けられます。
- 流す（サブスクリプションフィルター） … 届いたログを、ほぼリアルタイムで Lambda や別の保管先へ送り続けます。
大事なのは、アラームが見張るのはメトリクス（数字）で、ログそのものではないという点です。ログの異常で鳴らしたいときは、メトリクスフィルターで数に変える段を挟みます。
CHECK 2ここまでの確認
「ERROR」という語がログに出た回数でアラームを鳴らしたいとき、つなぐ仕組みとして正しいのは?
答えと解説
答え: 1. ログからメトリクスフィルターで回数を数えてメトリクスにし、そのメトリクスにアラームを付ける
アラームが見るのはメトリクス（数字）です。ログの語はメトリクスフィルターで数に変えてから、アラームにつなぎます。「ログとは何か」の章を読み直してください。
アラームとダッシュボードは何をするのか
アラームは「状態」を持つ
CloudWatch アラーム は、1つのメトリクス（または計算式）をしきい値と比べ続け、次の3つの状態を行き来します。
- OK … しきい値の内側に収まっている。
- ALARM … しきい値の外に出ている。
- INSUFFICIENT_DATA … 始まったばかり、またはデータが届かず、判断できない。
状態が変わったときに、Amazon SNS で通知する、Auto Scaling で台数を変える、EC2 を停止・再起動・復旧する、といった動作を起こせます。
1回はみ出しただけでは鳴らさない
アラームは、「どの長さで区切るか（期間）」「直近いくつの区切りを見るか（評価期間）」「そのうちいくつがはみ出したら鳴らすか」の3つで決まります。 たとえば「1分ごとの区切りを5つ見て、そのうち3つがはみ出したら鳴らす」にすると、一瞬の跳ね上がりでは鳴らず、続いたときだけ鳴ります。
ALARM EVALUATIONアラームの門
線を越えた状態が続いたときだけ通知に通す
アラーム（5つの区切りのうち3つ越えたら鳴る）
- 3/5越えた状態が続く ALARM → 通知5つの区切りのうち3つが超過
- 1/5一瞬だけ跳ねた 鳴らさない5つの区切りのうち1つだけ超過
- 0/5線の内側 OK のまますべての区切りが内側
- —データが届かない 判断できない始まったばかり・送られていない
何でもアラームにすると、鳴り続けて誰も見なくなります。どの値に、どの線で鳴らすかは、利用者に見える症状から逆算して決めます。その決め方は監視設計の記事で扱います。
ダッシュボードは「最初に開く1枚」
CloudWatch ダッシュボード は、選んだグラフや数字を1枚の画面に並べる機能です。複数のリージョンやアカウントの値も並べられます。 「障害のときに最初に開く1枚」を決めておくと、どこから見るかで迷う時間が減ります。
CHECK 3ここまでの確認
CloudWatch のアラームが INSUFFICIENT_DATA の状態のとき、分かることは?
答えと解説
答え: 2. 判断に使えるだけのデータがまだ無い（始まったばかり・データが届いていない）
アラームの状態は OK・ALARM・INSUFFICIENT_DATA の3つです。INSUFFICIENT_DATA は「異常」ではなく「判断できない」。データが届かない理由を確かめます。「アラームとダッシュボード」の章を読み直してください。
何を見れば何が分かるのか
最後に、よくある困りごとから、CloudWatch のどこを見るかを並べます。数字で「いつから・どれくらい」を掴み、ログで「何が・なぜ」を読む、の順です。
WHERE TO LOOK困りごとから見る場所へ
数字でいつからを掴み、ログでなぜを読む
言われたこと
最初に見る場所
言われたこと: 遅い
最初に見る場所: 応答時間のメトリクスと、同じ時刻の CPU・要求数
言われたこと: エラーが出る
最初に見る場所: エラー数のメトリクス → その時刻のログを Logs Insights で
言われたこと: メモリが足りない気がする
最初に見る場所: エージェントで送っているかを確かめる
言われたこと: 誰かが設定を変えた
最初に見る場所: CloudWatch ではなく CloudTrail の操作記録
- 「遅い」と言われた … まず応答時間（ロードバランサーのレイテンシなど）のメトリクスで、いつから遅いかを見る。同じ時刻の CPU 使用率や要求数と並べて、負荷の増加と重なっているかを見る。
- 「エラーが出る」と言われた … エラー数のメトリクスで始まった時刻を掴み、その時刻のログを Logs Insights で絞り込んでエラー文を読む。
- 「メモリが足りない気がする」 … 標準のメトリクスには無いので、エージェントを入れて送っているかを最初に確かめる。
- 「誰かが設定を変えた気がする」 … これは CloudWatch ではなく AWS CloudTrail（誰が・いつ・どの API を呼んだかの記録）から調べる。
EC2 の標準のメトリクスで何が見えるかは、EC2 の記事の「借りた1台」の中身と合わせて読むと、どの値がどの部品の話かがつながります。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
見る道具がそろったら、次は「どの値を、どの線で見張るか」を決める段です。
READ ALSO — 実務向け・段3 基盤
監視設計｜何を見るかは SLO から逆算する。4つのシグナルと、アラームを鳴らす基準の決め方
参照ソース
- What is Amazon CloudWatch?（Amazon CloudWatch ユーザーガイド） — CloudWatch の定義と、メトリクス・アラーム・ダッシュボードの役割（2026年9月時点）
- Metrics concepts（Amazon CloudWatch ユーザーガイド） — 名前空間・ディメンション、高解像度メトリクス、1分値15日・5分値63日・1時間値455日の保持（2026年9月時点）
- Basic monitoring and detailed monitoring in CloudWatch（Amazon CloudWatch ユーザーガイド） — EC2 の既定5分間隔と、詳細モニタリングの1分間隔（2026年9月時点）
- Metrics collected by the CloudWatch agent（Amazon CloudWatch ユーザーガイド） — メモリなど OS の中の値をエージェントで集めること（2026年9月時点）
- Working with log groups and log streams（Amazon CloudWatch Logs ユーザーガイド） — ロググループとログストリーム、既定で期限切れにならないこと、保持期間の選択肢（2026年9月時点）
- Analyzing log data with CloudWatch Logs Insights（Amazon CloudWatch Logs ユーザーガイド） と Creating metrics from log events using filters（同） — ログの検索・集計と、メトリクスフィルター（2026年9月時点）
- Alarm evaluation（Amazon CloudWatch ユーザーガイド） — アラームの3つの状態と、期間・評価期間・アラームを出すデータポイント数（2026年9月時点）
- Using Amazon CloudWatch dashboards（Amazon CloudWatch ユーザーガイド） — ダッシュボードと、複数リージョン・アカウントの表示（2026年9月時点）
