CloudWatch

このレッスンを終えると、Amazon CloudWatch (クラウドウォッチ) のメトリクス・ログ・アラームがそれぞれ何をするものかを説明でき、試験で「監視したい」と書かれた問題を迷わず選べるようになります。

自分でサーバーを建てたときは何をしていたか

自分で 1 台のサーバーを建てて運用したときのことを思い出してください。おそらく次のようなことを手作業で組んだはずです。

• ディスクの空きや CPU 使用率を df や top で確かめる
• 同じことを cron で定期実行して、結果をファイルに書き溜める
• アプリのログを /var/log の下に集めて、grep で障害の原因を探す
• 空き容量が 10 パーセントを切ったら自分宛にメールを飛ばすスクリプトを書く

この「数値を集める」「ログを集める」「しきい値を超えたら知らせる」の 3 つを、AWS 側のマネージドサービスとしてまとめて引き受けてくれるのが CloudWatch です。監視サーバーを別に建てる必要も、収集スクリプトを自分で保守する必要もありません。

CloudWatch の 3 つの顔

メトリクスは AWS の各サービスが標準で送ってきます。EC2 なら CPU 使用率やネットワーク転送量が最初から取れます。一方で メモリ使用率とディスク空き容量は EC2 の標準メトリクスに含まれません。これは AWS から見ると仮想マシンの中身であり、責任共有モデルで利用者側の領域だからです。取りたい場合は CloudWatch エージェントをインスタンスに入れます。ここは試験でもよく問われる線引きです。

アラームは「5 分間の平均 CPU 使用率が 80 パーセントを超えたら」のような条件で発火し、Amazon SNS への通知、EC2 の再起動や停止、Auto Scaling の増減といった動作につなげられます。つまり CloudWatch は見るだけでなく、伸縮の引き金にもなります。

ダッシュボードを作れば、複数のメトリクスをグラフとして 1 画面に並べられます。

試験ではこう出る

出題者は「CloudWatch」という単語を出さずに、次のような言い換えで聞いてきます。

• 「リソースの使用状況を監視したい」「メトリクスを収集したい」から CloudWatch
• 「CPU 使用率が一定の値を超えたら通知を受け取りたい」から CloudWatch アラーム
• 「アプリケーションのログを一元的に集めたい」から CloudWatch Logs
• 「定期的な処理を時刻で起動したい」から EventBridge (旧 CloudWatch Events)

引っ掛けの中心は CloudTrail との取り違えです。CloudWatch は「何が起きているか」を数値とログで見るもの、CloudTrail は「誰が操作したか」を記録するものです。問題文に「監査」「誰が」「API 呼び出し」が出たら CloudWatch ではありません。次のレッスンで詳しく整理します。

もう一つの頻出は、メモリ使用率を監視したいという問題です。標準メトリクスでは取れないので、CloudWatch エージェントの導入が答えになります。「エージェント不要で取れる」と書かれた選択肢は誤りです。

まとめ

• CloudWatch はメトリクス・ログ・アラームの 3 点を引き受けるマネージドな監視サービス
• EC2 のメモリとディスク空き容量は標準では取れず、CloudWatch エージェントが要る
• アラームは通知だけでなく、EC2 の再起動や Auto Scaling の起動にもつなげられる
• 「何が起きているか」が CloudWatch、「誰がやったか」は CloudTrail