CloudWatch の監視設計(メトリクス階層・アラーム・ログ分析の使い分け)

調査時点: 2026-07。料金は当時の値。

Amazon CloudWatch は、AWS リソースやアプリケーションのメトリクス・ログを収集し、可視化とアラーム通知を行う監視サービス。

メトリクスの 3 階層とエージェント要否#

階層	取得対象	導入要件	例
標準メトリクス	ハイパーバイザー側から見える外部負荷	なし(自動)	CPU 使用率、ネットワーク、EBS I/O、ステータスチェック
カスタムメトリクス / ログ	OS 内部	CloudWatch Agent(統合エージェント)を OS 内に導入	メモリ使用率(`mem_used_percent`)、ディスク使用率(`disk_used_percent`)、アプリのログファイル
分散トレース	サービス間の呼び出し経路と遅延	アプリに SDK 組み込み、または X-Ray デーモン	マイクロサービスのボトルネック、サービスマップ

メモリとディスクは外側から物理的に見えない。標準メトリクスだけで監視する選択肢は成立しない。CloudWatch Agent はログとメトリクスを扱い、トレースは扱わない(トレースは X-Ray)。

エージェントの一斉展開#

必要な IAM: EC2 のインスタンスプロファイルに CloudWatchAgentServerPolicy と AmazonSSMManagedInstanceCore
設定 JSON を SSM Parameter Store に一元保存し、Run Command(AmazonCloudWatch-ManageAgent)で全台に配信・起動する。1 台ずつログインして配置する運用は選ばない
詳細は Systems Manager の運用自動化

Lambda と EC2 のログ収集の違い#

Lambda はエージェントレス。標準出力に書くだけで実行環境が /aws/lambda/<関数名> へ配送する。ただし実行ロールに AWSLambdaBasicExecutionRole(logs:PutLogEvents など)が要る
EC2 は OS 内部がブラックボックスなのでエージェントが要る

解像度と評価期間#

種別	間隔	課金
標準モニタリング	5 分	無料
詳細モニタリング	1 分	有料
高解像度カスタムメトリクス	最短 1 秒	有料
ステータスチェック	1 分	無料

EC2 の機能名は「詳細モニタリング」。「拡張モニタリング(Enhanced Monitoring)」は RDS の機能で、EC2 には存在しない。

「5 分以内にスケールアウト」の評価期間#

詳細モニタリングを 1 分にしただけでは達成できない。アラームの「評価期間」との組み合わせで決まる。

期間 1 分 × 評価 5 回中 5 回 → トリガーまで最短 5 分。要件違反になりうる
期間 1 分 × 評価 3 回中 3 回 → 3 分でトリガー。5 分以内に余裕で開始できる

統計は Trim(トリム平均)や Percentile で外れ値を除いて評価できる。Web のレイテンシ計測など、少数の外れ値に引きずられたくない指標に向く。

しきい値の選び方: 静的か異常検出か#

メトリクスの性質	アラームの種類	理由
平坦・常に一定	静的しきい値(例: CPU 80% 以上)	明確な限界値がある
昼夜・曜日で周期的に上下	Anomaly Detection(異常検出)	機械学習で予測バンド(期待範囲)を自動生成し、バンド外れで鳴る。手動のしきい値調整が不要

周期的なメトリクスに固定しきい値を当てると誤報の元になる。

複合アラーム(Composite Alarm)#

複数のアラームを ALARM(CPU) AND ALARM(SystemCheck) のように論理式(AND / OR / NOT)で結合し、通知を親アラーム 1 つに集約する。単発では誤報になる条件を AND にして「本当に異常なときだけ」通知する用途。

EventBridge はステートレスで、2 つのアラームの AND 状態を待つことはできない。AND は複合アラームの仕事
メンテナンス中に通知だけ止めたいときはアラームのアクション無効化。複合アラームとは別機能
「アラームグループ」「通知のインテリジェント集約」という機能は存在しない

メトリクスフィルター(既存ログの数値でアラーム)#

すでに CloudWatch Logs にある JSON ログに対し、ロググループ側で { $.api_endpoint = "/checkout" } のようにフィルタし、メトリクス値に $.response_time_ms を指定すると、サーバー側を一切変更せずにカスタムメトリクス化できる。そのまま標準アラーム → SNS に繋げる。

切り分け:

すでに CloudWatch Logs にログがある → メトリクスフィルター
まだ EC2 内にしかない、メモリ・ディスクを新規に監視したい → CloudWatch Agent

リアルタイム検知はメトリクスフィルター、ストリームの目視は Live Tail。Logs Insights を 1 分おきに手動実行する方法はリアルタイム検知には使わない。

ログとメトリクスの分析ツール#

ツール	対象	言語	向く場面
Logs Insights	ログ本文(テキスト)	専用構文(`fields` / `filter` / `stats` / `bin`)	直近数時間〜数日の対話的トラブルシュート
Metrics Insights	メトリクス(数値)	SQL(`SELECT ... WHERE ... GROUP BY`)	「CPU 使用率トップ 10 インスタンス」のような動的な集計
Metric Math	メトリクス	数式	メトリクス間の計算(エラー数 ÷ 総数 × 100 のエラー率、キャッシュヒット率)
Athena(S3 エクスポート後)	S3 上のログ	標準 SQL	数か月〜数年・テラバイト級の監査。S3 の安価な保管 + クエリごとの従量課金
Contributor Insights	ログ	キー指定	「誰が / 何が負荷の主か」のトップ N ランキングを常時可視化

Logs Insights の例:

1
fields @timestamp, @message
2
| filter @message like /ERROR/
3
| stats count() as errorCount by bin(1h)

Metrics Insights と Metric Math の関係#

上位互換ではなく補完関係。Metrics Insights は Auto Scaling で増減する対象へ動的に追従できるが、メトリクス間の計算はできない。Metric Math は四則演算が得意だが固定の対象しか扱えない。併用すると、Metrics Insights の集計結果を Metric Math の入力にして「増減するコンテナ群全体のエラー率」を動的にアラーム化できる。

Metrics Insights のコスト構造#

実行元	課金
コンソールでの手動実行	無料
API / 外部ツール(Grafana など)経由の `GetMetricData`	従量(当時 1,000 メトリクスあたり 0.01 USD)
アラームに組み込み	固定(当時 1 クエリあたり月 0.10 USD)

リアルタイム「トップ 10」ダッシュボードは、自動更新のたびに全メトリクスをスキャンして課金される。2,000 台を 1 分更新で常時表示すると月数百 USD 規模になる試算になった。回避策は、更新間隔を伸ばすか、EventBridge + Lambda で定期的に 1 回だけ集計して対象 ID を固定し、無料の通常ダッシュボードへ書き戻す構成。

パフォーマンス改善の定番#

サービス	手段
S3	DataSync、Transfer Acceleration(遠隔地転送)、マルチパートアップロード、ライフサイクル
EBS	メトリクスに基づき gp2 → gp3 へ移行
EFS	IA(低頻度アクセス)へのライフサイクル
RDS	Performance Insights の推奨、RDS Proxy による接続管理

Lambda の大量同時実行が RDS の接続上限を使い切る「Too many connections」は、RDS Proxy のコネクションプーリングで吸収する。アプリは接続先エンドポイントを Proxy に書き換えるだけでよい。

周辺の観測系サービス#

X-Ray: 分散トレース、サービスマップ、ボトルネック特定
Data Firehose: 大量ログのニアリアルタイム転送。S3 / OpenSearch / Splunk などへノーコードで配送
AWS Health Dashboard: AWS 全体の障害(Service health)と、自アカウント宛てのメンテナンス・リタイア通知(Your account health)

更新履歴#

2026-07-18: 初版(ローカル調査ノート)
2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加