Amazon CloudWatch
Amazon CloudWatch
概要
Amazon CloudWatch は、AWS リソースやアプリケーションのメトリクス・ログ・イベントを収集し、可視化・通知・自動アクションにつなげる監視・オブザーバビリティサービスです。CPU 使用率やリクエスト数などの数値メトリクスを時系列で追跡し、ログを一元的に集約・検索し、しきい値超過時にアラームで通知や自動対応を発火させます。多くの AWS サービスが標準でメトリクスを送るため、システムの健全性把握とトラブルシュート、コスト・性能の最適化の土台になります。
主要な概念
メトリクスとカスタムメトリクス
CloudWatch は EC2 の CPU 使用率や ELB のリクエスト数など、多数のサービスの標準メトリクスを自動収集します。OS 内部のメモリやディスク使用率など標準では取れない値は、CloudWatch エージェントやAPIでカスタムメトリクスとして送信します。メトリクスは時系列で集計・グラフ化でき、ダッシュボードで横断的に可視化できます。
アラームと自動アクション
メトリクスにしきい値と評価条件を設定したアラームは、状態が変化すると SNS 通知や Auto Scaling、EC2 アクションなどをトリガーできます。たとえば CPU が一定以上で台数を増やす、低下したら減らすといった自動スケーリングや、異常時のオペレーターへの通知を実現します。複合アラームで複数条件を組み合わせることもできます。
CloudWatch Logs
アプリケーションや各サービスのログをロググループ/ログストリームに集約し、保持期間の設定や検索ができます。Logs Insights を使えばクエリ言語でログを分析でき、メトリクスフィルターで特定パターンの出現回数をメトリクス化してアラーム化することも可能です。ログの長期保管には S3 へのエクスポートも使えます。
EventBridge との関係
かつての CloudWatch Events を発展させたものが Amazon EventBridge で、AWS サービスのイベントやスケジュールをルールでフィルタし、Lambda や SQS など多様なターゲットへ配信します。「毎日定時に処理を起動」「特定のリソース変化を検知して自動対応」といったイベント駆動の自動化に使われます。
監査ログとの違い（CloudTrail）
CloudWatch が「メトリクスとログによる性能・状態の監視」を担うのに対し、誰がいつどの API を呼んだかという操作の監査記録は AWS CloudTrail が担当します。両者は役割が異なり、CloudTrail のイベントを CloudWatch Logs に送って分析・アラーム化するなど、組み合わせて使うことも一般的です。
典型的なユースケース
- EC2やRDS、Lambdaなどのメトリクスを収集しダッシュボードで一元監視する
- CPU使用率のアラームをトリガーにAuto Scalingで台数を自動増減させる
- アプリログをCloudWatch Logsに集約し、Logs Insightsで障害を調査する
- しきい値超過時にSNS経由でオペレーターへ即時通知し、対応を早める
- EventBridgeのスケジュールで定期バッチを起動し、運用を自動化する
試験での出題観点
CloudWatch は SOA の中核であり、SAA・DVA でも運用設計として頻出します。「メトリクスを監視して自動でスケールしたい → CloudWatch アラーム + Auto Scaling」「ログを集約して調査したい → CloudWatch Logs / Logs Insights」が定番の対応です。標準では取得できないメモリ/ディスク使用率には CloudWatch エージェント（カスタムメトリクス）が必要、という点はSOAで頻出の落とし穴です。最重要の比較は「CloudWatch＝性能・状態の監視」と「CloudTrail＝API操作の監査記録」の役割分担で、設問が監視なのか監査なのかを読み分ける必要があります。定期実行や自動対応では EventBridge との連携も問われます。
関連サービス
最終更新日: 2026-06-24
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。