Amazon CloudWatch徹底解説：Cloud Monitoring（GCP）・Azure Monitorとの比較で学ぶ“監視・ログ・メトリクス設計”完全ガイド

はじめに（要点サマリー）

本記事では Amazon CloudWatch を軸に、Google Cloud Monitoring / Cloud Logging、Azure Monitor / Log Analytics と比較しながら、監視・ログ・メトリクス・アラート設計の全体像 を丁寧に整理していきます。
CloudWatch は、メトリクス収集・ログ集約・アラーム・ダッシュボード・トレース（X-Ray連携）・イベント連携 までを一体的に扱える、AWSの標準監視基盤です。
GCP では Cloud Monitoring＋Cloud Logging、Azure では Azure Monitor＋Log Analytics / Application Insights が同じポジションを担います。どのクラウドでも「メトリクス＋ログ＋イベント＋可視化＋通知」の組合せ方が本質です。
設計の肝は、
1. 何をモニタリングするか（SLO/SLIの決め方）
2. どの粒度でメトリクス・ログを集めるか
3. どこまでを自動でアラートし、どこから人が判断するか
4. ダッシュボードを誰向けにどう作るか
5. コストとパフォーマンス（ログ量・保持期間）のバランス
  の5点です。
想定読者は、SRE・インフラ／プラットフォームエンジニア、Web/業務アプリ開発者、データ基盤担当、セキュリティ/ガバナンス担当、情報システム部門の運用チーム、スタートアップの技術リーダー。
この記事を読み終えるころには、CloudWatch を中心に据えながら、GCP / Azure でもほぼ同じ考え方で監視基盤を設計できる「共通の頭の使い方」 が身についている状態を目指します。

1. Amazon CloudWatchとは：監視の“受け皿”を一つにまとめるサービス

Amazon CloudWatch は、AWS リソースやアプリケーションから メトリクス（数値）・ログ・イベント を集約し、アラーム・可視化・自動アクション までを提供するマネージドな監視サービスです。EC2 や RDS、Lambda など多くのサービスが 標準メトリクスを自動で送信 してくれるため、まずは「全部 CloudWatch に集めてから考える」という発想でよいくらい、中心的な存在になっています。

代表的な機能は次のとおりです。

メトリクス：CPU 使用率、ディスク IO、SQS のキュー長、カスタムメトリクスなどを 1分 or 5分粒度などで収集。
ログ：CloudWatch Logs グループとして、アプリログ・OSログ・ALB/CloudFrontログなどを集約。
アラーム：メトリクスやログベースメトリクスを元にしきい値を設定し、SNS や Ops系ツールに通知。
ダッシュボード：メトリクスやアラーム状況をまとめた“見える化パネル”を作成。
Events / EventBridge連携：リソースの状態変化や定期スケジュールから、Lambda や Step Functions を起動。

GCP では Cloud Monitoring（旧 Stackdriver Monitoring） がメトリクス＆アラートを、Cloud Logging がログ集約を担い、Azure では Azure Monitor がメトリクス基盤、Log Analytics / Application Insights がログ・トレースを担当する構造で、役割としてはほぼ同じです。

2. 監視設計の前提：SLO/SLIから決める“何を見たいか”

監視ツールの機能を覚えるより先に大切なのは、そもそも何を監視したいのか？ を決めることです。

2.1 SLO（Service Level Objective）と SLI（Service Level Indicator）

SLI：サービス品質を表す指標（Indicator）。
- 例：
  - 「1分ごとの成功リクエスト率」
  - 「p95 レイテンシ」
  - 「エラー率」
  - 「ジョブ完了までの平均時間」など。
SLO：SLI に対して「どこまで許容するか」を決めた目標値。
- 例：
  - 「90日間の HTTP 成功率 99.9%以上」
  - 「p95 レイテンシ 500ms 未満」

CloudWatch では、これらを メトリクス化してアラームに落とす ことで、日々の運用と SLO を結びつけられます。GCP の Cloud Monitoring や Azure Monitor でも同様に、まず SLI を Cloud Monitoring の指標／Azure のメトリックや KQL クエリで表現してから、SLO をアラート条件や SLO ビューに落とし込む形になります。

2.2 “インフラ指標”と“ユーザー体験指標”を分けて考える

インフラ側：CPU、メモリ近似値、ディスク IO、ネットワーク帯域、コンテナ数、キュー長…
アプリ／ユーザー体験側：エラー率、レイテンシ、売上・コンバージョン、サインイン成功率…

CloudWatch でも、インフラメトリクス（AWS 提供）とアプリ側のカスタムメトリクスを区別して扱い、「ユーザー体験に直結するもの」を優先してアラート化すると、アラート疲れを防げます。

3. CloudWatchメトリクス：標準＋カスタム＋ログベースの三本柱

3.1 標準メトリクス

AWS 各サービスは、CloudWatch に対して自動的にメトリクスを送信しています。例えば：

EC2：CPUUtilization、NetworkIn/Out、StatusCheckFailed など
RDS：CPUUtilization、FreeStorageSpace、DatabaseConnections など
Lambda：Invocations、Errors、Duration、Throttles など
ALB/NLB：RequestCount、TargetResponseTime、HTTPCode_ELB_5XX など
SQS：ApproximateNumberOfMessagesVisible など

これらは追加料金なし（一部高頻度メトリクスは有料）で利用できるため、まずは標準メトリクスをベースにダッシュボードを作るのが近道です。

3.2 カスタムメトリクス

アプリ固有の指標（例：注文数、ログイン失敗数、バッチ処理時間など）は、PutMetricData API / SDK / CloudWatch Agent を用いて CloudWatch に送信できます。

名前空間：MyApp/Orders など
ディメンション：service=frontend, region=ap-northeast-1 など

GCP でも Cloud Monitoring にカスタムメトリクスを送信できますし、Azure でも Azure Monitor へカスタムメトリックを投入できます。考え方は同じで、「アプリの成功・失敗・遅延を数字で表し、SLO と結びつける」ための手段です。

3.3 ログベースメトリクス

CloudWatch Logs に蓄積したログに対して メトリクスフィルター を作成し、特定パターンの出現回数をメトリクス化することもできます。

例：
- 500 エラーを表すログ行をカウントして App/5xxCount メトリクスを作り、エラー率アラートを構成。
- 「支払い失敗」ログの回数をメトリクス化して、異常増加を検知。

GCP の Cloud Logging と Cloud Monitoring、Azure の Log Analytics でも、クエリ結果をメトリクス化・アラート化する仕組み が用意されています。

4. CloudWatch Logs：ログ集約・検索・フィルタ・保持期間

4.1 ロググループとログストリーム

CloudWatch Logs では、ログはロググループ → ログストリームという階層で管理されます。

ロググループ：アプリやサービス単位（例：/aws/lambda/app-api）
ログストリーム：インスタンスIDやコンテナID・日付など細かい単位

ログの粒度やグループ分けを最初に決めておくと、後から運用が楽になります。

4.2 収集方法

CloudWatch Agent：
- EC2 やオンプレ環境からファイルログ・OSメトリクスを収集。
サービス連携：
- Lambda / API Gateway / ECS / EKS / RDS（拡張ログ）、ALB / WAF / VPC Flow Logs などは CloudWatch Logs に直接出力設定が可能。
Fluent Bit / Fluentd / OpenTelemetry Collector：
- コンテナ環境などで、ログを CloudWatch Logs へルーティングする際によく使われます。

GCP では Logging エージェントや Ops Agent、Azure では Log Analytics エージェントや Azure Monitor Agent を利用し、発想は同じです。

4.3 ログの保持期間とライフサイクル

CloudWatch Logs は、ロググループごとに保持期間（Retention） を設定できます。

本番のアプリログ：30〜90日
セキュリティ／監査ログ：半年〜数年（ただし S3 など長期保管先へエクスポートした方が安価）

長期保存が必要なログは、定期的に S3 へエクスポートし、Athena などで分析する構成が一般的です。GCP でも Logging から Cloud Storage へ、Azure では Log Analytics からストレージへエクスポートするパターンが同等です。

5. アラームと通知：しきい値をどう決めるか

5.1 CloudWatch アラームの基本

CloudWatch Alarm は、メトリクスが一定の条件を満たしたときに“ALARM”状態になる仕組みです。

条件の例：
- CPUUtilization > 80% が 5分間連続
- 5xx エラー率 > 1% が 10分のうち 2回以上
- App/LoginFailureCount が 1分間で 50回を超えた

アラーム状態になったら、SNS でメール／Slack／PagerDuty などに通知を送れますし、Lambda や EC2 Auto Scaling のポリシーを起動するトリガー としても使えます。

5.2 アラート疲れを防ぐための工夫

アラートは“人が行動を変えるきっかけ”だけにする
- 「CPUが70%超えた」だけでは何もできない場合が多いので、ユーザー影響に結びつく指標（SLI） に重点を置きます。
Warning / Critical で段階をつける
- 軽度の問題は翌日のレビュー、重大なものだけ夜間ページなど。
サイレンティングとルール見直し
- 誤検知が続くルールは、閾値・期間・対象メトリクス を見直して“静かにする”ことも大切です。

GCP / Azure でも、アラートポリシー／ルールが非常に柔軟ですが、考え方はまったく同じです。

6. ダッシュボードと可視化：誰のための画面かを明確に

6.1 CloudWatch Dashboards

CloudWatch Dashboards は、複数メトリクス・アラーム・ログインサイト を 1 画面にまとめられる機能です。

例：
- プラットフォームチーム向け：インフラ全体の CPU / ネットワーク / エラー率 / アラーム数
- プロダクトチーム向け：特定サービスのレイテンシ・エラー率・注文数・売上など
- 経営層向け：ごく少数のビジネス指標＋稼働状況“ざっくり”

6.2 3クラウドのダッシュボード比較

CloudWatch Dashboards：メトリクス＋アラーム中心のパネル。
Cloud Monitoring Dashboards（GCP）：メトリクス＋ログ指標＋Uptime Checkなどの一体表示。
Azure Dashboards / Workbooks：Azure Monitor メトリクス＋Log Analytics クエリ結果＋APM情報を組み合わせた高度な可視化。

どれも「ターゲット（誰向けか）を明確にして、見るべき項目を絞るほど良いダッシュボードになる」という原則は共通です。

7. 分散トレースとログのひもづけ：X-Ray / Cloud Trace / Application Insights

複数マイクロサービスや Lambda、メッセージキューが絡む構成では、単純なメトリクス・ログだけではどこで遅れているかが分かりづらくなります。

AWS：AWS X-Ray と CloudWatch Logs を連携し、トレースIDをログに埋め込むことで、1つのリクエストがどのサービスを経由し、どこで時間がかかったか を可視化できます。
GCP：Cloud Trace / Cloud Profiler と Cloud Logging を連携。
Azure：Application Insights のトレースと Log Analytics が一体化。

CloudWatch 自体は“トレースエンジン”ではありませんが、ログ・メトリクスとトレースを ID で連携させることで、根本原因分析（RCA）が一気にやりやすくなります。

8. コスト設計：メトリクス・ログ・ダッシュボードの“適量”を探る

監視基盤は、使えば使うほどコストがじわじわ効いてくる領域でもあります。

8.1 CloudWatch の主な課金ポイント

メトリクス（標準メトリクスは多くが無料枠含む、有料の高解像度メトリクスあり）
カスタムメトリクス
ログの保存量・取り込み量・保持期間
ダッシュボード数
アラーム数（一部機能）など

8.2 コストを抑える工夫

無駄なカスタムメトリクスを作りすぎない
- 集計可能なものはログベースメトリクスに寄せるなど、バランスを取ります。
ログの保持期間を用途ごとに分ける
- アプリデバッグログ：短期
- セキュリティログ：S3長期保存＋ CloudWatch は短期
高頻度メトリクスは本当に必要なものだけ
- 1分粒度で十分なものまで、10秒粒度にしないように注意。
ダッシュボードやアラームを整理する
- 使われていないパネル・アラームは定期的に棚卸し。

GCP / Azure でも、ログ・メトリクス量と保持期間がコストに直結するのは同じなので、最初から「どれくらい残すか」を決めておくと安心です。

9. 設計パターン：3つの“監視アーキテクチャ”例

9.1 小規模〜中規模 Web/API サービス

目的：1〜数チームで開発している Web/API を安定運用したい。
構成（AWS）：
- CloudWatch メトリクス：EC2/LB/RDS/Lambda の標準メトリクス＋アプリのカスタムメトリクス（エラー率・レイテンシ等）
- CloudWatch Logs：アプリログ・ALBアクセスログ
- アラーム：SLO ベースの指標（成功率・レイテンシ）、致命的なインフラ障害（ディスク不足など）
- ダッシュボード：チーム用 1〜2 枚＋全体用 1 枚

GCP なら Cloud Monitoring＋Logging、Azure なら Azure Monitor＋Log Analytics でほぼ同じ構成が組めます。

9.2 バッチ処理・データパイプライン

目的：夜間バッチや ETL、ストリーミング処理の成功/失敗を“見える”ように。
構成：
- メトリクス：ジョブ件数、失敗件数、処理時間、レイテンシ
- ログ：ステップごとのログを CloudWatch Logs に集約し、ログベースメトリクスで失敗数をカウント。
- アラーム：一定時間内にジョブが完了しない、失敗率が増加した場合に通知。

GCP の Dataflow / Composer、Azure の Data Factory 等でも同じ発想でメトリクス・ログを Cloud Monitoring / Azure Monitor 側に送ります。

9.3 マルチアカウント／マルチクラウド環境

目的：複数 AWS アカウントや、AWS＋GCP＋Azure を横断して監視したい。
構成案：
- 各クラウドの CloudWatch / Cloud Monitoring / Azure Monitor から、共通の可視化基盤（例えば Grafana / Datadog など） にデータを集約。
- ただし 各クラウドのネイティブ監視も残し、サービス固有の機能はそちらで活用。

CloudWatch も GCP と Azure も、外部システムへのエクスポートや API 連携 に対応しているので、“二段構え”が組みやすいです。

10. サンプル：CloudWatchでの実務的な設定例

※イメージしやすいよう、簡単な例を載せておきます。

10.1 カスタムメトリクス送信（Python SDK）

import boto3, time

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

def put_order_count(count: int):
    cloudwatch.put_metric_data(
        Namespace="MyApp/Orders",
        MetricData=[
            {
                "MetricName": "OrderCreated",
                "Dimensions": [
                    {"Name": "service", "Value": "web"},
                    {"Name": "env", "Value": "prod"},
                ],
                "Timestamp": time.time(),
                "Value": count,
                "Unit": "Count",
            }
        ],
    )

10.2 メトリクスフィルタ（ログから 5xx 回数をカウント）

aws logs put-metric-filter \
  --log-group-name "/aws/lambda/app-api" \
  --filter-name "5xx-count" \
  --filter-pattern '\"status\":5*' \
  --metric-transformations \
    metricName=Lambda5xxCount,metricNamespace=MyApp/API,metricValue=1

このようにして作った MyApp/API Lambda5xxCount に対して、一定以上の増加でアラーム を張ると、アプリの異常を早く検出しやすくなります。

11. よくある落とし穴と回避策

インフラメトリクスだけ見て、ユーザー体験が見えていない
- 対策：エラー率・レイテンシ・ビジネス指標 をカスタムメトリクスとして追加し、SLO ベースでアラートを設計します。
ログを全部突っ込んだ結果、検索もコストも重い
- 対策：ログを種類ごとにグループ分けし、保持期間を用途単位で設定。長期は S3 へ退避。
アラートが鳴りすぎて誰も見なくなる
- 対策：
  - SLI 以外のアラートは「Warning」扱いにして、日次/週次レビューへ。
  - 連続で鳴るルールは一度停止して、前提の SLO/閾値を見直す。
開発者と運用者でダッシュボードが分断
- 対策：共通の SLO ダッシュボードを1枚作り、その上で各チーム専用パネルを追加する形に。

12. 誰がどう得をする？（読者別のメリット）

SRE / プラットフォームエンジニアの方
- CloudWatch を中心に、メトリクス・ログ・アラーム・ダッシュボードを一体で設計する“型” を持てます。マルチクラウドでも同じ考え方で展開できるので、運用負荷がかなり減ります。
アプリ開発者の方
- 「自分の書いたコードが本番でどう見えているか」を、CloudWatch メトリクス・ログで把握できるようになります。SLI の観点で設計できるエンジニア に一歩近づきます。
情報システム部門・運用担当の方
- CloudWatch / Cloud Monitoring / Azure Monitor を使い分けつつ、“ここまで取れば十分”という現実的ライン を描けるようになります。監査や障害報告への対応もしやすくなります。
セキュリティ / ガバナンス担当の方
- 監査ログ・アクセスログ・変更履歴の取り扱い方と保持戦略が整理され、規程と実装のギャップ を埋めやすくなります。
スタートアップの技術リーダーの方
- 少人数でも、CloudWatch ベースで“ちゃんとした”監視基盤 を用意でき、成長に合わせて GCP / Azure へもスケールしやすい設計が分かります。

13. 今日からできる3ステップ

SLO/SLIを1〜2個だけ決める
- 例：成功率 99.9%、p95 レイテンシ 500ms など。
CloudWatch でその SLI を表現するメトリクスを1つ作る
- ログベースメトリクス or カスタムメトリクスで、まずは 1 本。
そのメトリクスに対するアラームと簡単なダッシュボードを作る
- これだけでも、「何となくメトリクスを見る」状態から「目標と実績を比較する」状態 に一段ステップアップできます。

14. まとめ：CloudWatchは“数字・ログ・イベントをつなぐハブ”

Amazon CloudWatch は、単なるメトリクス収集ツールではなく、

メトリクス（SLI/SLO）
ログ（詳細な文脈）
アラーム（行動のトリガー）
ダッシュボード（共有される“見える化”）
イベント（自動アクション）

を一つの場所に集約してくれる、運用の中枢ハブです。

GCP の Cloud Monitoring / Logging、Azure Monitor / Log Analytics も同じ役割を担っており、**「どの指標をどう扱うか」という設計の仕方さえ身につければ、クラウドが変わっても応用できます。

これまでの記事で取り上げてきた S3 / EC2 / Lambda / RDS / VPC / CloudFront と今回の CloudWatch を組み合わせることで、

インフラ → アプリ → フロント → 監視 まで、一連の“見える・守れる・伸ばせる”基盤が見えてきたのではないかなと思います。

次回は、これらと密接に絡む AWS IAM（アイデンティティとアクセス管理） を取り上げ、Cloud IAM（GCP）／Azure AD / Entra ID + RBAC と比較しながら、「権限設計・ロール設計・ゼロトラストに向けたIDの使い方」を丁寧に深堀りしていきますね。