AWS 17：監視 ― CloudWatch で「壊れた」に先に気づく

CloudWatch は、AWS 全体の「計器盤」

CloudWatch（クラウドウォッチ）は、AWS のサービスの状態を集めて、見せて、おかしければ知らせるサービスです。ほとんどの AWS サービスは、何も設定しなくても自分の状態を CloudWatch へ送っています。図の灰色の線が、各部品から CloudWatch へ流れ込む情報のイメージです。

車の運転席にたとえるとわかりやすくなります。

この章は、この4つを順番に見ていきます。最後に、「どこで遅いのか」を探すトレース（X-Ray）の入口にも触れます。

CloudWatch はリージョン（第2章）ごとのサービスです。東京リージョンに作った構成の数字は、東京リージョンの CloudWatch で見ます。

メトリクス：決まった間隔で記録される「数字の列」

メトリクスは、ある数字を時間に沿って並べたものです。「3時00分に CPU 使用率 12％、3時05分に 15％……」のように、いつ・何が・いくつの点が並んでいます。図の棒の1本1本が、1つの点です。

1本のメトリクスは、次の3つで決まります。

同じ CPUUtilization でも、Web 1 と Web 2 ではディメンションが違うので、別の1本として記録されます。

数字を見たり、アラームに使ったりするときは、さらに2つを決めます。

たとえば「エラーの数」は5分の合計で、「CPU」は5分の平均で見る、というように、数字の性質に合った統計を選びます。「返事の時間」のように、一部の遅い利用者を見逃したくない数字では、平均ではなく p99（遅いほうから1％の位置の値）のようなパーセンタイルを使うこともできます。

何もしなくても届く数字と、届かない数字

AWS のサービスの多くは、主な数字を自動で CloudWatch へ送っています。フォトログの部品では、次のようになっています。

ここで1つ、よく驚かれる点があります。EC2 のメモリ使用率とディスクの空き容量は、自動では届きません。

理由は、それが OS（サーバーの中で動く基本ソフト）の中の数字だからです。AWS は仮想マシンの外側から CPU やネットワークは測れますが、OS の中でメモリがどう使われているかまでは見えません（見えないのは、あなたのサーバーの中を AWS が覗かないという意味でもあります）。

そこで、サーバーの中に CloudWatch エージェント（数字やログを集めて CloudWatch へ送る小さなプログラム）を入れます。エージェントが送る数字は、既定では CWAgent という名前空間に入り、カスタムメトリクス（自分で送る数字）として課金されます。

エージェントの設定は、ユーザーデータ（第9章）や自作の AMI（第10章）に入れておけば、Auto Scaling で増えた新しい台でも最初から動きます。EC2 には、エージェントが送信できる権限を持った IAM ロール（第3章）を付けておきます。

何を見張るか：原因より先に「利用者から見た症状」

数字は山ほど取れます。では、どれにアラームを付ければいいのでしょうか。

大事な考え方は、まず利用者から見た「症状」を見張ることです。「CPU が 90％」は、それだけでは問題かどうかわかりません。CPU をしっかり使って、全員に速く返事できているなら、むしろ効率がよい状態です。問題なのは、利用者が困っているときです。

利用者の困り方は、だいたい次の4つに分けられます。

これに対して、CPU・メモリ・DB の接続数・ログの中身は、なぜ困っているかを調べるときの手がかり（原因）です。

図の左（番号1）の症状で鳴らし、鳴ったら右（番号2）の原因を見に行く。この順番にすると、知らない原因で壊れたときでも、症状として必ず気づけるようになります。反対に、原因の数字にだけアラームを付けていると、思いもしなかった理由で壊れたとき、何も鳴りません。

なお「詰まり」は症状の一歩手前ですが、ディスクのように尽きた瞬間に全部止まるものは、症状が出る前に鳴らす価値があります。

フォトログで見張る数字を決める

前のページの考え方で、フォトログで見張る数字を決めます。入口の ALB は、すべてのリクエストが通る場所なので、利用者から見た症状を測るのにいちばん向いた場所です。

「決めた件数」「決めた秒数」は、サービスによって違います。最初は少し緩めに決め、1〜2週間ふだんの数字を眺めてから締めるのが現実的です。

ALB には HTTPCode_ELB_5XX_Count という似た名前の数字もあります。こちらは ALB 自身が返したエラー（後ろのサーバーが1台も健全でない、など）です。Target のほうはサーバーが返したエラーです。両方を見ると、どちらで壊れているかの見当がつきます。

ログ：「何が起きたか」を文章で残す

数字は「エラーが30件」と教えてくれますが、「どのエラーが、誰の、どの操作で」までは教えてくれません。それを残すのがログです。ログは、プログラムが出来事を1行ずつ書き残した記録です。

図の下の黒い板が、フォトログのアプリが書くログの例です。1行目は「写真の投稿（POST /photos）が成功（201）し、184ミリ秒かかった」、2行目は「画像の縮小に失敗した」という記録です。

ここで大事なのが、ログをサーバーの外へ送ることです。

そこで、CloudWatch エージェントでアプリのログを CloudWatch Logs へ送ります。こうすれば、台が消えてもログは残り、全台のログを1か所で探せます。

AWS のサービス自身もログを出せます。たとえば ALB のアクセスログ（誰がいつどこに来たか）は S3（第15章）へ、RDS のエラーログは CloudWatch Logs へ送る設定ができます。

ロググループとログストリーム

CloudWatch Logs には、ログを入れる棚が3段あります。

図では、ロググループ /photolog/app の中に、Web 1・Web 2・入れ替わった新しい台のストリームが並んでいます。台が入れ替わっても、同じロググループに新しいストリームが増えるだけで、過去のストリームは残ります。

図の右下に赤で書いたとおり、ロググループの保存期間は、既定で「無期限」です。つまり、何もしなければログは永遠にたまり続けます。これはお金の話につながるので、後で詳しく見ます。

ログは、できれば1行を JSON（{"level":"error","user":"u_81","msg":"..."} のような、項目名と値の組の形）で書いておくと、後で項目ごとに絞り込んだり数えたりしやすくなります。

たまったログから探す：Logs Insights

ログを集めたら、次は探します。CloudWatch Logs Insights は、ロググループに対して問い合わせの文（クエリ）を投げ、条件に合う行を探したり、数えたりする機能です。

図の左上は、「ERROR を含む行を、5分ごとに数える」クエリです。

結果を見ると、図の右のように3時10分ごろにエラーが急に増えています。この時刻に何があったか（新しい版を出した、利用者が急に増えた、など）と突き合わせれば、原因にぐっと近づけます。

Logs Insights は、問い合わせで読んだログの量に応じて課金されます。期間を「過去30日」にして巨大なロググループを何度も検索すると、思ったより高くつくことがあります。期間を絞ってから検索するのが基本です。

ログから数字を作る：メトリクスフィルター

「ERROR という行が5分で20回以上出たら鳴らしたい」。こう思ったとき、ログのままではアラームを付けられません。アラームが見張れるのは数字（メトリクス）だけだからです。

そこで使うのがメトリクスフィルターです。ロググループに「この文字列（やパターン）を見つけたら、この数字を1増やす」という決まりを付けておくと、ログが届くたびに数えて、メトリクスにしてくれます。

こうして作った AppErrors には、他のメトリクスと同じようにアラームを付けられます。アプリのコードに手を入れず、すでに出しているログから数字を作れるのが利点です。

作った数字はカスタムメトリクスとして課金されます。細かく分けて何百本も作ると、それだけで費用がかさみます。

アラーム：しきい値を超え続けたら鳴る

アラームは、1本のメトリクスを見張り、決めた線（しきい値）を超えたら状態を変えて知らせる仕組みです。

ただし、1回だけ跳ねた数字でいちいち鳴っていたら、うるさくて仕方ありません。そこで CloudWatch のアラームは、次の組み合わせで「鳴らす条件」を決めます。

この「N 点のうち M 点」という決め方が大事です。図の左側のように、1点だけ線を超えても鳴りません。右側のように、超えた状態が続いたときだけ鳴ります。

M と N を大きくすると誤報は減りますが、気づくのが遅れます。小さくすると早く気づけますが、誤報が増えます。どれだけ早く知りたいかとどれだけ誤報に耐えられるかの釣り合いで決めます。

アラームの状態は3つ

アラームは、いつも次の3つのどれかの状態にいます。

通知を送ったり、何かの操作をしたりするのは、状態が変わったときです。OK から ALARM に変わったときに「壊れた」、ALARM から OK に戻ったときに「直った」を知らせるように設定できます。

もう1つ、データが届かないときの扱いを決められます。

ALB のエラー件数は、エラーが0件の時間には点が送られません。これを既定のままにすると、平和なときほど「データ不足」になってしまいます。エラー件数には notBreaching を選ぶのが定番です。

鳴ったら知らせる：SNS でメールやチャットへ

アラームが ALARM になっても、画面を見ていなければ気づけません。そこで、アラームに通知を付けます。通知には Amazon SNS（Simple Notification Service）を使います。

SNS は「トピック」という掲示板のようなものを作り、そこに購読者（メールアドレス、チャットへの転送、スマホへの SMS など）を登録しておくと、トピックに届いた知らせを購読者全員に配ってくれるサービスです。

図では、Web 2 の故障でアラームが鳴り、CloudWatch から SNS、そしてメールとチャットへ知らせが配られています。

メールで購読すると、最初に確認のメールが届きます。そのリンクを押すまで、通知は届きません。作っただけで安心しないことが大事です。

アラームは知らせるだけでなく、操作もできます。

ダッシュボード：大事な数字を1枚に並べる

障害が起きて通知が届いたとき、まず何を見るでしょうか。そのとき慌てて数字を1本ずつ探さなくて済むように、大事な数字を1枚の画面に並べておくのがダッシュボードです。

並べ方のコツは、見る順番どおりに置くことです。

図のダッシュボードでは、すべてのグラフが同じ時刻に跳ねています。症状と原因を同じ時間の軸で並べておくと、「5xx が増えた時刻に、DB の接続数も増えている」のようなつながりがすぐに見えます。

ダッシュボードは、コンソールの CloudWatch の画面で、グラフを足していくだけで作れます。あるいは、設定を JSON で書いて作ることもできます。JSON で書けるということは、次の第18章で扱う「構成をコードにする」の対象にもできる、ということです。

作ってみる：通知先とアラームを CLI で

ここまでの部品を、CLI（第1章）で作ってみます。コンソールでも同じ項目を画面で選ぶだけです。

図の板は2つの手順に分かれています。

アラームの設定の意味は次のとおりです。

LoadBalancer のディメンションの値は、ALB の ARN の末尾（app/名前/ID の部分）です。

作ったら、わざと鳴らして通知が届くことを確かめておくと安心です。CLI の aws cloudwatch set-alarm-state で、アラームの状態を一時的に ALARM にできます。

どこで遅いのか：トレース（X-Ray）の入口

アラームで「写真の投稿が遅い」とわかりました。では、どこで遅いのでしょうか。ALB？アプリ？DB？S3？ メトリクスは部品ごとの数字なので、1つのリクエストが部品をまたいで流れる様子は見えません。

そこで使うのがトレースです。トレースは、1つのリクエストが通った道と、各区間にかかった時間を記録したものです。AWS では AWS X-Ray がトレースを集めて見せてくれます。

図は、写真の投稿1回ぶんのトレースを横棒で並べたものです。

こうして犯人の区間がわかれば、直す場所がはっきりします。フォトログの場合、画像の縮小を投稿のたびにその場で待たせずに、後回しにするのが解決策です。これは第24章（非同期）で扱います。

トレースを取るには、アプリに計装（記録を取るための仕組みを組み込むこと）が要ります。2026年時点では、業界標準の OpenTelemetry（AWS 版は ADOT：AWS Distro for OpenTelemetry）で計装するのが推奨です。X-Ray 独自の SDK とデーモンは 2026年2月から保守のみの段階に入り、2027年2月に提供終了の予定です。これから始めるなら OpenTelemetry を選びます。

お金：何に課金されるか

CloudWatch の料金は、使う道具ごとに単位が違います。

いくつかの項目には無料枠があり、小さなサービスなら無料枠でかなりの部分が収まります。単価と無料枠の量は変わるので、CloudWatch の料金ページで確認してください。

気をつけたいのは、いちばん膨らみやすいのはログだという点です。1リクエストごとに何行もログを書くと、利用者が増えるにつれて取り込み量がそのまま増えます。「デバッグ用の細かいログは本番では出さない」「必要な項目だけ書く」を心がけます。

CloudWatch Logs には、取り込みの単価が安い Infrequent Access（あまり検索しないログ向け）という種類もあります。できる機能が一部限られるので、使い分けは料金ページと公式ドキュメントで確かめます。

ログの保存期間は、既定で「無期限」

ロググループの保存期間は、何も設定しないと無期限です。ログは消えずにたまり続け、保存料も毎月少しずつ増えていきます。図の赤い棒のように、何年も経つと「誰も読まないログに毎月払っている」状態になります。

そこで、ロググループを作ったらすぐに保存期間を決めます。1日から10年までの決まった日数から選べます。

設定は、図の右下のコマンド1行でできます（コンソールでも、ロググループの「保持期間」から変えられます）。

保存期間を過ぎたログは削除の対象になります。すぐに消えるわけではなく、少し時間がかかることがありますが、対象になった時点からは保存料がかかりません。

よくある落とし穴

監視は「付けたつもり」になりやすい仕組みです。よくある失敗を並べます。

図のいちばん下の、緑の印の項目が、この章でいちばん伝えたいことです。鳴らすのは症状に絞り、原因はダッシュボードで見る。これだけで、アラームは「うるさいだけのもの」から「信頼できる知らせ」に変わります。

片付け：練習で作った監視を消す

この章で練習のために作ったものは、次の順で消します。フォトログの構成そのもの（ALB・EC2・RDS など）の片付けは、第16章を見てください。

カスタムメトリクスには「削除する」操作がありません。送るのをやめれば、やがて課金の対象から外れ、数字もしばらくすると見えなくなります。メトリクスフィルターは、ロググループを消すと一緒に消えます。

ロググループを消すと、中のログは戻せません。調査に使うログが残っていないか確かめてから消してください。