概要
AWS 上でシステムを運用する際、リソースの状態やパフォーマンスを把握することは不可欠です。CPU 使用率が異常に高い、ディスク容量が逼迫している、API のエラーレートが上昇しているといった状況に気づけなければ、障害の発見や対応が遅れ、サービスに影響を与える可能性があります。
Amazon CloudWatch は、AWS リソースやアプリケーションの監視サービスです。EC2 インスタンスの CPU 使用率、RDS のデータベース接続数、Lambda 関数の実行回数など、さまざまなメトリクス（数値データ）を自動的に収集し、グラフで可視化できます。さらに、メトリクスにしきい値を設定してアラームを作成し、異常検知時に SNS 通知や Auto Scaling アクションなどを自動的にトリガーできます。
本記事では、CloudWatch の基本概念を理解し、EC2 インスタンスのメトリクス確認とアラーム設定を通じて、AWS リソースの監視方法を体験します。
この記事のメリット
- CloudWatch のメトリクス画面で EC2 インスタンスの CPU 使用率やネットワーク通信量を確認する方法を習得できる
- 名前空間・メトリクス・ディメンションといった CloudWatch の基本概念を理解できる
- アラームを作成し、しきい値超過時に SNS トピックへ通知を送る設定を体験できる
- CloudWatch ダッシュボードを作成し、複数のメトリクスを一画面で監視する方法を把握できる
- 運用監視の基礎的な仕組みを理解できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
Amazon CloudWatch とは
クラウドおさるとひさん、今日は CloudWatch について教えてほしいです。AWS のリソースを監視するサービスっていうのはなんとなく知ってるんですけど、具体的にどんなことができるんですか？
土肥CloudWatch は、AWS リソースとアプリケーションのモニタリングサービスだよ。メトリクスの収集・可視化、アラームによる異常検知、ログの集約・分析など、運用監視に必要な機能を統合的に提供してくれるんだ。
クラウドおさるなるほど、監視に必要な機能がひとまとめになってるんですね。どんなユースケースがあるんですか？
土肥主なユースケースはこんな感じだよ。
- リソース監視（CPU 使用率、メモリ使用量、ディスク I/O の監視）
- 異常検知と自動対応（アラームによる通知や Auto Scaling のトリガー）
- ログの集約と分析（CloudWatch Logs によるアプリケーションログの管理）
- ダッシュボードによる可視化（運用チーム向けの統合ビュー）
クラウドおさるCPU が上がりすぎたら通知してくれたり、ログをまとめて分析できたりするんですね。運用には欠かせなさそうです。
土肥そのとおり。AWS でシステムを運用するなら、CloudWatch は真っ先に押さえておきたいサービスだね。
メトリクス
クラウドおさるさっき「メトリクス」って言葉が出てきましたけど、これは何ですか？
土肥メトリクスは、CloudWatch に発行される時系列のデータポイントのことだよ。AWS サービスはデフォルトでさまざまなメトリクスを CloudWatch に送信してくれるんだ。
クラウドおさる自動で送ってくれるんですね。メトリクスってどうやって区別するんですか？
土肥メトリクスは以下の 3 つの要素で一意に識別されるよ。
| 要素 | 説明 | 例 |
|---|---|---|
| 名前空間（Namespace） | メトリクスのグループ。AWS サービスごとに定義される | AWS/EC2、AWS/RDS、AWS/Lambda |
| メトリクス名 | 測定対象の名前 | CPUUtilization、NetworkIn、StatusCheckFailed |
| ディメンション | メトリクスを細分化するキーと値のペア | InstanceId: i-0123456789abcdef0 |
クラウドおさる名前空間でサービスを分けて、メトリクス名で測定対象を指定して、ディメンションでさらに細かく絞り込むんですね。
土肥そうそう。たとえば「EC2 の、CPU 使用率の、このインスタンスのやつ」って感じで特定できるようになってるんだ。
メトリクスの保持期間と解像度
クラウドおさるメトリクスのデータって、ずっと残るんですか？
土肥実はデータポイントの間隔（期間）によって保持期間が決まっているんだ。
| データポイントの期間 | 保持期間 |
|---|---|
| 1 秒（高解像度） | 3 時間 |
| 60 秒（1 分） | 15 日間 |
| 300 秒（5 分） | 63 日間 |
| 3600 秒（1 時間） | 455 日間（15 か月） |
クラウドおさる細かいデータほど早く消えるんですね。1 秒単位だと 3 時間しか持たないんだ。
土肥そうなんだ。ちなみに EC2 の基本モニタリングでは 5 分間隔、詳細モニタリングを有効化すると 1 分間隔でメトリクスが送信されるよ。
クラウドおさる基本は 5 分間隔で、もっと細かく見たいときは詳細モニタリングに切り替えればいいんですね。
アラーム
クラウドおさるメトリクスを見て異常に気づけるのはわかったんですけど、ずっと画面を見てるわけにもいかないですよね？
土肥そこで活躍するのがアラームだよ。CloudWatch アラームは、メトリクスの値を監視して、指定したしきい値を超えたら自動でアクションを実行してくれる機能なんだ。
クラウドおさるアラームにはどんな状態があるんですか？
土肥アラームには 3 つの状態があるよ。
| 状態 | 説明 |
|---|---|
OK | メトリクスがしきい値の範囲内 |
ALARM | メトリクスがしきい値を超過 |
INSUFFICIENT_DATA | データが不足しており判定できない |
クラウドおさるOK と ALARM はわかりやすいですね。INSUFFICIENT_DATA は、まだデータが集まってないときの状態ですか？
土肥そのとおり。アラームを作成した直後はこの状態になることが多いよ。そして ALARM 状態になると、こんなアクションを実行できるんだ。
- SNS トピックへの通知（メール送信など）
- Auto Scaling ポリシーの実行
- EC2 インスタンスの停止・終了・再起動
- Systems Manager の Incident Manager への通知
クラウドおさるメール通知だけじゃなくて、Auto Scaling を動かしたり、インスタンスを自動で止めたりもできるんですね。すごい便利です。
土肥通知して終わりじゃなくて、自動で対処までできるのが CloudWatch アラームの強みだね。
ダッシュボード
クラウドおさるメトリクスもアラームも個別に見るのは理解できたんですけど、まとめて一覧で見たいときはどうするんですか？
土肥CloudWatch ダッシュボードを使うといいよ。メトリクスのグラフやアラームの状態をウィジェットとして配置して、一画面で確認できるカスタマイズ可能なビューなんだ。
クラウドおさる自分で好きなようにレイアウトできるんですね。
土肥そうだよ。しかも複数のリソースやリージョンのメトリクスを 1 つのダッシュボードにまとめて表示できるから、運用チームの統合モニタリング画面として活用できるんだ。
クラウドおさる東京リージョンとバージニアリージョンのメトリクスを 1 つの画面で見られるのは助かりますね。実践で実際に作ってみるのが楽しみです。
実践
前提条件
- リージョン:
ap-northeast-1（東京） - EC2 インスタンスが 1 台起動済みであること
- IAM ユーザーまたはロールに CloudWatch、EC2、SNS の操作権限があること
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| SNS トピック | cloudwatch-alarm-topic | アラーム通知の送信先 |
| CloudWatch アラーム | high-cpu-alarm | CPU 使用率の監視 |
| CloudWatch ダッシュボード | ec2-monitoring | EC2 メトリクスの可視化 |
ステップ1: EC2 メトリクスの確認
まず、CloudWatch で EC2 インスタンスのメトリクスを確認します。
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
CloudWatchと入力し、表示された「CloudWatch」を選択します - 左側ナビゲーションの「メトリクス」→「すべてのメトリクス」を選択します
- メトリクス画面の下部「参照」タブに、名前空間ごとのカード（EC2、EBS、S3 など）が表示されます。「EC2」を選択します
- 「インスタンス別メトリクス」を選択します
- 監視対象の EC2 インスタンスの
CPUUtilizationにチェックを入れます - 上部のグラフに CPU 使用率の推移が表示されます
- グラフ上部の期間設定で「1h」「3h」「12h」などを切り替えると、表示期間を変更できます
- 「統計」列のドロップダウンから「Average」「Maximum」「Minimum」を切り替えることで、集計方法を変更できます
ステップ2: SNS トピックの作成
アラーム通知の送信先となる SNS トピックを作成します。
- 上部の検索バーに
SNSと入力し、表示された「Simple Notification Service」を選択します - 左側ナビゲーションの「トピック」を選択します
- 「トピックの作成」をクリックします
- 以下の項目を入力します
- タイプ:
スタンダード（初期状態では FIFO が選択されているので切り替えます） - 名前:
cloudwatch-alarm-topic - 表示名:
CloudWatch Alarm - その他の項目はデフォルトのままにします
- 「トピックの作成」をクリックします
- トピックの詳細画面が表示されたら、「サブスクリプションの作成」をクリックします
- 以下の項目を入力します
- プロトコル:
E メール - エンドポイント: 通知を受信するメールアドレスを入力
- 「サブスクリプションの作成」をクリックします
- 入力したメールアドレスに確認メールが届くので、メール内の「Confirm subscription」リンクをクリックしてサブスクリプションを確定します
ステップ3: CloudWatch アラームの作成
EC2 インスタンスの CPU 使用率が一定のしきい値を超えた場合に通知を送るアラームを作成します。
- 上部の検索バーに
CloudWatchと入力し、「CloudWatch」を選択します - 左側ナビゲーションの「アラーム」→「すべてのアラーム」を選択します
- 「アラームの作成」をクリックします
- 「メトリクスの選択」をクリックします
- 「EC2」→「インスタンス別メトリクス」を選択します
- 監視対象の EC2 インスタンスの
CPUUtilizationを選択し、「メトリクスの選択」をクリックします
- 「メトリクスと条件の指定」画面で以下を設定します
- 統計:
平均値 - 期間:
5 分 - しきい値の種類:
静的 - アラーム条件:
以上 - しきい値:
80（CPU 使用率が 80% 以上で発火）
- 「次へ」をクリックします
- 「アクションの設定」画面で以下を設定します
- アラーム状態トリガー:
アラーム状態 - SNS トピックの選択: 「既存の SNS トピックを選択」を選択
- 通知の送信先:
cloudwatch-alarm-topicを選択 - その他のアクションは設定しません
- 「次へ」をクリックします
- アラーム名に
high-cpu-alarmと入力します - 「次へ」をクリックし、確認画面で内容を確認して「アラームの作成」をクリックします
- アラーム一覧に
high-cpu-alarmが表示され、状態がデータ不足になっていることを確認します（データが蓄積されるとOKに変わります）
ステップ4: アラームの動作確認
アラームの動作を確認するため、EC2 インスタンスに負荷をかけて CPU 使用率を上昇させます。
- EC2 コンソールから対象インスタンスに接続します（EC2 Instance Connect やセッションマネージャーを使用）
- 以下のコマンドを実行して CPU に負荷をかけます
# CPU 負荷をかける（stress コマンドがない場合は yes コマンドで代替）
yes > /dev/null &- CloudWatch コンソールに戻り、「すべてのアラーム」を選択します
- 数分後、
high-cpu-alarmの状態がOKからアラーム状態に変わります
- SNS サブスクリプションで設定したメールアドレスにアラーム通知メールが届いていることを確認します
- 負荷テストを停止します
# バックグラウンドで実行中の yes コマンドを停止
kill %1- 数分後、CPU 使用率がしきい値を下回ると、アラームの状態が
OKに戻ります
ステップ5: ダッシュボードの作成
複数のメトリクスを 1 つの画面で監視するためのダッシュボードを作成します。
- 左側ナビゲーションの「ダッシュボード」を選択します
- 「ダッシュボードの作成」をクリックします
- ダッシュボード名に
ec2-monitoringと入力し、「ダッシュボードの作成」をクリックします
- ウィジェットの追加画面が表示されます。データソースで「メトリクス」を選択し、「次へ」をクリックします
- メトリクスの選択画面で「EC2」→「インスタンス別メトリクス」を選択し、対象インスタンスの
CPUUtilizationにチェックを入れます（グラフの種類は右上のドロップダウンで「線」のままにします） - 「ウィジェットの作成」をクリックします
- ダッシュボード上部の「+」アイコンをクリックして、さらにウィジェットを追加します
- 同様の手順で、以下のメトリクスのウィジェットを追加します
NetworkIn（ネットワーク受信バイト数）NetworkOut（ネットワーク送信バイト数）StatusCheckFailed（ステータスチェック失敗）- ウィジェットの配置をドラッグ＆ドロップで調整し、右上の「保存」をクリックします（保存するまでダッシュボードの変更は確定しません）
まとめ
- Amazon CloudWatch は、AWS リソースとアプリケーションのモニタリングサービスで、メトリクスの収集・可視化・アラームによる異常検知を統合的に提供します
- メトリクス は名前空間・メトリクス名・ディメンションの 3 要素で識別される時系列データです
- アラーム はメトリクスのしきい値を監視し、
OK・ALARM・INSUFFICIENT_DATAの 3 状態を遷移します - アラームが
ALARM状態になると、SNS 通知や Auto Scaling アクションなどを自動実行できます - ダッシュボード を使うと、複数のメトリクスやアラームを 1 つの画面にまとめて監視できます
- EC2 の基本モニタリングでは 5 分間隔、詳細モニタリングでは 1 分間隔でメトリクスが送信されます
参照先
- Amazon CloudWatch とは – Amazon CloudWatch
- Amazon CloudWatch の概念 – Amazon CloudWatch
- Amazon CloudWatch アラームの使用 – Amazon CloudWatch
- Amazon CloudWatch ダッシュボードの使用 – Amazon CloudWatch
- インスタンスの利用可能な CloudWatch メトリクスのリスト表示 – Amazon EC2
