旅行会社の新規事業開発部。
体験予約サービスは順調に成長し、アクセスも増えてきた。
CloudFrontで表示は速くなり、
Route 53で案内も整え、
EC2・EBS・EFS・S3でシステムは一通り完成。
――しかし、ある朝。
ケンイチ
「課長……ちょっといいですか。
今朝からサイトが“重い気がする”って問い合わせが来てて」
課長
「“気がする”か。
で、実際どうなってるかは分かる？」
ケンイチ
「……正直、分からないです。
今、ちゃんと動いてるのかどうかも」
課長は少し考えてから、こう言った。
課長
「それはね、“見えていない”のが問題だ。
サーバーは、黙ってても何も教えてくれないから」
ケンイチ
「え、でもEC2って起動してますよね？」
課長
「起動している、はスタートライン。
今どれくらい忙しいのか、苦しんでいるのかは別の話だ」
そう言って、ホワイトボードに新しい名前を書いた。
課長
「CloudWatchは、
サーバーやAWSサービスの“体調を見える化”する仕組みだ」
ケンイチ
「体調……？」
課長
「たとえば人間なら、
脈拍・体温・血圧を見るよね。
CloudWatchも同じで――」
CPU使用率（頭を使いすぎてない？）
メモリ・ディスクの使用状況
アクセス数の増減
エラーの回数
課長
「これをグラフで見られる。
しかもリアルタイムで」
ケンイチ
「なるほど……
“なんとなく重い”じゃなくて、
“CPUが90%超えてます”って言えるんですね」
課長
「そう。
原因が分かれば、対策も取れる」
課長
「CloudWatchは“見る”だけじゃない」
ケンイチ
「え、他にもあるんですか？」
課長
「たとえば――
“ある条件になったら、知らせる”」
CPUが80%を超えたら
エラーが急増したら
サーバーが落ちたら
👉 自動でメールや通知が飛ぶ
ケンイチ
「じゃあ……
ずっと画面を見張ってなくてもいい？」
課長
「そう。
人が監視する時代は終わりだ」
ケンイチは少し考えてから、素朴な疑問を口にした。
ケンイチ
「CloudWatchって、結局なにをしてくれるサービスなんですか？
“監視”って言われても、ピンと来なくて……」
課長はホワイトボードに三つの枠を書いた。
課長
「いい質問だ。
CloudWatchは1つのサービスだけど、中身は3つの役割に分かれている」
| 機能名 | 何をするもの？ | 主な役割 | たとえ |
|---|---|---|---|
| CloudWatch Logs | 記録を集める | アプリやサーバーの動作ログを保存する | 日記・ブラックボックス |
| CloudWatch Alarm | 異常を知らせる | 数値がしきい値を超えたら通知する | 目覚まし・警報アラーム |
| CloudWatch Events （※現在は EventBridge に統合） | きっかけで動かす | 状態変化をトリガーに処理を実行 | 自動ドア・スイッチ |
課長
「まず Logs で“何が起きたか”を記録する。
次に Alarm で“おかしくなった”ことに気づく。
そして Events で“じゃあどう動くか”を決める」
ケンイチ
「なるほど……
見る → 気づく → 自動で動く って流れなんですね」
課長
「そういうことだ。
CloudWatchは単なる“見張り役”じゃない。
運用を自動化するための土台なんだ」
これが分かれば、CloudWatchはもう怖くない」
Amazon CloudWatchは、
ほぼすべてのAWS利用企業が当たり前に使っているサービスです。
Webサービス運営企業
→ アクセス急増時にCPUやレスポンスを監視
ECサイト
→ エラー増加を検知して即対応
業務システム
→ 夜間バッチの失敗を自動通知
AWS公式の導入事例では、多くの企業が
EC2
ALB
RDS
とあわせて CloudWatchで監視・アラートを設定しています。
「障害に“気づくのが遅れる”」
これを防ぐための標準装備がCloudWatchです。
Amazon CloudWatchの主な役割はどれ？
A. サーバーの状態を見える化する
B. データを保存する
C. Webページを配信する
CloudWatchでできることとして正しいのは？
A. サーバーを起動する
B. 異常時に通知を送る
C. データベースを作る
CloudWatch Logsで分かるのは？
A. サイトのデザイン
B. アプリやサーバーの動作記録
C. 利用料金の支払い
クイズ1：A 異常時に通知を送る → サーバーやAWSの状態を可視化
クイズ2：B 異常時に通知を送る→ 条件を決めてアラート通知できる
クイズ3：B アプリやサーバーの動作記録→ トラブル原因を後から追える