Amazon CloudWatch

は、AWS リソースやアプリケーションの、ログ、、ダッシュボードを扱う監視サービスです。、、、など多くの AWS サービスから標準メトリクスを収集し、しきい値を超えたときに通知や自動アクションを実行できます。

SAA では、CloudWatch は「運用負荷を抑えて監視したい」「使用率やネットワークなどのメトリクスを可視化したい」「しきい値を超えたら通知やを動かしたい」という文脈でよく出ます。自前の cron、、、（旧 Amazon QuickSight）などを組み合わせるより、まず CloudWatch の標準機能で満たせないかを考えます。

Point

CloudWatch は「クラウド上の状態を見る」ための監視サービスです。
Watch は「見る」「監視する」という意味です。
試験では、メトリクス、ログ、アラーム、ダッシュボードをまとめて扱うサービスとして覚えます。
和訳
- Watch: 見る、監視する
- Metric: 測定値、指標
- Weblio英和辞書「metric」

概要

の中心は、です。メトリクスは使用率、ネットワーク入出力、ディスク読み書き、リクエスト数など、リソースやアプリケーションの状態を数値で表したものです。AWS サービスが自動で送る標準メトリクスと、利用者が送るカスタムメトリクスがあります。

CloudWatch では、メトリクスをグラフ化してダッシュボードで見たり、しきい値に基づいてを作ったりできます。運用担当者がコンソールで状態を見るだけでなく、通知、、アクションなどの自動対応にもつなげられます。

SAA では、監視したい対象が AWS 標準メトリクスなのか、内部やアプリケーション固有の値なのかを読み分けます。EC2 の CPU 使用率やネットワークなどは標準メトリクスで扱えますが、メモリ使用率やディスク使用率など OS 内部の値は CloudWatch Agent やカスタムメトリクスを検討します。

主要技術

①メトリクス、名前空間、ディメンション

は、監視対象の数値データです。メトリクスは名前空間で分類され、ディメンションで対象リソースを識別します。たとえばの使用率は AWS/EC2 名前空間の CPUUtilization として扱われ、インスタンス ID などのディメンションで区別されます。

用語	役割	試験での見方
Metric	監視する数値	CPU 使用率、ネットワーク、リクエスト数などです。
Namespace	メトリクスの分類	`AWS/EC2`、`AWS/RDS` などサービス別に整理します。
Dimension	メトリクスの対象を絞る属性	インスタンス ID、グループ名などで対象を分けます。
Period	集計する時間間隔	1 分、5 分など、監視粒度に関係します。

⚠️ 頻出: CloudWatch は AWS サービスから標準メトリクスを受け取れます。アプリケーション独自の値や内部の値が必要な場合は、カスタムメトリクスや CloudWatch Agent を考えます。

②EC2 の基本モニタリングと詳細モニタリング

には、基本と詳細モニタリングがあります。基本モニタリングでは、多くの EC2 が 5 分間隔で利用できます。詳細モニタリングを有効にすると、EC2 インスタンスのメトリクスを 1 分間隔で取得できます。

モニタリング種別	粒度	主な用途
基本モニタリング	多くのメトリクスは 5 分間隔	通常の状態把握に向きます。
詳細モニタリング	1 分間隔	急な負荷増加を早く検知したい場合に使います。

詳細モニタリングは、EC2 起動時または実行中・停止中のインスタンスに対して有効化できます。使用率、ネットワーク入出力などの EC2 標準メトリクスをより細かい粒度で見たい場合に選びます。

Agent は、詳細モニタリングの代替ではなく、内部やアプリケーション寄りのメトリクスやログを収集したいときに使います。たとえばメモリ使用率、プロセス、ディスク使用率、アプリケーションログなどが必要な場合に検討します。

⚠️ 頻出: 「EC2 の CPU 使用率やネットワークトラフィックを 1 分間隔で把握したい」「運用オーバーヘッドを最小化したい」という条件では、EC2 詳細モニタリングを有効化し、CloudWatch ダッシュボードやで確認する構成を優先します。

③ダッシュボードとアラーム

ダッシュボードは、複数のやを 1 つの画面にまとめて可視化する機能です。複数や複数アカウントのメトリクスをまとめて見る設計にも使えます。

CloudWatch アラームは、メトリクスがしきい値を超えたときに通知や自動アクションを実行する機能です。使用率が高い、の 5xx が増えた、の空き容量が少ない、といった条件で運用対応につなげます。

機能	役割	代表的な使い方
Dashboard	メトリクスを可視化	キャンペーン期間中の負荷状況を一覧します。
Metric Alarm	しきい値監視	CPU 使用率やエラー率が高いときに通知します。
Composite Alarm	複数アラームの組み合わせ	複数条件がそろった場合だけ通知します。
連携	通知	メール、チャット連携、運用通知につなげます。

アラームは監視だけでなく、ポリシーやアクションと組み合わせることがあります。SAA では、負荷増加に応じてしたい場合に、CloudWatch メトリクスと Auto Scaling の関係も見ます。

④CloudWatch Logs と Logs Insights

Logs は、アプリケーションログ、ログ、AWS サービスログを集約する機能です。ロググループとログストリームで整理し、保持期間を設定できます。

は、CloudWatch Logs に保存されたログをクエリして調査する機能です。障害調査、アクセス傾向分析、エラー原因の絞り込みに使います。

用語	役割	試験での見方
Log group	ログのまとまり	アプリケーション単位や環境単位で分けます。
Log stream	個別のログ発生元	インスタンスや単位で分かれます。
Retention	保持期間	コストや監査要件に合わせて設定します。
Logs Insights	ログ検索・分析	障害調査や傾向分析に使います。

やでログ分析する設計もありますが、CloudWatch Logs に既に集約しているログをすばやく調べたい場合は Logs Insights が自然です。長期保管や大規模分析が主目的なら S3 へのエクスポートや Athena と比較します。

⑤CloudWatch Agent とカスタムメトリクス

Agent は、やサーバーからやログを収集して CloudWatch に送るエージェントです。EC2 標準メトリクスだけでは見えない内部の情報を取得したい場合に使います。

要件	選ぶ機能	理由
EC2 の使用率やネットワークを標準粒度で見る	CloudWatch 標準メトリクス	AWS 側で提供されるため導入負荷が低いです。
EC2 標準メトリクスを 1 分間隔で見る	EC2 詳細	Agent を入れずに標準メトリクスの粒度を上げられます。
メモリ使用率やディスク使用率を見る	CloudWatch Agent	OS 内部の値は標準メトリクスだけでは不足します。
アプリケーション固有の業務指標を見る	カスタムメトリクス	利用者が独自の数値を CloudWatch に送ります。

運用オーバーヘッドを最小化する問題では、標準機能で満たせるなら標準機能を選びます。CloudWatch Agent、、、、などを組み合わせる構成は、要件に対して過剰になりやすいです。

⑥クロスアカウントオブザーバビリティ

多数の AWS アカウントへワークロードが分かれていると、、ログ、トレースがアカウントごとに記録されるため、障害の切り分けにアカウントを順番に切り替える手間がかかります。のオブザーバビリティを使うと、1 つのアカウントから複数のアカウントのテレメトリーを横断して検索し、可視化できます。

設定は 2 つのアカウント側から行い、どちらで何を作るかが問われます。

役割	作るもの	何を決めるか
モニタリングアカウント	シンク	どのアカウントからのテレメトリーを受け取るかを許可します。
ソースアカウント	リンク	どの種類のテレメトリーをモニタリングアカウントへ共有するかを選びます。

共有できるのは、CloudWatch のメトリクス、CloudWatch Logs のロググループ、のトレースなどです。と組み合わせると、組織やを指定してソースアカウントをまとめて登録できるため、アカウント数が多いほど手作業との差が大きくなります。

似た構成と混同しやすいため、役割の違いを押さえます。

選択肢	実際にできること	判断ポイント
クロスアカウントオブザーバビリティ	メトリクス、ログ、トレースを横断して検索・可視化	標準機能だけで完結し、運用負荷が最も低い選択です。
とで集約	ログを 1 か所へ集める	収集の基盤と検索の仕組みを自分で作ることになります。
でダッシュボード化	集めたデータの可視化	各アカウントのデータソース登録という手作業が残ります。
	パッチ、コマンド実行、運用作業の一元化	運用作業の集約であり、テレメトリーの横断表示の仕組みではありません。

⚠️ 頻出: 「複数アカウントのメトリクス、ログ、トレースを 1 つのダッシュボードで横断的に見たい」は CloudWatch のクロスアカウントオブザーバビリティです。モニタリングアカウントにシンク、ソースアカウントにリンクを作ります。

試験対策

の試験問題では、まず監視対象が「AWS 標準」か「内部・アプリ固有メトリクス」かを見ます。次に、必要な粒度、可視化、通知、自動化の要件を確認します。

問題文のキーワード	優先して考える機能	理由
の使用率やネットワークを 1 分間隔で把握	EC2 詳細 + CloudWatch	標準 EC2 メトリクスを 1 分粒度で取得できます。
運用オーバーヘッドを最小化	CloudWatch 標準機能	自前収集や複数サービス連携より管理が少なくなります。
メトリクスを一覧で可視化	CloudWatch Dashboard	複数メトリクスを 1 画面で確認できます。
しきい値超過で通知	CloudWatch Alarm +	メトリクスに基づく通知を構成できます。
メモリ使用率やディスク使用率を収集	CloudWatch Agent	OS 内部メトリクスは標準 EC2 メトリクスだけでは不足します。
アプリケーション独自の指標を監視	Custom Metrics	業務指標や独自メトリクスを送信します。
ログを検索して障害調査		CloudWatch Logs 内のログをクエリできます。
複数アカウントを横断して監視	オブザーバビリティ	モニタリングアカウントから他アカウントのテレメトリーを見られます。

よくある誤答は、標準メトリクスで足りる要件に対して、CloudWatch Agent、、、、、cron などを組み合わせる構成です。CPU 使用率やネットワークなどの EC2 標準メトリクスを短い間隔で見たいだけなら、詳細モニタリングと CloudWatch ダッシュボード・がシンプルです。

⚠️ 頻出: 「EC2 の CPU 使用率」「ネットワークトラフィック」「1 分間隔」「運用オーバーヘッド最小」という組み合わせでは、EC2 詳細モニタリングを有効化して CloudWatch で可視化・アラーム設定する選択肢を優先します。