📌
CloudWatch とはAmazon CloudWatch は、AWS リソースとアプリケーションの監視・ログ管理サービスです。EC2、RDS、Lambda などほぼすべての AWS サービスが自動的にメトリクスを CloudWatch に送信しており、CPU 使用率、ネットワークトラフィック、エラー率などをリアルタイムで確認できます。
CloudWatch の主要機能は メトリクス(数値データの時系列記録)、アラーム(閾値超過時の通知)、ログ(テキストログの収集・検索)、ダッシュボード(可視化パネル)の4つです。これらを組み合わせることで、異常の検知→通知→自動対処までを一元管理できます。
CloudWatch は従量課金制で、標準メトリクス(5分間隔)は無料で利用できます。詳細モニタリング(1分間隔)、カスタムメトリクス、アラーム、ダッシュボードは追加料金が発生します。基本的な監視はコストゼロで始められるため、AWS を使うなら最初から活用すべきサービスです。
CloudWatch の位置づけ: AWS の「目と耳」に相当するサービスです。リソースの状態を常に監視し、異常があれば即座にアラートを出し、必要に応じて自動修復アクション(Auto Scaling、Lambda 実行など)をトリガーします。
📊
CloudWatch メトリクスとはメトリクスは、AWS リソースの状態を表す数値データの時系列記録です。EC2 の CPU 使用率、RDS の接続数、Lambda の実行時間など、AWS サービスが自動的に CloudWatch にデータを送り続けています。「今サーバーはどれくらい忙しいか」「エラーは増えていないか」をグラフで確認できます。
メトリクスの特徴
- 自動収集 — EC2, RDS, Lambda など主要サービスは設定不要で自動送信
- 時系列データ — 時刻ごとの値が記録される(5分 or 1分間隔)
- 15ヶ月保持 — 高解像度(1分)は15日、1時間集計は15ヶ月間保持される
- 統計値 — Average, Sum, Max, Min, SampleCount で集計できる
- カスタムメトリクス — PutMetricData API で独自のデータも送れる
- 標準メトリクスは無料 — 5分間隔の基本データは追加料金なし
標準メトリクスの例(自動収集)
- EC2: CPUUtilization, NetworkIn/Out
- RDS: DatabaseConnections, FreeStorageSpace
- Lambda: Duration, Errors, Invocations
- S3: NumberOfObjects, BucketSizeBytes
カスタムメトリクスの例(自分で送信)
- アプリの同時ログインユーザー数
- 注文件数 / 売上金額
- API のレスポンスタイム
- キューの滞留メッセージ数
📊
メトリクスの階層構造CloudWatch メトリクスは 名前空間(Namespace)→ メトリクス名(MetricName)→ ディメンション(Dimensions)→ データポイント という4層の階層構造を持っています。名前空間はサービス単位のグループ(例: AWS/EC2)、メトリクス名は具体的な指標(例: CPUUtilization)、ディメンションはリソースの識別子(例: InstanceId=i-xxx)です。
ディメンションは最大30個まで設定でき、複数のディメンションの組み合わせで「InstanceId=i-xxx かつ AutoScalingGroupName=my-asg」のように多次元で絞り込めます。ディメンションなしで取得すると全リソースの集約値になり、特定のディメンションを指定すると個別リソースの値が得られます。
データポイントは時刻と値のペアで、Period(集約期間)ごとに1つ生成されます。標準メトリクスは5分間隔(60秒 × 5 = 300秒)で自動送信されます。詳細モニタリングを有効にすると1分間隔になります。データポイントの保持期間は解像度により異なり、1分データは15日間、5分データは63日間、1時間データは455日間保持されます。
## メトリクス取得コマンド
$ aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123 \
--period 300 --statistics Average
📈
標準メトリクスとカスタムメトリクスCloudWatch のメトリクスには標準メトリクス(AWS が自動で送信)とカスタムメトリクス(自分で送信)の2種類があります。
標準メトリクス(自動で収集される)
EC2, RDS, Lambda などの AWS サービスが自動で CloudWatch にデータを送ります。設定不要で、サービスを使い始めた時点から記録が始まります。
- 収集間隔: 5分(詳細モニタリングで1分に変更可)
- 料金: 無料(5分間隔の場合)
- 注意: メモリ使用率・ディスク使用率は含まれない(SAA 頻出)
カスタムメトリクス(自分で送信する)
標準メトリクスにないデータを送りたい場合、PutMetricData API や CloudWatch Agent で独自のメトリクスを送信できます。
- 収集間隔: 1秒〜(高解像度メトリクス対応)
- 料金: 有料($0.30/メトリクス/月)
- 用途: メモリ使用率、アプリ固有の指標(ログインユーザー数、注文件数など)
📉
メトリクスの具体例 — 実際にはこう見えるCloudWatch のメトリクスは時系列のグラフで確認します。5分ごとに記録された値が折れ線グラフで表示され、異常な変化を視覚的に見つけられます。
AWS/EC2 — CPUUtilization(InstanceId: i-0abc123)
赤い破線 = 閾値(80%)。赤い点 = 閾値を超えたデータポイント
データポイント(5分間隔で記録された実際の値)
ポイント: CloudWatch コンソールではこのようなグラフをリアルタイムで確認でき、異常の発生タイミングや傾向を把握できます。このデータを元にアラームを設定すれば、閾値を超えた瞬間に自動で通知やアクションを実行できます。
📋
メトリクスで収集できるデータ一覧主要な AWS サービスが CloudWatch に自動送信する標準メトリクスの一覧です。サービスを使い始めた時点で、これらのデータは自動的に記録されています。
EC2(名前空間: AWS/EC2)
CPUUtilization — CPU 使用率(%)
NetworkIn / Out — ネットワーク通信量
DiskReadOps / WriteOps — ディスク I/O 回数
StatusCheckFailed — ステータスチェック失敗
⚠ メモリ使用率・ディスク使用率は標準メトリクスに含まれない(CloudWatch Agent が必要)
RDS(名前空間: AWS/RDS)
DatabaseConnections — 同時接続数
CPUUtilization — CPU 使用率(%)
FreeStorageSpace — 空きストレージ容量
ReadLatency / WriteLatency — 読み書きの遅延
FreeableMemory — 空きメモリ
ReplicaLag — レプリカの遅延時間
Lambda(名前空間: AWS/Lambda)
Invocations — 呼び出し回数
Duration — 実行時間(ms)
Errors — エラー回数
Throttles — スロットリング回数
ConcurrentExecutions — 同時実行数
IteratorAge — ストリーム処理の遅延
ALB / ELB(名前空間: AWS/ApplicationELB)
RequestCount — リクエスト数
TargetResponseTime — レスポンス時間
HTTPCode_Target_5XX — 5xx エラー数
HealthyHostCount — 正常なターゲット数
SQS(名前空間: AWS/SQS)
NumberOfMessagesSent — 送信メッセージ数
NumberOfMessagesReceived — 受信メッセージ数
ApproximateNumberOfMessagesVisible — キュー内メッセージ数
ApproximateAgeOfOldestMessage — 最古メッセージの滞留時間
⏱️
データの保持期間と解像度CloudWatch のメトリクスは時間が経つにつれて自動で集約(解像度が下がる)されます。古いデータほど粒度が荒くなりますが、長期間保持されます。
解像度
保持期間
いつ使われるか
1秒
3時間
高解像度カスタムメトリクス
1分
15日間
詳細モニタリング有効時
5分
63日間
標準メトリクス(デフォルト)
1時間
15ヶ月
63日より古いデータの自動集約
ポイント: 「3日前の1分単位のデータ」は見られるが、「2ヶ月前の1分単位のデータ」は自動集約されて5分単位になっている。障害調査のために細かいデータが必要なら、早めに確認すること。
📝
AWS 認定試験(SAA)レベルの問題Q1.EC2 インスタンスのメモリ使用率を CloudWatch で監視するために必要なことは?
A.EC2 の詳細モニタリングを有効化する
B.CloudWatch Agent をインストールしてカスタムメトリクスとして送信する
C.EC2 のインスタンスタイプを変更する
D.CloudWatch Logs にメモリ情報を出力する
Q2.CloudWatch アラームの EvaluationPeriods を 3、Period を 300秒に設定した場合、アラームが ALARM 状態に遷移するのはどのような場合ですか?
A.1回でも閾値を超えたとき
B.15分間に1回以上閾値を超えたとき
C.5分間隔で3回連続(=15分間)閾値を超えたとき
D.300秒以内に3回閾値を超えたとき
Q3.Composite Alarm について正しい記述はどれですか?
A.1つのメトリクスに対して複数の閾値を設定できる機能
B.複数のアラームの状態を AND/OR/NOT で組み合わせて判定するアラーム
C.アラームの状態を複数の SNS Topic に同時通知する機能
D.異なるリージョンのアラームを統合する機能