▪️目的

AWSを利用してシステムを構築すると、EC2やRDS、ECSなど、さまざまなAWSサービスを利用することになります。

しかし、システムを構築しただけでは、

• EC2のCPU使用率は高くなっていないか？
• メモリやディスクに問題はないか？
• アプリケーションでエラーが発生していないか？
• サーバーに異常が発生していないか？
• いつ障害が発生したのか？
• 何か異常な状態になったときに通知できないか？

といったことを把握できません。

そこで重要になるのが、AWS CloudWatchです。

CloudWatchは、AWS上のリソースやアプリケーションなどを監視し、メトリクスやログ、アラームなどを利用してシステムの状態を把握するためのサービスです。

この記事では、AWS初心者の方向けにCloudWatchの基本的な仕組みから、メトリクス、ログ、アラーム、CloudTrailとの違いまで分かりやすく解説します。

---

---

▪️CloudWatchとは？

CloudWatchとは、

AWS上のリソースやアプリケーションなどを監視するためのサービス

です。

例えばEC2を利用している場合、

EC2
 ↓
CPU使用率
ディスク関連の情報
ネットワーク関連の情報

など、さまざまな情報を確認できます。

CloudWatchでは、このような情報を収集・監視することができます。

イメージとしては、

AWSリソース
   │
   ├─ EC2
   ├─ RDS
   ├─ ECS
   └─ その他のサービス
          │
          ▼
      CloudWatch
          │
          ├─ メトリクス
          ├─ ログ
          └─ アラーム

という関係です。

つまりCloudWatchは、

「AWS上で動いているシステムが正常な状態なのかを確認するための仕組み」

と考えると分かりやすいでしょう。

---

▪️CloudWatchでは何を監視するの？

CloudWatchでは、大きく分けて、

• メトリクス
• ログ
• アラーム

などを扱います。

まずはこの3つを理解すると、CloudWatchの全体像が見えてきます。

メトリクス
↓
数値として状態を確認

ログ
↓
システムで何が起きたのか確認

アラーム
↓
異常な状態を検知して通知などにつなげる

それぞれ詳しく見ていきましょう。

---

▪️メトリクスとは？

CloudWatchを理解するうえで重要なのが、メトリクスです。

メトリクスとは簡単にいうと、

システムやAWSリソースの状態を数値として表したもの

です。

例えばEC2では、

CPU使用率
ネットワーク通信量
ディスク関連の情報

などのメトリクスを確認できます。

例えば、

CPU使用率
↓
20%

だったものが、

CPU使用率
↓
95%

まで上昇していれば、

「EC2に負荷がかかっているのでは？」

と考えることができます。

---

▪️CPU使用率を監視してみる

例えばWebサーバーとしてEC2を利用しているとします。

通常時は、

CPU使用率
20%

だったものが、アクセス増加によって、

CPU使用率
90%

まで上昇したとします。

CloudWatchでCPU使用率を監視していれば、

CPU使用率
  │
90% ────────●
  │       ／
50% ────●
  │   ／
20% ●
  └──────────── 時間

のように、CPU使用率の変化を確認できます。

このように、時間の経過に伴ってシステムの状態がどう変化したのかを見ることができます。

---

▪️メトリクスは時間と一緒に見る

メトリクスは、単純に「現在何％なのか」だけを見るものではありません。

時間の経過とともに、

10:00 → 20%
10:05 → 25%
10:10 → 40%
10:15 → 70%
10:20 → 95%

のように状態を確認できます。

これによって、

• 徐々に負荷が上がっている
• 一時的に負荷が上がった
• 定期的に負荷が高くなる
• 特定の時間帯だけ負荷が高い

などの傾向を把握できます。

これは障害調査や性能分析でも重要になります。

---

▪️CloudWatch Logsとは？

CloudWatchでは、メトリクスだけでなくログも扱うことができます。

CloudWatch Logsは、

アプリケーションやOSなどから出力されたログを収集・保存・確認するための機能

です。

例えばアプリケーションで、

2026-10-08 10:00:01 INFO  User login
2026-10-08 10:00:05 INFO  Request received
2026-10-08 10:00:08 ERROR Database connection failed

というログが出力されたとします。

このようなログをCloudWatch Logsへ送ることで、AWS上から確認できます。

---

▪️メトリクスとログの違い

ここはCloudWatchを理解するうえで非常に重要です。

例えば、

CPU使用率
95%

という情報はメトリクスです。

一方、

ERROR Database connection failed

という情報はログです。

つまり、

メトリクス
↓
「どのくらい異常なのか」

ログ
↓
「何が起きたのか」

という違いがあります。

実際の障害調査では、この2つを組み合わせて確認することがよくあります。

---

▪️CloudWatch Alarmとは？

CloudWatchには、メトリクスを監視して、特定の条件になったときに状態を変化させるCloudWatch Alarmがあります。

例えば、

CPU使用率が80%以上になったら異常として扱う

という設定ができます。

イメージとしては、

CPU使用率
   │
   │       ●
80%│─────── アラーム条件
   │     ／
   │   ／
   │ ●
   └──────────── 時間

そして条件を満たした場合、

CloudWatch
   ↓
Alarm
   ↓
通知などのアクション

という流れを作ることができます。

---

▪️CloudWatch AlarmとSNS

CloudWatch Alarmは、Amazon SNSなどと組み合わせることで通知につなげることができます。

例えば、

EC2
 ↓
CPU使用率を監視
 ↓
80%以上
 ↓
CloudWatch Alarm
 ↓
SNS
 ↓
メールなどで通知

という構成です。

これによって、運用担当者が常にCloudWatchの画面を確認していなくても、異常を検知したときに通知を受け取ることができます。

---

▪️CloudWatchとEC2

EC2では、CloudWatchを利用してさまざまなメトリクスを確認できます。

代表的なものとして、

• CPU使用率
• ネットワーク関連のメトリクス
• EBS関連のメトリクス

などがあります。

例えば、

EC2
 │
 ├─ CPU使用率
 ├─ Network
 └─ EBS
       │
       ▼
   CloudWatch

という形です。

ただし、OS内部のすべての情報が自動的にCloudWatchへ送られるわけではありません。

例えば、Linuxサーバーのメモリ使用率など、OS内部の情報を詳しく監視したい場合には、CloudWatch Agentなどを利用する構成があります。

---

▪️CloudWatchとアプリケーション

CloudWatchはAWSリソースだけではなく、アプリケーションの監視にも利用できます。

例えばアプリケーションのログを、

アプリケーション
      ↓
ログ出力
      ↓
CloudWatch Logs

という形で収集できます。

そしてログを確認することで、

ERROR
WARN
INFO

などの情報を確認できます。

障害が発生したときに、

CloudWatch
   ↓
メトリクス確認
   ↓
異常を発見
   ↓
CloudWatch Logs
   ↓
エラー内容を確認

という流れで調査することもできます。

---

▪️CloudWatchとCloudTrailの違い

前回の記事で紹介したCloudTrailとCloudWatchは、名前が似ているため混乱しやすいです。

しかし、役割は異なります。

項目	CloudWatch	CloudTrail
主な役割	監視・状態把握	AWS操作の記録
見るもの	メトリクス・ログなど	API操作などのイベント
例	CPU使用率90%	誰かがEC2を作成した
目的	障害・性能・運用監視	監査・操作履歴・調査
代表的な確認	システムがどう動いているか	誰が何をしたか

簡単に覚えるなら、

CloudWatch＝システムを見る

CloudTrail＝操作を見る

です。

例えば、

「EC2のCPU使用率が高い」

ならCloudWatch。

「誰がEC2を作成したのか確認したい」

ならCloudTrailです。

---

▪️CloudWatchとS3の違い

CloudWatchとS3も役割が異なります。

S3は、

オブジェクトを保存するストレージサービス

です。

一方CloudWatchは、

AWSリソースやアプリケーションなどを監視するサービス

です。

例えば、

CloudWatch
↓
監視・ログ・アラーム

S3
↓
データ保存

という違いがあります。

ただし、CloudWatch LogsのログをS3へエクスポートするなど、組み合わせて利用することもできます。

---

▪️CloudWatchを使った障害調査

CloudWatchは、障害が発生したときにも非常に役立ちます。

例えば、

「Webサイトのレスポンスが急に遅くなった」

とします。

まずCloudWatchで、

CPU使用率
↓
急上昇していないか？

を確認します。

次に、

メモリ
ディスク
ネットワーク

など、関連する情報を確認します。

さらにアプリケーションログを、

CloudWatch Logs

で確認します。

すると、

CPU使用率上昇
       ↓
アプリケーションログ確認
       ↓
大量のエラーを発見
       ↓
原因を調査

というように、障害の原因を絞り込んでいくことができます。

---

▪️CloudWatchを使った運用

実際のAWS環境では、CloudWatchを単に「見るだけ」で終わらせるのではなく、異常を検知して運用につなげることが重要です。

例えば、

EC2
 ↓
CPU使用率を監視
 ↓
CloudWatch
 ↓
80%以上
 ↓
Alarm
 ↓
SNS
 ↓
運用担当者へ通知

という仕組みを作ることができます。

これによって、

「人間が気づく」

のではなく、

「システムが異常を検知して、人間に知らせる」

という運用ができます。

---

▪️CloudWatchを利用するときのポイント

CloudWatchを設計するときは、単純に大量のメトリクスやログを収集すればよいわけではありません。

例えば、

• 何を監視するのか
• どの程度の値を異常と判断するのか
• どのくらいの期間ログを保存するのか
• どのログを収集するのか
• 異常時に誰へ通知するのか
• 一時的なスパイクをどう扱うのか
• 監視コストをどう抑えるのか

などを考える必要があります。

特にアラームについては、

「どの値になったら異常なのか」

を適切に決めることが重要です。

例えば、

CPU使用率80%以上

だけで異常と判断すると、一時的な負荷上昇でもアラームが発生する可能性があります。

そのため、

CPU使用率80%以上
かつ
一定期間継続

のように、システムの特性に合わせて監視条件を設計することがあります。

---

▪️AWSの監視を考えてみる

ここまで紹介したAWSサービスを組み合わせると、AWSの運用イメージがかなり分かりやすくなります。

例えば、

                    AWS環境
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
     IAM          CloudWatch        CloudTrail
       │               │               │
       │          ┌────┴────┐          │
       │          ▼         ▼          │
       │      Metrics      Logs        │
       │          │         │          │
       │          ▼         ▼          │
       │        Alarm      Logs         │
       │          │                     │
       │          ▼                     │
       │         SNS                    │
       │                                │
       └──────── 権限・監視・監査 ────────┘

というように、それぞれ役割があります。

• IAM → 権限を管理
• CloudWatch → システムを監視
• CloudTrail → AWS操作を記録
• SNS → 通知などを行う

という関係です。

AWSのインフラを運用するうえでは、

「作って終わり」ではなく、「状態を監視して、異常を検知し、必要に応じて対応する」

ことが重要です。

---

▪️CloudWatchを理解すると運用が見えてくる

AWS初心者の段階では、

EC2を作る
S3を作る
RDSを作る

といった「構築」に目が行きがちです。

しかし、実際のインフラ運用では、

構築
 ↓
監視
 ↓
異常検知
 ↓
原因調査
 ↓
対応

という流れがあります。

CloudWatchは、この中でも特に、

監視・異常検知・ログ確認

を支える重要なサービスです。

そのため、AWSを学習するときには、

「AWSサービスを構築する知識」だけではなく、「構築したサービスをどう監視するのか」

まで考えることが重要です。

---

▪️まとめ

今回は、AWSのCloudWatchについて解説しました。

CloudWatchは、AWS上のリソースやアプリケーションなどを監視するためのサービスです。

ポイントを整理すると、

• CloudWatchはAWS環境やアプリケーションを監視する
• メトリクスによってシステムの状態を数値で確認できる
• CloudWatch Logsによってログを収集・確認できる
• CloudWatch Alarmによって異常を検知できる
• SNSなどと組み合わせて通知につなげられる
• EC2やRDS、ECSなどさまざまなAWSサービスと組み合わせて利用できる
• OS内部の情報を詳しく監視する場合はCloudWatch Agentなどを利用することがある
• CloudTrailはAWSの操作履歴、CloudWatchはシステムやリソースの監視という違いがある
• 監視では「何を」「どの条件で」「誰に通知するか」を設計することが重要

特に、

CloudWatch＝システムを見る

CloudTrail＝AWS上の操作を見る

という違いは覚えておきましょう。

AWSでは、システムを構築するだけではなく、「正常に動いているか」「異常が起きたときに気づけるか」「原因を調査できるか」まで考えることが重要です。

CloudWatchは、そのための中心的なサービスの一つです。

次回は、AWS上の通知を扱うAmazon SNSについて解説します。
＊「Amazon SNS」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのsnsとは？通知を配信する仕組みを初心者向けに/」