

AWSを利用する企業などにとって、インフラやアプリケーションの健全性の把握は重要です。サーバーのCPU使用率が急に上昇したり、アプリケーションのレスポンスが遅くなったりしたときに、いち早く気付けなければサービス停止や顧客離れにつながります。
そこで利用したいAWSのサービスがAmazon CloudWatch(クラウドウォッチ)です。これにより、リソースのパフォーマンスやアプリケーションの挙動を一元的に把握できます。今回は、CloudWatchの概要、使い方、活用Tips、注意点まで解説します。
目次 <Contents>
CloudWatchとは何か
最初にCloudWatchとは、どういったAWSのサービスであるかについて解説します。
CloudWatchの概要
Amazon CloudWatchは、EC2やRDSなどのAWSリソースやアプリケーションからメトリクス・ログを自動収集できるサービスです。また、グラフやダッシュボードで可視化、しきい値を超えた際の通知や自動アクション実行まで一元的に実装できます。さらにカスタムメトリクスや外部環境のデータも取り込み、アラーム・ログ分析・ユーザー体験監視など多彩な機能を備えていることが特徴です。AWSの運用には必須のサービスであり、運用の健全性やパフォーマンス管理を強力に支援してくれます。
主な特徴
CloudWatchはさまざまな使い方がありますが、それを踏まえた特徴をまずは紹介します。
AWSサービスとの高い親和性
CloudWatchはEC2・RDS・Lambda・S3など、多数のAWSサービスに標準で対応しています。そのため、追加設定なしでメトリクスやログを自動収集できることが特徴です。リソース追加時も自動で監視対象に含まれるため、導入・運用コストを抑えつつ、環境全体の状態を一元的に把握できます。
メトリクス・ログの統合管理
メトリクス(時系列データ)とログを同じ基盤に収集・管理できるサービスです。そのため、性能指標とエラーログを相関させて分析できます。たとえば、CloudWatch Logs Insightsでリアルタイム検索・集計することが可能です。また、それを用いてトラブルシューティングや傾向把握を実施するなどが考えられます。
柔軟なアラームと自動化
しきい値超過の通知はもちろん、複合アラームや異常検知など高度な条件設定に対応していることが特徴です。たとえば、SNS通知やLambda・EventBridgeと連携させた設計に対応しています。これらを活用すると、検知から対応までを自動化でき、人的負荷の軽減につながるのです。
カスタマイズ可能なダッシュボード
複数のメトリクスやログ結果を1画面にまとめたダッシュボードを作成できます。クロスアカウント・クロスリージョンでの集約や、ビジネス指標を含めた独自ウィジェットの配置も可能です。作成には少し慣れやコツが必要ですが、ダッシュボードを用いることで、状況を共有しやすくなります。
CloudWatchの主な機能
最初にCloudWatchの特徴を紹介しましたが、続いては主な機能について具体的に解説します。
メトリクス(Metrics)
CloudWatchはEC2やRDSなどの標準メトリクスを自動的に収集できます。名前空間やディメンションなどで整理され、平均・合計・最小・最大・百分位などを扱えることが特徴です。カスタムメトリクスを作成すれば、業務KPIなど独自の指標も可視化できるようになります。
他にもMetric Mathと呼ばれる機能があり、複数指標を演算することが可能です。エラー率やSLA達成率など派生指標を作ってアラームやダッシュボードの作成に活用できます。
保存期間はデータ粒度によって変わり、1分間隔データは15日間、5分間隔は63日間、1時間間隔は15か月保存されます。長期分析が必要な場合はS3にエクスポートしてAthenaで分析するのが一般的です。
ログ(Logs)
アプリやOSからのログをCloudWatch Logsに転送できます。保持期間はポリシーで制御し、不用分は自動で削除することも可能です。専用クエリを利用すれば高速検索や集計も可能であり、単なるログ収集機能にはとどまらない機能を有しています。現地から原因の特定までを一気通貫で処理できる機能とも言えるのです。
アラーム(Alarms)
メトリクスにしきい値を設定し、条件を超えたら通知やアクションを実行します。たとえば「CPU使用率が80%を5分間超えたら通知」などです。SNSでメール通知したり、Lambdaを起動して自動スケールアウトさせるなど、柔軟に対応が可能です。さらに複合アラームを使えば「CPU使用率が高いANDネットワーク帯域も逼迫している」といった複合条件も検知できます。
ダッシュボード(Dashboards)
CloudWatch Dashboardsを使えば、複数のメトリクスやログを一枚の画面で可視化できます。CPU・メモリ・ディスク使用量を並べて見たり、サービス別にグラフを配置したりすることが可能です。折れ線・数値・棒・散布など多彩なウィジェットを組み合わせ、サービス別/役割別ビューを最適化できる機能です。
しかも、クロスアカウント/クロスリージョン集約にも対応しています。大量のAWS環境を運用する場合でも、全体健全性・SLO・容量傾向を一目で共有できるのです。
CloudWatchの基本的な使い方
具体的にCloudWatchを利用する際の基本的なフローを解説します。
メトリクスの確認

AWSコンソールでCloudWatchを開き、「メトリクス」タブからEC2やRDSなどのパフォーマンス指標を確認できます。
ログ収集の設定
EC2にCloudWatchエージェントをインストールすることで、ログを転送できるようになります。また、Lambda関数などは、ログが自動でCloudWatch Logsに転送される仕組みです。EC2からのログ転送は難しい作業ではなく、簡単にログ収集を設定できます。
アラーム設定
CPU使用率やメモリ使用率に対してしきい値を設定し、超過時にSNSで通知させることが可能です。アラームを作成する際は「アラームの作成」か設定したいメトリクスを選択します。しきい値の条件も設定しましょう。

続く画面では、アラームを検知した際の動作を設定できます。一般的には赤枠の部分でSNSトピックを利用した通知を設定しますが、それ以外の動作を設定しても差し支えありません。

入力が完了すれば、設定値を確認してアラームを作成するだけです。
ダッシュボード作成

必要なメトリクスを選び、グラフや数値ウィジェットを配置してダッシュボードを作成できます。事前にダッシュボードを作成しておけば、必要な情報が一目瞭然です。その都度、メトリクスを検索して確認する手間がなくなります。
CloudWatchの活用Tips
上記ではCloudWatchの標準的な使い方を解説しました。続いては、活用に向けたTipsについても解説します。
複合アラームで誤検知を減らす
単一メトリクスだけでアラームを設定すると、スパイク的な一時的変動で誤検知が起こりがちです。しかし、複合アラームを使うとこの問題を解決しやすくなります。たとえば、複数のアラーム条件をAND/ORで組み合わせ、実際に障害が起きている可能性の高い状態だけを通知するのです。
- 「CPU使用率が80%以上」かつ「ネットワーク帯域使用率が80%以上」
- 「HTTP 5xxエラーが一定時間連続」かつ「レスポンス遅延が閾値超過」
必要に応じて「OKに戻った通知」も設定して、復旧状況を追跡しましょう。
ログ保持期間を最適化
CloudWatch Logsはログの保存期間が長いほどコストがかかります。重要度の低いログは短期間(数日〜数週間)にし、重要な監査用ログはS3にエクスポートして長期保存する運用が一般的です。S3にエクスポートする場合、以下の手順で設定します。
CloudWatchコンソールで「ロググループ」をクリックし、対象のロググループを選択します。

保持期間の設定をクリックし、必要な期間へ変更します。

続いて、重要なログは「アクション」→「データをS3にエクスポート」からエクスポートタスクを作成します。赤枠の部分に出力先を指定してください。なお、別のアカウントが有するS3にエクスポートできるため、運用アカウントとログ蓄積アカウントを分離するような運用も可能です。

CloudWatchとCloudTrailの違い
CloudWatchとCloudTrailはどちらもAWS環境の可視化・管理に役立ちます。ただ、対象や目的が違うため、それぞれを適切に設定、運用しなければなりません。
まず、CloudWatchはEC2やRDSなどAWSリソースの、ログ、メトリクスをリアルタイムに収集・監視するサービスです。また、しきい値超過時に通知や自動アクションを実行することでシステムの健全性を維持します。
一方、CloudTrailはユーザーやサービスがどの操作(APIコール)をいつ・どこから実行したかを記録する監査ログサービスです。主に、変更履歴の追跡やセキュリティインシデント調査に活用されます。
CloudWatchを導入するメリット
CloudWatchを導入するメリットは大きく3つあげられます。
AWSとの高い親和性
CloudWatch は EC2・RDS・Lambda・S3 など70以上の AWS サービスに標準対応しています。そのため、追加設定なしでメトリクスやログを自動収集できることがメリットです。また、新しいリソースを作成しても即座に監視対象となるため、監視設計やメンテナンスの負荷が大幅に軽減できます。
マネージド型サービス
一般的な監視サービスと異なり、サーバー構築やソフトウェアのインストールが不要な完全マネージド型サービスです。インフラの準備に時間をかけず、コンソールやAPIからすぐに利用を開始できます。高可用性やセキュリティパッチもAWSが管理するため、監視基盤そのものの運用コストを抑えられることもメリットです。
自動化に対応
メトリクス監視・アラーム発報・SNS通知・Lambda連携など一連の流れを一気通貫で自動化できます。たとえば、しきい値超過時にインスタンスを増減させたり、復旧スクリプトを起動するなどです。検知から対応まで人手を介さずに処理できるため、運用負荷と対応遅延のリスクを減らせます。
CloudWatchを導入する際の注意点
CloudWatchの導入には注意点もあるため意識しましょう。
AWS外リソースの監視には追加設定が必要
オンプレミスや他クラウドのサーバー・アプリを監視する場合はCloudWatchエージェントの導入やログ転送設定が必要です。標準ではAWSリソースのみ自動収集されます。外部環境を含めた監視を実現したい場合は、CloudWatchが最適な選択であるか一考したほうが良いでしょう。
コスト管理が重要
CloudWatchはメトリクス数・ログ保存量・クエリ実行数に応じて従量課金されます。そのため、カスタムメトリクスや長期ログ保存が増えると費用が膨らみがちです。保持期間の調整や不要メトリクスの削除、S3へのエクスポートなどでコスト最適化を意識することが欠かせません。
まとめ
CloudWatchはAWS運用に不可欠ともいえる監視基盤です。まずは標準メトリクスと簡単なアラームから始め、徐々にログ分析、ダッシュボード、自動化連携へと発展させていきましょう。運用を効率化し、システムの安定性を高めるためにも、CloudWatchを最大限に活用することが重要です。