CloudWatch Syntheticsで死活監視を自動化する方法【SRE実践ガイド】

AWSのメトリクスやログを監視しているのに、ユーザーからの「サイトが落ちています」という報告で初めて障害に気づいた——そんな経験はないでしょうか。

CloudWatchでCPU使用率やエラー率を監視していても、実際にユーザー目線でサービスにアクセスできるかどうかは、別の仕組みで確認する必要があります。この「ユーザー視点での死活監視」を自動化するのが CloudWatch Synthetics です。

本記事では、CloudWatch Syntheticsの概要から、Canaryの作成手順、アラーム設定、本番運用でのベストプラクティスまでを体系的に解説します。

この記事でわかること
– CloudWatch Syntheticsの仕組みとCanaryの概念
– AWSコンソールからCanaryを作成してURLの死活監視を設定する手順
– VPC内リソースの監視方法とよくあるエラーの対処法
– SLIとしてSyntheticsを活用する設計パターン

前提条件
– AWSアカウントがあり、CloudWatchの基本操作ができること
– CloudWatch Alarmsの基本概念を理解していること（CloudWatchアラートの設定方法を参照）

---

CloudWatch Syntheticsとは

CloudWatch Syntheticsは、定期的に自動でHTTPリクエストやUIアクションを実行して、エンドポイントの死活監視やページの動作確認を行うAWSのサービスです。

このような外形監視（Synthetic Monitoring）は、CloudWatchのメトリクス監視（内部から見たシステムの状態）とは根本的に異なります。

内部監視（メトリクス）と外形監視（Synthetics）の違い:

graph TD

A["内部監視（CloudWatch Metrics）"] --> B["CPU・メモリ・エラー率などを計測"]

B --> C["インフラが正常かどうかを把握する"]

D["外形監視（CloudWatch Synthetics）"] --> E["外部からHTTPリクエストを定期実行"]

E --> F["ユーザーが実際にアクセスできるかを確認する"]

インフラ側のメトリクスがすべて正常値を示していても、ネットワーク経路やロードバランサーの設定によってユーザーがアクセスできないケースがあります。CloudWatch Syntheticsはそのギャップを埋める役割を担います。

Canaryとは

CloudWatch SyntheticsではスクリプトをCanary（カナリア）という単位で管理します。Canaryとはもともと炭鉱で毒ガスの検知に使われたカナリアに由来する言葉で、「先に危険を検知するもの」という意味で使われます。

Canaryを使うことで次のことができます。

• 指定したURLにHTTP GETリクエストを送り、ステータスコードが200かどうかを確認する
• Selenium形式のスクリプトでブラウザ操作を自動化し、画面のUIが正しく動作するかを確認する
• REST APIのレスポンスをチェックして、JSONの特定フィールドが期待値通りかを確認する

料金体系

Canaryの料金は実行回数に応じた従量課金です。2025年時点の料金は以下のとおりです。

内容	料金（東京リージョン）
Canary実行	$0.0019 / 回
無料枠	100回 / 月

5分ごとに1回実行するCanaryを1つ動かした場合、月間約8,640回の実行になります。Canary実行料だけで約$16（約2,400円）、Lambda・S3・CloudWatch Logsの追加コストを合わせると月3,000〜3,500円程度が目安です。

構成によってはコストが大きく跳ね上がる点に注意が必要です。1分間隔に変更するとCanary実行回数が5倍になります。1 Canaryだけで月1.5〜1.6万円程度（実行料約12,300円＋Lambda・S3等約3,500円）になり、2つ動かせば月3万円を超えるケースもあります。コストを抑えたい場合は監視頻度を5〜10分ごとにし、スクリーンショット取得は必要最小限にとどめることを推奨します。

---

CloudWatch Syntheticsの仕組み

Canaryの実行フロー

Canaryを設定すると、AWSが管理するLambda関数が定期的に実行されます。このLambda関数がHTTPリクエストやブラウザ操作を実行し、結果をCloudWatchに記録します。

graph TD

A["CloudWatch Synthetics

（スケジューラ）"] --> B["Lambda関数

（Canaryスクリプト）"]

B --> C["監視対象エンドポイント

（URL・API）"]

C --> D{"レスポンス確認"}

D -->|"成功（200 OK）"| E["CloudWatch Metrics

SuccessPercent: 100"]

D -->|"失敗（エラー・タイムアウト）"| F["CloudWatch Metrics

SuccessPercent: 0"]

E --> G["アラーム: OK状態"]

F --> H["アラーム: ALARM状態

→ SNS通知"]

Canaryの実行結果はCloudWatchのカスタムメトリクスとして記録されます。主要なメトリクスは次の2つです。

• SuccessPercent: 成功率（%）。100が正常、0が完全失敗
• Duration: 実行時間（ミリ秒）。レスポンス速度の監視に使用

なぜHTTPステータスコード（200番台）ではなくSuccessPercentを使うのか？

ALBなどのメトリクスには HTTPCode_Target_2XX_Count（200番台レスポンス数）がありますが、SyntheticsではSuccessPercentを使います。理由は2つあります。

1つ目は計測する視点が違うからです。ALBの200番台カウントは「インフラが正常にリクエストを処理した数」を示すインフラ側の指標です。一方、SuccessPercentは「外部からCanaryがアクセスした結果、期待通りのレスポンスが返ってきた割合」であり、ユーザー視点での成否を表します。ネットワーク経路の問題やタイムアウトなど、ALBの正常動作とは無関係な障害もSuccessPercentには反映されます。

2つ目はSLIとして使いやすいからです。SuccessPercentは0〜100%に正規化された割合のため、SLO（例: 99.9%以上を維持する）を定義しやすく、エラーバジェットの計算に直接使えます。200番台カウントは絶対数なので、リクエスト数の増減に左右されて比率ベースでの評価には向きません。

サポートされているランタイム

Canaryスクリプトはいくつかのランタイムで実行できます。

ランタイム	特徴	使いどころ
syn-nodejs-puppeteer-7.0	Puppeteerを使ったブラウザ自動化	UI操作・スクリーンショット確認
syn-python-selenium-3.0	SeleniumベースのUI自動化	Selenium資産の流用
syn-nodejs-puppeteer（Heartbeat用）	URLへのHTTPリクエストのみ	シンプルな死活監視

死活監視だけであれば、Heartbeatランタイムを使うのが最もシンプルです。UIの操作まで確認したい場合はPuppeteerやSeleniumを使います。

監視結果の確認方法

実行結果はCloudWatchコンソールの「Synthetics Canaries」から確認できます。各実行のHTTPステータスコード、レスポンスタイム、スクリーンショット（設定している場合）を一覧で確認できるため、障害発生時の原因調査にも活用できます。

---

CloudWatch SyntheticsでCanaryを作成する手順

Step 1: AWSコンソールでCanaryを作成する

1. AWSコンソールにログインし、CloudWatchを開く
2. 左メニューの「Synthetics Canaries」をクリック
3. 「Canaryを作成」ボタンをクリック

Canaryの作成画面では「設計図を使用」と「スクリプトを使用」の2つが選べます。初めて設定する場合は 「設計図を使用」→「Heartbeat monitoring」 を選択してください。

Step 2: URLハートビートCanaryの設定

Heartbeat設定画面で以下を入力します。

基本設定:

項目	設定値の例	説明
Canary名	prod-api-heartbeat	わかりやすい名前をつける
アプリケーションまたはエンドポイントのURL	https://example.com/health	監視対象のURL
スケジュール	5分ごと	実行間隔
ランタイムバージョン	syn-nodejs-puppeteer-7.0	最新の安定版を選ぶ
保存期間	1か月	ログ・スクリーンショットの保持期間

IAMロールの設定:

Canaryの実行にはIAMロールが必要です。初回は「自動的に作成」を選択すると必要な権限が自動で付与されます。既存のロールを使う場合は以下のポリシーが含まれていることを確認してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:GetBucketLocation",
        "s3:ListAllMyBuckets",
        "cloudwatch:PutMetricData",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

S3バケットの設定:

Canaryの実行結果（ログ・スクリーンショット）はS3に保存されます。バケット名は cw-syn-results-{アカウントID}-{リージョン} の形式で自動作成されます。保存コストを抑えたい場合は、ライフサイクルルールで30日後に削除するように設定しておくことを推奨します。

Step 3: アラームと通知の設定

Canaryの作成後、CloudWatch Alarmsで通知を設定します。Canaryの作成画面にある「CloudWatchアラーム」セクションで設定するか、後からCloudWatch Alarmsで手動作成できます。

アラームの設定例:

メトリクス  : CloudWatchSynthetics / Canary名
メトリクス名: SuccessPercent
統計       : 平均値
期間       : 5分
条件       : SuccessPercent < 100 が 1回 連続した場合
アクション  : SNSトピック（例: pagerduty-integration または slack-notification）

成功率（SuccessPercent）が100%を下回った場合にアラームを発火させます。1回の失敗でアラームを出すか、2〜3回連続失敗でアラームを出すかは運用方針によって変わります。

フリッピング（誤検知）を防ぐ設計:

一時的なネットワークの揺らぎによる誤検知を防ぐために、「2回連続で失敗したらアラーム」とする設定が多くの現場で採用されています。

評価期間: 2
アラーム条件: 2/2 のデータポイントが閾値を超えた場合

---

よくあるエラーとトラブルシューティング

Canaryが失敗し続ける（SuccessPercent: 0）

原因1: URLが存在しない・到達できない

まずCanaryが実行されているリージョンから実際にそのURLにアクセスできるかを確認します。CloudWatchのSyntheticsは東京リージョン（ap-northeast-1）で実行されますが、VPCの設定によってはインターネットに出られない場合があります。

原因2: タイムアウト

デフォルトのタイムアウトは2000ミリ秒（2秒）です。レスポンスが遅いAPIを監視している場合はタイムアウト値を上げてください。Puppeteerランタイムでは以下のように設定します。

const synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const apiCanaryBlueprint = async function () {
  const requestOptions = {
    hostname: 'example.com',
    method: 'GET',
    path: '/health',
    port: 443,
    protocol: 'https:',
  };
  const stepConfig = {
    includeRequestHeaders: false,
    includeResponseHeaders: false,
    includeRequestBody: false,
    includeResponseBody: false,
    continueOnStepFailure: false,
    restrictedHeaders: [],
    restrictedUrlParameters: []
  };
  await synthetics.executeHttpStep(
    'Verify GET /health',
    requestOptions,
    async function(res) {
      return new Promise((resolve, reject) => {
        if (res.statusCode !== 200) {
          reject(new Error(`Expected 200 but got ${res.statusCode}`));
        } else {
          resolve();
        }
      });
    },
    stepConfig
  );
};

exports.handler = async () => {
  return await apiCanaryBlueprint();
};

CloudWatchアラームが発火しない

Canaryが失敗しているのにアラームが発火しない場合、アラームのメトリクス設定が正しくない可能性があります。以下を確認してください。

1. 名前空間が正しいか: CloudWatchSynthetics を選択しているか（デフォルトのCW名前空間ではない）
2. Canary名がメトリクスのディメンションに含まれているか: アラーム設定時に CanaryName = prod-api-heartbeat のようにディメンションを指定する
3. 評価期間の設定: データポイントが存在しない場合のアラーム状態を「データ不足時はアラーム扱い」にしているか

VPC内のリソースを監視する

プライベートサブネット内のリソース（Aurora・ElastiCacheなど）をSyntheticsで監視したい場合は、CanaryをVPC内で実行するよう設定します。

設定手順:

1. Canary作成時に「VPCオプション」を展開する
2. 実行対象のVPC・プライベートサブネットを選択する
3. Canaryに適用するセキュリティグループを選択する（監視対象リソースへの通信を許可したもの）

注意点:

VPC内のCanaryがCloudWatchにメトリクスを送信するには、VPC内からCloudWatchのエンドポイントにアクセスできる必要があります。以下のどちらかの設定が必要です。

• VPCエンドポイント（推奨）: com.amazonaws.ap-northeast-1.monitoring のインターフェース型VPCエンドポイントを作成する
• NATゲートウェイ経由: プライベートサブネットからNATゲートウェイを通じてインターネットにアクセスできるようにする

---

本番環境でのベストプラクティス

監視頻度の設計

監視頻度はサービスのRTO（目標復旧時間）から逆算して設定します。

RTO	推奨監視頻度	用途
1分以内	1分ごと	決済・認証など重要エンドポイント
5分以内	5分ごと	一般的なAPIエンドポイント
15〜30分以内	10〜15分ごと	重要度の低いページ・バッチ処理

頻度を上げるほど検知が早くなりますが、コストと Lambda の実行回数が増えます。重要なエンドポイントに絞って高頻度監視を設定し、その他は5分ごとにするのが現実的です。

複数リージョンでの監視

グローバルサービスや、ユーザーが複数の地理的エリアにいる場合は、複数リージョンにCanaryを設定することでユーザー体験の差異を検知できます。

東京リージョン    (ap-northeast-1) → 国内ユーザー向け監視
バージニア北部    (us-east-1)      → 米国ユーザー向け監視
フランクフルト    (eu-west-1)      → 欧州ユーザー向け監視

Terraform を使ってマルチリージョンで同一のCanaryを展開する場合は、provider に複数リージョンを定義してモジュールを使い回す方法が効率的です。

module "canary_tokyo" {
  source       = "./modules/synthetics-canary"
  canary_name  = "prod-api-heartbeat"
  endpoint_url = "https://example.com/health"
  schedule     = "rate(5 minutes)"
  providers = {
    aws = aws.tokyo
  }
}

module "canary_virginia" {
  source       = "./modules/synthetics-canary"
  canary_name  = "prod-api-heartbeat"
  endpoint_url = "https://example.com/health"
  schedule     = "rate(5 minutes)"
  providers = {
    aws = aws.virginia
  }
}

SLIとしてSyntheticsを活用する

CloudWatch Syntheticsの SuccessPercent メトリクスはそのままSLI（サービスレベル指標）として活用できます。

SLI設計の例:

SLI: 外形監視の成功率
  = CloudWatchSynthetics / SuccessPercent (prod-api-heartbeat)

SLO: 過去30日間で 99.9% 以上の成功率を維持する
  → エラーバジェット: 30日 × 24時間 × 60分 × 0.1% ≒ 約43分

アラート設計:
  - 即時通知: SuccessPercent < 100 が 2分間継続
  - エラーバジェット消費警告: 直近1時間の成功率 < 99.5%

SLOとの組み合わせについては「SLIとSLOの設計入門」の記事も合わせて参照してください。

---

まとめ

本記事で解説した内容をまとめます。

• CloudWatch Synthetics は、外部からHTTPリクエストを定期実行してユーザー視点での死活監視を自動化するサービス
• Canary はSyntheticsのスクリプト実行単位。Heartbeatランタイムを使えばコードなしでURLの死活監視を設定できる
• アラーム設定では SuccessPercent メトリクスを使い、2回連続失敗でアラームを出す設計が誤検知を防ぐうえで有効
• VPC内リソースを監視する場合はVPCエンドポイントの設定が必要
• SuccessPercent をSLIとして活用することで、SLOベースの監視体制を整えられる

CloudWatch Syntheticsを導入することで、「インフラは正常なのにユーザーがアクセスできない」という状況を早期に検知できるようになります。CloudWatch MetricsやLogsと組み合わせることで、観測可能性（Observability）をより高い水準に引き上げられます。

---

AWSの監視設計をSREの視点で体系的に学びたい方へ

本記事で解説したCloudWatch Syntheticsを含む、SREとしてAWSを使いこなすための知識を1本のコースにまとめています。CloudWatch・SLO設計・インシデント対応まで、実務で使えるノウハウを凝縮しています。

👉 Udemy「AWS×SRE入門〜CloudWatchで学ぶ監視設計の基礎〜」を見る

CloudWatchの設定・アラート設計・SLOの考え方をずんだもん解説で学ぶ入門コースです。セール時は1,500円前後で受講できます。