Amazon CloudWatch入門 メトリクス・ログ・アラートの基本とオンプレ監視ツールとの比較ガイド

「オンプレではZabbixやNagiosでサーバーを監視していたけれど、AWSに移行したらCloudWatchで何をどう見ればいいのか、正直つかみきれていない」——クラウド移行案件の現場でよく耳にする悩みです。エージェントを入れる必要はあるのか、ログはどこに集まるのか、アラートはどこから飛ばすのか。オンプレと用語も設計思想も違うため、最初は迷って当然です。

この記事では、Amazon CloudWatchの3本柱である「メトリクス」「ログ」「アラーム」の基本を、オンプレ監視ツールとの比較を交えながら体系的に解説します。料金の仕組み、保持期間、クォータ、設計のコツ、よくあるトラブル、FAQ、そして実務で使えるチェックリストまで、現場で迷わない最低ラインを一気にまとめます。

なぜAmazon CloudWatchなのか？オンプレ監視との根本的な違い

オンプレの監視は「自分たちで監視サーバーを立て、エージェントを配り、ポーリングしてDBに貯める」のが基本でした。Amazon CloudWatchはこの構造を根本から変え、AWSのマネージドサービスとして「メトリクス収集・ログ集約・アラート発火・可視化」を一気通貫で提供します。

もっとも大きな違いは、AWSサービスを使うだけで標準メトリクスが自動的に集まり始めることです。Amazon EC2、Amazon RDS、AWS Lambda、Application Load Balancerなどは、何も設定しなくてもCPU使用率・ネットワーク・エラー率といった基本指標がCloudWatchに送られます。オンプレで言えば「サーバーを買った瞬間にZabbixが勝手にテンプレートを当ててくれる」ような状態です。

一方で、OS内部の指標（メモリ使用率・ディスク使用率・プロセス情報）やアプリケーションログはデフォルトでは取れません。ここはCloudWatch Agentを入れる必要があり、オンプレの「Zabbix Agent配布」とよく似た発想で設計します。「標準メトリクスは自動、内部メトリクスはAgent」という二層構造を最初に押さえると、CloudWatchの全体像が一気にクリアになります。

CloudWatchの主要機能 メトリクス・ログ・アラーム・ダッシュボード

1. CloudWatch Metrics（メトリクス）

メトリクスは時系列の数値データを格納する仕組みです。AWSサービスが自動送信する「AWS/EC2」「AWS/RDS」などの名前空間と、自分のアプリから送信できる「カスタムメトリクス」に分かれます。デフォルトの収集間隔は5分ですが、詳細モニタリングを有効にすると1分粒度になります。さらに「高分解能カスタムメトリクス」を使えば1秒粒度まで対応可能です。

オンプレでは「rrdtoolで5分平均、サマリで1時間平均」といった粒度設計を自分で行いましたが、CloudWatchでは粒度ごとに保持期間が決まっています（後述）。

2. CloudWatch Logs（ログ）

CloudWatch Logsは、サーバー・アプリ・AWSサービスのログを一元集約するマネージドのログ基盤です。Amazon EC2上の/var/log/messagesやNginxのアクセスログをCloudWatch Agent経由で送ったり、AWS Lambdaの実行ログを自動取り込みしたり、VPC Flow LogsやAWS CloudTrailのログを直接流し込んだりできます。

ログは「ロググループ」と「ログストリーム」という2階層で管理し、ロググループ単位で保持期間や暗号化、サブスクリプションフィルタを設定します。Logs Insightsという独自のクエリ言語で、SQL感覚に近い検索・集計・可視化が可能です。

3. CloudWatch Alarms（アラーム）

アラームはメトリクスやログメトリクスフィルタの値を監視し、しきい値超過時にAmazon SNS経由でメール・Slack・PagerDuty・AWS Chatbotなどへ通知を発火させます。状態は「OK」「ALARM」「INSUFFICIENT_DATA」の3つで、Nagiosの「OK/WARNING/CRITICAL/UNKNOWN」と似た感覚で扱えます。

複数メトリクスを組み合わせる「複合アラーム」や、機械学習で動的なしきい値を作る「異常検出（Anomaly Detection）」もあり、固定しきい値では拾えない傾向変化も検知できます。

4. CloudWatch Dashboards（ダッシュボード）

ダッシュボードは複数メトリクス・ログクエリ・アラーム状態を1画面に並べて可視化する機能です。GrafanaのAWS版と捉えると分かりやすく、アカウント・リージョンをまたいだメトリクスも1枚にまとめられます。料金体系上、3ダッシュボード×50メトリクスまでは無料枠の対象です（2026年3月時点）。

基本的な使い方 コンソールとAWS CLIの操作例

1. EC2のCPU使用率を確認する（コンソール）

マネジメントコンソールから「CloudWatch」→「メトリクス」→「すべてのメトリクス」→「EC2」→「Per-Instance Metrics」と進み、対象インスタンスIDの「CPUUtilization」を選びます。デフォルトでは過去3時間が表示されるので、期間を「1週間」に切り替えれば傾向がつかめます。

2. AWS CLIでメトリクスを取得する

# AWS CLI: 直近1時間のEC2 CPU使用率を5分粒度で取得
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time   $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Average Maximum

3. AWS CLIでアラームを作成する

# AWS CLI: CPU使用率80%超が連続3回(15分)でALARM
aws cloudwatch put-metric-alarm \
  --alarm-name ec2-cpu-high \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0

4. CloudWatch Logs Insightsで集計する

# Logs Insights: Nginxアクセスログから5xxエラーを時間帯別に集計
fields @timestamp, status, request
| filter status >= 500
| stats count(*) as errors by bin(5m)
| sort @timestamp desc

料金の仕組み 2026年3月時点の具体的な数字

CloudWatchは「使った分だけ」の従量課金で、料金の柱は次の3つです（東京リージョン、2026年3月時点の代表値。最新は必ずAWS公式料金ページで確認してください）。

・カスタムメトリクス: 1メトリクスあたり月額0.30 USD（最初の10,000まで）
・API呼び出し: GetMetricData/GetMetricStatisticsなど1,000リクエストあたり0.01 USD
・ログ取り込み: 標準クラス1GBあたり約0.76 USD、Infrequent Accessクラス1GBあたり約0.38 USD
・ログ保管: 1GBあたり月額約0.033 USD（圧縮後）
・Logs Insightsクエリ: スキャンしたデータ1GBあたり0.0076 USD
・ダッシュボード: 1ダッシュボードあたり月額3.00 USD（最初の3ダッシュボードは無料）
・アラーム: 標準分解能アラーム1個あたり月額0.10 USD、高分解能は0.30 USD

無料利用枠として、ベーシックモニタリング・10カスタムメトリクス・10アラーム・100万APIリクエスト・5GBログ取り込み・5GBログスキャンが毎月付与されます。検証環境ならこの範囲内で十分回ります。

コストの罠として特に多いのが、「1秒粒度の高分解能カスタムメトリクスを大量に投げる」「DEBUGログを本番でCloudWatch Logsに垂れ流す」「Container Insights有効化でメトリクス数が爆発する」の3つです。月末に請求を見て驚かないよう、コスト配分タグとAWS Budgetsをセットで設定しておきましょう。

主要なクォータと保持期間

・メトリクス保持期間: 高分解能(1秒)=3時間、1分粒度=15日、5分粒度=63日、1時間粒度=455日（約15か月）
・ログ保持期間: 1日〜10年、または無期限から選択（ロググループ単位）
・1リクエストあたりPutMetricData: 最大1,000メトリクス、ペイロード1MB
・カスタムメトリクスのディメンション: 1メトリクスあたり最大30
・アラーム数: リージョンあたりデフォルト5,000（緩和申請可）
・ダッシュボード数: アカウントあたり最大1,000

長期保管が必要なメトリクスは、Amazon S3にエクスポートするか、Amazon Managed Grafana + Amazon Managed Service for Prometheusの組み合わせを検討します。

オンプレ監視ツールとの比較表 Zabbix・Nagios・Prometheusとの違い

ざっくり整理すると、AWS中心の環境ならCloudWatchが第一選択、ハイブリッド環境ならCloudWatch + Zabbix併用、k8s中心ならCloudWatch + Container Insightsか、Amazon Managed Service for Prometheusという棲み分けが現実的です。

実務で使える設計パターンとTips

1. 「3層しきい値」でアラート疲れを防ぐ

アラームを「INFO（傾向把握用、通知なし）」「WARNING（業務時間帯のみメール）」「CRITICAL（24時間オンコール）」の3段階に分けます。CloudWatchの複合アラームを使えば、「CPU高 かつ ロードアベレージ高 かつ 5xxエラー増加」といった条件で初めてCRITICALを発火させ、誤検知を激減できます。

2. ログは「取り込みクラス」を使い分ける

監査・コンプライアンス目的で「保管はするが滅多に検索しない」ログは、Logs Infrequent Accessクラスに送ると取り込み料金が約半分になります。アクセスログ・エラーログなど日常的にLogs Insightsで叩くものは標準クラスのまま、AWS CloudTrailやVPC Flow LogsはIA、と棲み分けるとコストが安定します。

3. メトリクスフィルタでログを数値化する

CloudWatch Logsのメトリクスフィルタを使えば、「ERRORという文字列が1分間に何回出たか」をメトリクス化してアラーム化できます。アプリ側を改修せずに、ログだけで疑似的なエラーレート監視が組めるため、レガシー移行時の橋渡しに非常に役立ちます。

4. タグベースで環境を分離する

Environment=prod/stg/devのタグをリソースに振り、CloudWatchのメトリクスエクスプローラーやAWS Resource Groupsで束ねます。ダッシュボード作成時もタグでフィルタすれば、本番/検証の取り違え事故を防げます。

5. Synthetics Canaryで外形監視

CloudWatch Synthetics Canaryを使うと、URLを定期巡回して応答時間・ステータスコード・スクリーンショットを取得できます。Nagiosのcheck_httpを置き換える発想で、SLA監視の最後のピースを埋められます。

よくあるトラブルと対処法

1. EC2のメモリ・ディスク使用率が見えない

標準メトリクスにメモリとディスクは含まれません。CloudWatch Agentをインストールし、設定ファイルでmem_used_percentやdisk_used_percentを有効化してください。AWS Systems Manager Distributorから一括配布すると運用が楽です。

2. ロググループが無期限保持で料金が膨らむ

ロググループの初期値は「期限切れなし」です。新規作成時は必ず保持期間を設定し、既存環境はAWS CLIで一括棚卸しします。

# AWS CLI: 全ロググループの保持期間一覧（無期限のものを洗い出す）
aws logs describe-log-groups \
  --query 'logGroups[].[logGroupName,retentionInDays,storedBytes]' \
  --output table

3. アラームがINSUFFICIENT_DATAのまま動かない

多くの場合、メトリクスが届いていない（Agent停止・IAM権限不足・名前空間/ディメンションのタイポ）か、評価期間に対してデータポイントが少なすぎます。「missingDataTreatment」を「notBreaching」「breaching」のどちらにするかも要件次第で見直します。

4. 高分解能メトリクスで請求が爆発

1秒粒度メトリクスは標準の3倍料金です。本当に1秒粒度が必要なのは秒オーダーのレイテンシ監視くらいで、ほとんどの業務監視は1分粒度で十分です。誤って高分解能で投げていないか、PutMetricDataのStorageResolution値を確認しましょう。

5. Logs InsightsクエリがTimeoutする

スキャン範囲が広すぎるのが原因です。検索期間を短く区切る、ロググループを絞る、filterを先に効かせてからstatsを書く、という順序を徹底します。

FAQ よくある質問

Q1. CloudWatchはオンプレサーバーも監視できますか？

はい。CloudWatch Agentはオンプレのサーバーにもインストール可能で、IAMロールの代わりにIAMユーザーのアクセスキーを使います。ハイブリッド環境を1つの監視基盤にまとめたい場合の選択肢になります。

Q2. Datadogや New Relicと比べてどうですか？

機能の幅・APMの深さでは商用SaaSが優位ですが、AWS環境への密結合・追加コスト最小・IAMで完結という点ではCloudWatchが圧倒的に楽です。「まずCloudWatchで土台を作り、必要な部分だけSaaSを足す」のが現実的な落とし所です。

Q3. メトリクスは何年前まで遡れますか？

1時間粒度なら最大455日（約15か月）です。それ以上の長期保管が必要な場合は、Amazon S3エクスポートやAmazon Managed Service for Prometheusを併用します。

Q4. アラート通知をSlackに飛ばすには？

SNSトピックにAWS Chatbotを連携させるのが最短です。AWS Chatbotは追加料金不要で、SlackチャンネルやMicrosoft Teamsへ整形済み通知を届けてくれます。

Q5. CloudWatchとAWS X-Rayはどう使い分けますか？

CloudWatchは「メトリクス・ログ・アラーム」のレイヤ、X-Rayは「分散トレーシング（リクエストの経路追跡）」のレイヤです。両者は補完関係で、CloudWatch ServiceLensから両者を1画面で確認できます。

Q6. 複数アカウント・複数リージョンを横断監視したい

クロスアカウントオブザーバビリティを有効化すると、モニタリングアカウント側からソースアカウントのメトリクス・ログ・トレースをまとめて閲覧できます。AWS Organizations配下の運用なら必須機能です。

本記事のまとめとチェックリスト

Amazon CloudWatchは「メトリクス」「ログ」「アラーム」「ダッシュボード」の4機能で、AWS環境の監視・オブザーバビリティを一気通貫で支える基盤です。オンプレのZabbix/Nagiosと比べて初期構築コストはほぼゼロですが、OS内部メトリクスはAgentが必要、料金は従量制で設計を誤ると膨らむ、という2点だけ押さえれば現場で迷うことはなくなります。

移行・新規構築のときに使えるチェックリストをまとめます。

・標準メトリクス確認: 監視対象AWSサービスの自動メトリクスを把握したか
・CloudWatch Agent: EC2にメモリ・ディスク監視を入れたか
・ロググループ保持期間: 全ロググループに保持期間を設定したか
・取り込みクラス: 監査ログをInfrequent Accessに振り分けたか
・3層しきい値: INFO/WARNING/CRITICALを分けたか
・複合アラーム: 誤検知防止のAND条件を組んだか
・SNS + Chatbot: Slack通知の経路を確立したか
・ダッシュボード: 業務単位の1枚を作成したか
・クロスアカウント: 複数アカウント監視の必要性を検討したか
・コスト可視化: AWS BudgetsでCloudWatch料金にアラートを設定したか
・Synthetics Canary: 重要URLに外形監視を設定したか
・IAM最小権限: CloudWatch読み取り/書き込みを役割別に分離したか

クラウド上のLinuxサーバー設計の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。クラウドセキュリティ（IAM・VPC・暗号化）の体系的な学習にはSecurityMasters.TOKYOもあわせてご覧ください。