Amazon CloudWatch設計ガイド：Google Cloud、Azureと比較する監視とログの実務

Amazon CloudWatchを導入しても、収集するデータと異常時の行動が決まっていなければ、監視画面と通知が増えるだけです。

先に利用者へ届けたい品質を決め、その品質を測るメトリクス、原因を調べるログとトレース、対応を始めるアラームを順に設計します。

この記事では、CloudWatchの基本をGoogle CloudとAzureのサービスに対応づけ、監視基盤を実務で組み立てる順序を解説します。

Amazon CloudWatchが担う役割

Amazon CloudWatchは、AWS上のリソースとアプリケーションから運用データを集め、可視化、検索、通知、自動処理につなげるオブザーバビリティサービスです。

オブザーバビリティとは、システムの外から得られるデータを使い、内部で何が起きているかを調べられる状態を指します。

監視対象には、Amazon EC2の設計、Amazon RDSの設計、AWS Lambdaの設計などが含まれます。

• メトリクス：CPU使用率、リクエスト数、エラー率など、時間とともに変化する数値です。
• ログ：処理内容、エラー、アクセスなど、個々の出来事を記録したデータです。
• トレース：一つのリクエストが複数のサービスを通過した順序と所要時間を追うデータです。
• アラーム：メトリクスやログが条件を満たしたとき、通知や自動処理を始める仕組みです。
• ダッシュボード：判断に必要なメトリクス、ログ、アラームの状態を一つの画面にまとめたものです。

これらは別々の機能ですが、障害対応では一つの流れとして使います。

アラームで異常を知り、メトリクスで影響範囲を確かめ、ログとトレースで原因候補を絞り、復旧後の推移をダッシュボードで確認する流れです。

三つのクラウドを同じ設計軸で比べる

製品名を一対一で覚えるより、運用上の役割で対応づけると比較しやすくなります。

次の表は大まかな対応関係であり、各サービスの機能範囲や料金体系が同じという意味ではありません。

マルチクラウドでは、共通の設計軸を持ちながら、クラウド固有の監視機能も残す方法が現実的です。

全体状況を共通画面で確認し、詳細な調査は各クラウドのネイティブ機能で行うという役割分担にできます。

SLIとSLOから監視項目を決める

監視設計は、取得できるメトリクスを並べる作業から始めません。

利用者が困る状態を定義し、それを数値でどのように捉えるかを決めます。

SLIは品質を測る指標

SLI（Service Level Indicator）は、サービス品質を測る指標です。

HTTPリクエストの成功率、応答時間、ジョブの完了率などが該当します。

p95応答時間は、観測したリクエストの95％が収まる応答時間を表します。

平均値だけでは一部の遅いリクエストが見えにくいため、利用者が感じる遅さを捉える指標として使えます。

SLOは品質の目標

SLO（Service Level Objective）は、SLIに対して定める目標です。

たとえば「90日間のHTTP成功率を99.9％以上にする」「p95応答時間を500ミリ秒未満にする」という形で表します。

これらの数値は説明用の例であり、実際の目標は利用者への影響、現在の実績、復旧体制を踏まえて決める必要があります。

インフラ指標と利用者指標を分ける

CPU使用率や空き容量は原因候補を探すためのインフラ指標であり、成功率や応答時間は利用者への影響を捉える指標です。

CPU使用率が高くてもサービスが正常な場合はあり、CPU使用率が低くても外部依存先の障害でリクエストが失敗する場合があります。

緊急通知には利用者指標を優先し、インフラ指標は原因調査や予兆の確認に使うと、行動につながらない通知を減らせます。

メトリクスを三つの種類に分ける

AWSサービスが提供するメトリクス

EC2、RDS、Lambda、ロードバランサー、SQSなど、多くのAWSサービスはCloudWatchへメトリクスを送ります。

代表例は、EC2のCPUUtilization、RDSのDatabaseConnections、LambdaのErrors、SQSのApproximateNumberOfMessagesVisibleです。

利用できる指標、収集間隔、料金条件はサービスと設定で異なるため、設計時には対象サービスの最新仕様を確認します。

アプリケーション固有のカスタムメトリクス

注文成功数、ログイン失敗数、バッチ処理時間など、事業やアプリケーションに固有の値はカスタムメトリクスとして送信できます。

CloudWatch Metricsでは、名前空間、メトリクス名、ディメンションを組み合わせて系列を識別します。

• 名前空間：関連するメトリクスをまとめる領域です。
• ディメンション：環境、サービス、リージョンなど、同じメトリクスを分類する名前と値の組です。

ディメンションの値を細かく増やすと系列数も増えやすいため、調査に必要な分類だけを採用します。

ログから作るメトリクス

CloudWatch Logsのメトリクスフィルターを使うと、条件に合うログを数値として数え、グラフやアラームへつなげられます。

たとえば、支払い失敗を示すログの件数を数えれば、失敗が増えたことを検知できます。

ただし、ログの表記が処理ごとに異なると正しく集計できないため、状態コードやイベント名を一定の形式で記録します。

CloudWatch Logsを調査しやすく保つ

CloudWatch Logsでは、ロググループの中にログストリームが作られます。

ロググループはアプリケーションや用途のまとまり、ログストリームはインスタンスや実行環境など、ログを発生させた単位として考えると整理しやすくなります。

収集経路を選ぶ

• AWSサービスの連携：Lambda、API Gateway、ECS、EKS、RDSなど、対象サービスの出力設定を使います。
• CloudWatch Agent：EC2やオンプレミス環境のログとOSメトリクスを収集します。
• Fluent Bit、Fluentd、OpenTelemetry Collector：コンテナ環境などから、必要な送信先へ運用データを振り分けます。

Amazon VPCの設計で扱う通信記録など、種類の異なるログを一つのグループへ混在させると、権限、保持期間、検索範囲を分けにくくなります。

サービス、環境、用途を基準にロググループを分け、命名規則を先に決めます。

保持期間と長期保管を分ける

保持期間は、障害調査、監査、セキュリティ確認など、ログを残す目的から決めます。

すべてのログを同じ期間だけ残すと、不要な保存コストが生じる一方、必要な証跡を早く失うおそれがあります。

CloudWatch Logs内の保持期間を用途別に設定し、長期保管が必要なデータはS3などへの保管方法を別に設計します。

継続的なアーカイブにはサブスクリプションを検討し、S3へのエクスポートタスクは特定期間のデータを書き出す用途として使い分けます。

アラームを対応手順と一緒に設計する

CloudWatch Alarmは、メトリクスが指定した条件を満たしたときに状態を変え、通知や自動アクションにつなげます。

しきい値だけでなく、評価期間、何回の違反で通知するか、データが欠けたときの扱いまで含めて条件を決めます。

「CPUUtilizationが80％を超えた状態が5分続く」「5xxエラー率が1％を超える」といった値は設定例であり、どのシステムにも共通する推奨値ではありません。

通知には、対象サービス、影響を確かめる画面、最初に行う確認、担当チームを添えます。

受信した人が行動を選べない通知は、しきい値を調整するだけでなく、監視目的そのものを見直します。

ダッシュボードは利用者ごとに分ける

一枚のダッシュボードへすべてのグラフを詰め込むと、異常時に見るべき場所が分かりません。

画面を見る人と、その人が下す判断を決めてから項目を選びます。

• サービス担当者向け：成功率、応答時間、エラー率、依存先の状態を配置します。
• 基盤担当者向け：CPU、メモリ、ディスク、ネットワーク、キューなどの原因調査用指標を配置します。
• 事業責任者向け：利用者影響と主要なサービス状態を少数の指標で示します。

同じ指標でも、担当者には詳細な時系列が必要であり、事業責任者には影響の有無と継続時間が必要です。

ログ、メトリクス、トレースを結びつける

複数のサービスを通るリクエストでは、メトリクスだけを見ても遅延箇所を特定できません。

リクエストIDやトレースIDをログへ含め、メトリクス上で異常が始まった時間帯から、関連ログとトレースへ移れるようにします。

AWSではCloudWatchの各機能とX-Ray、Google CloudではCloud Monitoring、Cloud Logging、Cloud Trace、AzureではAzure MonitorとApplication Insightsを組み合わせる考え方です。

根本原因分析（RCA）は、目に見えたエラーだけを直すのではなく、エラーを生んだ条件と経路を特定する作業です。

時刻、サービス名、環境名、リクエストを識別する値が揃っていると、三種類のデータを行き来しやすくなります。

監視コストを設計段階で管理する

監視費用は、収集量、保存量、検索量、メトリクスの系列数、解像度、アラームやダッシュボードの構成などで変わります。

料金項目と無料利用枠は変わる可能性があるため、固定額や「標準だから無料」といった前提を設計根拠にしません。

1. 目的のない収集を止める：取得するメトリクスとログごとに、使う判断または調査を記録します。
2. ディメンションを絞る：調査で使わない分類を増やさず、メトリクス系列の増加を抑えます。
3. ログ量を用途別に把握する：本番、検証、監査などを分け、保持期間を個別に設定します。
4. 高い時間解像度を限定する：短い間隔でなければ見つけられない事象だけに使います。
5. 定期的に棚卸しする：使われていないアラーム、ダッシュボード、ロググループを確認します。

用途別の監視構成

WebまたはAPIサービス

最初に成功率と応答時間を利用者指標として置き、EC2、ロードバランサー、RDS、Lambdaなどの標準メトリクスを原因調査用に加えます。

アプリケーションログとアクセスログには、同じリクエストを追える識別子を含めます。

SLO違反を重大通知へつなげ、容量不足などの予兆は警告として別経路で扱います。

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

リクエストの応答時間ではなく、開始件数、完了件数、失敗件数、処理時間、未処理件数を中心に監視します。

「エラーが出たか」だけでなく、「予定した時刻までに完了したか」を確認できるメトリクスが必要です。

各処理段階のログへジョブIDを付けると、失敗した入力と停止箇所を追いやすくなります。

複数アカウントとマルチクラウド

複数のAWSアカウントでは、監視用アカウントへ必要な運用データを集約する構成を検討します。

複数クラウドを横断する場合は、Grafanaなどの共通画面を置く方法がありますが、クラウド固有の詳細情報まで一律に移す必要はありません。

誰がどのログとメトリクスを閲覧できるかは、AWS IAMの権限設計と合わせて決めます。

カスタムメトリクスを送信する例

次のPythonコードは、注文作成数をCloudWatch Metricsへ送る最小例です。

実行環境には、認証情報をコードへ書かず、必要なAPI操作だけを許可したIAMロールを設定します。

from datetime import datetime, timezone

import boto3

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


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

このメトリクスをSLOやアラームに使う前に、何を一件と数えるのか、再試行や重複をどう扱うのかを決めます。

定義が曖昧な数値は、正確に収集できても判断には使えません。

よくある失敗と修正方法

導入時のチェックリスト

1. 利用者が困る状態を一つ選び、対応するSLIを定義する。
2. 現在値を確認し、根拠のあるSLOと評価期間を決める。
3. 原因調査に必要なインフラ指標、ログ、トレースを選ぶ。
4. ロググループの分け方、命名規則、保持期間を決める。
5. 通知レベルごとに受信者、対応期限、最初の確認手順を決める。
6. 担当者向けと事業責任者向けのダッシュボードを分ける。
7. 収集量と費用を確認し、不要なデータを定期的に見直す。

CloudWatch設計の結論

CloudWatchは、メトリクス、ログ、トレース、アラーム、ダッシュボードを通じて、異常の検知から原因調査までを支える基盤です。

最初に作るべきものは大量のグラフではなく、利用者への影響を表すSLI、その目標であるSLO、目標を外れたときの対応手順です。

この順序を守れば、Google CloudやAzureへ移っても、製品名に左右されず同じ設計判断を応用できます。