---
title: "CloudWatch Syntheticsの使い方と料金：Canaryの作成手順・東京の単価・ランタイム選定【2026年11月】"
url: "https://www.issoh.co.jp/tech/details/4399/"
published: 2024-12-04
updated: 2026-11-03
categories: ["AWS"]
publisher: "株式会社一創"
---

# CloudWatch Syntheticsの使い方と料金：Canaryの作成手順・東京の単価・ランタイム選定【2026年11月】

CloudWatch Synthetics（シンセティックス）は、AWSアカウント内のLambdaで「Canary」と呼ぶ監視スクリプトを定期実行し、公開中のWebページやAPIを外側から叩いて確かめるサービスです。この記事では、Canaryをコンソールとコードで作る手順、文字列まで検証するスクリプト例、東京リージョンの単価で出した月額、ランタイムの選び方を、2026年11月3日時点のAWS公式ドキュメントと料金データで確認して書きます。外形監視という考え方そのものや内部監視との違いは[外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説](/tech/details/15223/)にまとめています。

## まとめ：CloudWatch Syntheticsの料金と選び方の要点

料金はCanaryの実行1回ごとの従量課金で、東京リージョンは1回0.0019USD、米国東部（バージニア北部）は0.0012USDです。東京で5分間隔のCanaryを1本回すと月16.42USD、1分間隔なら月82.08USD（30日換算・実行料金のみ）。課金の単位が実行回数なので、費用は「何本を何分間隔で回すか」でほぼ決まります。

ランタイムの既定解は`syn-nodejs-puppeteer-18.0`です。API canary・リンク切れ検出・Canary Recorderの各ブループリントと、X-Rayのアクティブトレースが、Playwrightランタイムでは使えないためです。HTTP・DNS・SSL・TCPの単純な疎通だけを見るなら、ブラウザを積まない`syn-nodejs-5.3`でMulti checksブループリントを使い、最大10チェックを1本に束ねると実行回数を減らせます。

IP制限のかかったサイトは、CanaryをVPCに入れてNATゲートウェイの固定IPから公開URLを叩けば、外形監視のまま監視できます。公開サイトの監視で避けるべきなのは、VPC内からプライベートIPや内部向けの名前を直接叩く構成です。公開ユーザーが通る公開DNS・CDN・WAFを通らないため、公開経路の障害を検知できません。

## Canaryの仕組み：Lambda・S3・メトリクスの関係

Canaryの実体はLambda関数です。作成すると、名前が`Synthetics`で始まるランタイムのレイヤーが関数に付き、指定したスケジュールでブラウザまたはHTTPクライアントが起動します。実行のたびにスクリーンショット・HARファイル・ログがS3へ、成功率`SuccessPercent`と所要時間`Duration`がCloudWatchの`CloudWatchSynthetics`名前空間へ送られます。アラームはこのメトリクスに張ります。

保存先を指定しないと`cw-syn-results-{アカウントID}-{リージョン}`というS3バケットが作られ、Canaryを消してもバケットと中身は残ります。監視対象を入れ替えるたびに作り直す運用では、バケットにライフサイクルルールを最初に入れておくと保存料金が積み上がりません。CloudFormationで作る場合は`ProvisionedResourceCleanup: AUTOMATIC`を指定すると、Canary削除時にLambda関数とレイヤーも消えます（[AWS::Synthetics::Canary](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-synthetics-canary.html)）。

## コンソールでCanaryを作成する手順

入口はCloudWatchコンソールの「Application Signals」→「Synthetics Canaries」→「Create Canary」です（[Creating a canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FCreate.html)）。古い解説記事の画面とはメニューの位置が違うので、ここから入ります。

1. 作り方を選ぶ：ブループリントを使う／自作スクリプトをアップロード／S3から取り込む、のいずれか。S3から取り込むときはバケットをCanaryと同じリージョンに置く。
2. 名前・監視URL・ランタイムを入れる。名前は小文字英数字とハイフン等で、Lambda関数名の一部になる。
3. 「Locations」で追加のリージョンを選ぶと、同じCanaryを複数リージョンから回せる（後述のマルチロケーション）。
4. スケジュールを選ぶ：1回だけ／rate式で継続／cron式。コンソールのrate式は1分に1回から1時間に1回まで。
5. タイムアウトを設定する場合は15秒以上にする。Lambdaのコールドスタートと計装の起動時間を見込むためで、公式の注意書きどおり。
6. データ保持（成功・失敗それぞれ1〜455日）、保存先S3、IAMロール、アラーム、必要ならVPCを指定して作成する。

ブループリントは7種類あります。URLを開いてスクリーンショットを撮るHeartbeat監視、複数のAPIをHTTPステップとして叩くAPI canary、ページ内リンクを辿るBroken link checker、基準画像と比べるVisual monitoring、Chrome拡張で操作を記録するCanary recorder、コードなしで「クリック・入力・文字列確認」を組めるGUI workflow builder、そしてJSONでHTTP・DNS・SSL・TCPを束ねるMulti checksです。

Canary recorderで記録したスクリプトは、そのまま本番に載せないでください。id属性の無い要素はCSSセレクタで記録されるので画面の改修で壊れやすく、文言の存在確認も生成されないため、エラー画面に遷移しても操作が最後まで流れれば成功になります。次章のような検証コードを足す前提の下書きとして使います。

## 文字列まで検証するCanaryスクリプトとCloudFormationの例

HTTP 200が返るだけでは、メンテナンス画面やエラーページを返していても成功になります。売上に直結するページは、表示されるべき文言があるかまで見ておくと誤った「緑」を防げます。`syn-nodejs-puppeteer-11.0`以降は、ルートに`index.js`を置いてZIPにするだけで取り込めます（[Puppeteerランタイムでのスクリプトの書き方](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FWritingCanary%5FNodejs%5FPup.html)）。

```
const synthetics = require('@aws/synthetics-puppeteer');
const log = require('@aws/synthetics-logger');

// 監視先と期待する文言は環境変数で渡す（秘密情報は入れない）
const TARGET_URL = process.env.TARGET_URL;
const EXPECTED_TEXT = process.env.EXPECTED_TEXT;

const checkTopPage = async function () {
  if (!TARGET_URL || !EXPECTED_TEXT) {
    throw new Error('TARGET_URL and EXPECTED_TEXT are required');
  }
  const page = await synthetics.getPage();

  await synthetics.executeStep('loadTopPage', async function () {
    const response = await page.goto(TARGET_URL, { waitUntil: 'domcontentloaded', timeout: 30000 });
    const status = response ? response.status() : 0;
    if (status !== 200) {
      throw new Error('unexpected status: ' + status);
    }
  });

  await synthetics.executeStep('verifyText', async function () {
    // 後から描画される文言も待つ。15秒で見つからなければ例外で失敗にする
    await page.waitForFunction(
      (text) => document.body !== null && document.body.innerText.includes(text),
      { timeout: 15000 },
      EXPECTED_TEXT
    );
    log.info('expected text found');
  });
};

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

`executeStep`は、渡した関数が例外を投げればそのステップを失敗として記録し、ステップ名ごとの`SuccessPercent`と`Duration`を発行して、前後のスクリーンショットも撮ります。どの段階で落ちたかがステップ単位で分かるので、ページ読み込みと文言確認は別ステップに分けておくと原因の切り分けが速くなります。環境変数は保存時に暗号化され、2026年7月16日からはカスタマー管理のKMSキーも指定できるようになりました（[AWSの新機能告知](https://aws.amazon.com/about-aws/whats-new/2026/07/synthetics-customer-managed-keys/)）。それでもAPIリファレンスは機密情報を入れないよう明記しているので、パスワードやAPIキーはSecrets Managerに置いてください。

コードで管理するならCloudFormationの`AWS::Synthetics::Canary`を使います。次の例は、実行ロール・コード用と結果用のS3バケット・上のスクリプトを固めたZIPを先に用意してある前提で、URLと期待文言は自社の値に置き換えます。

```
Resources:
  TopPageCanary:
    Type: AWS::Synthetics::Canary
    Properties:
      Name: top-page-check
      RuntimeVersion: syn-nodejs-puppeteer-18.0
      ExecutionRoleArn: arn:aws:iam::123456789012:role/SyntheticsCanaryRole
      ArtifactS3Location: s3://my-canary-artifacts/top-page-check
      Code:
        S3Bucket: my-canary-code
        S3Key: top-page-check.zip
        Handler: index.handler
      Schedule:
        Expression: rate(5 minutes)
        DurationInSeconds: "0"
      RunConfig:
        TimeoutInSeconds: 60
        EnvironmentVariables:
          TARGET_URL: https://www.example.com/
          EXPECTED_TEXT: お問い合わせ
      SuccessRetentionPeriod: 31
      FailureRetentionPeriod: 31
      StartCanaryAfterCreation: true
      ProvisionedResourceCleanup: AUTOMATIC
```

ここで一番の落とし穴は`DurationInSeconds`です。公式ドキュメントのサンプルテンプレートは`3600`を指定しており、これは「スケジュールに従って3600秒間だけ実行を続ける」という意味です。写して使うと、監視は1時間で止まります。0を指定するか省略すれば、停止するまで実行が続きます（[Schedule](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-synthetics-canary-schedule.html)）。実行ロールには`s3:PutObject`・`cloudwatch:PutMetricData`・`logs:PutLogEvents`などが要り、信頼ポリシーのプリンシパルは`lambda.amazonaws.com`です。

## 東京リージョンの料金と月額の計算

Canaryの単価は、AWS Price List APIの2026年10月7日公開データで東京が1回0.0019USD、米国東部が0.0012USDです。無料利用枠は全リージョン合計で月100回。料金ページに出てくる例は米国東部の単価なので、東京で見積もるときは約1.6倍になる点に注意してください（[Amazon CloudWatch料金](https://aws.amazon.com/cloudwatch/pricing/)）。

| 実行間隔 | 月間実行回数  | 東京 1本     | 東京 10本     | 米国東部 1本   |
| ---- | ------- | --------- | ---------- | --------- |
| 1分   | 43,200回 | 82.08 USD | 820.80 USD | 51.84 USD |
| 5分   | 8,640回  | 16.42 USD | 164.16 USD | 10.37 USD |
| 15分  | 2,880回  | 5.47 USD  | 54.72 USD  | 3.46 USD  |
| 1時間  | 720回    | 1.37 USD  | 13.68 USD  | 0.86 USD  |

表は30日換算の実行料金だけで、無料枠は引いていません。実際の請求には、Lambdaのリクエストと実行時間、CloudWatch Logsの取り込みと保存、S3の保存とリクエスト、ステップごとに増えるカスタムメトリクス、アラームの料金が別に乗ります。ブラウザを起動するCanaryはLambdaの実行時間が長くなりやすく、既定ではステップの前後でスクリーンショットも保存するので、HTTPだけのCanaryより付随費用が大きくなります。

### 間隔の仕分けとMulti checksによる実行料金の削減

監視対象が20URLあるとします。全部を東京で1分間隔にすると実行料金だけで月1,641.60USD。売上に直結する3本だけを1分間隔にし、残り17本を15分間隔に落とすと、3×82.08＋17×5.472＝月339.26USDまで下がります。1分遅れて気付くと困るページと、15分後でも足りるページを分ける作業が、そのまま費用の設計になります。

残り17本がブラウザ操作の要らない単純な疎通確認なら、Multi checksブループリントでさらに減らせます。1本のCanaryにHTTP・DNS・SSL・TCPのチェックを最大10個まで載せられるので、17URLは2本に収まり、15分間隔なら月10.94USD。合計は月257.18USDです。Canaryとしての成否は1本単位ですが、チェックごとのステップメトリクスも出るので、URLごとに通知先を分けたいときはステップのメトリクスに個別のアラームを張ります。

Multi checksは`blueprint-config.json`という名前のJSONをZIPにして渡します。次の例は、トップページの200応答と、証明書の残り日数が30日を切っていないことを1本で確かめる設定です（[Multi checksのJSON設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FWritingCanary%5FMultichecks.html)）。

```
{
  "globalSettings": { "stepTimeout": 30000 },
  "steps": {
    "1": {
      "stepName": "topPage",
      "checkerType": "HTTP",
      "url": "https://www.example.com/",
      "httpMethod": "GET",
      "assertions": [
        { "type": "STATUS_CODE", "operator": "EQUALS", "value": 200 }
      ]
    },
    "2": {
      "stepName": "certExpiry",
      "checkerType": "SSL",
      "hostname": "www.example.com",
      "assertions": [
        { "type": "CERTIFICATE_EXPIRY", "operator": "GREATER_THAN", "value": 30, "unit": "DAYS" }
      ]
    }
  }
}
```

Multi checksを使うにはランタイムが`syn-nodejs-3.0`以降であること、CloudFormationやAPIでは`Handler`の代わりに`BlueprintTypes: ["multi-checks"]`を指定することが条件です。応答本文は1MBまで、変数は10個までという制限があります。

## ランタイム5系統の最新版と選び方

ランタイムは、Syntheticsのライブラリと依存関係をまとめたLambdaレイヤーです。2026年11月3日時点のドキュメントで、各系統の最新版は次のとおりです（[Synthetics runtime versions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FLibrary.html)）。

| 系統                   | 最新版                       | 実行基盤         | フレームワーク                | Chromium      |
| -------------------- | ------------------------- | ------------ | ---------------------- | ------------- |
| Node.js + Puppeteer  | syn-nodejs-puppeteer-18.0 | Node.js 22.x | Puppeteer-core 25.11.0 | 153.0.8010.36 |
| Node.js + Playwright | syn-nodejs-playwright-9.0 | Node.js 22.x | Playwright 1.63.0      | 153.0.8010.36 |
| Python + Selenium    | syn-python-selenium-13.0  | Python 3.12  | Selenium 4.32.0        | 153.0.8010.36 |
| Node.js（ブラウザなし）      | syn-nodejs-5.3            | Node.js 22.x | なし                     | なし            |
| Java（ブラウザなし）         | syn-java-1.0              | Java 21      | なし                     | なし            |

この記事を前回更新した2026年7月28日には、同じ一覧の最新がPuppeteer 16.1・Playwright 7.1・Selenium 11.1でした。約3か月で各系統2世代進んだことになります。新しい版はChromiumの脆弱性対応（CVE）が主な変更です。Puppeteer系とPlaywright系はFirefoxも同梱しています。

### Playwrightを既定にしない理由

最新という理由でPlaywright系を選ぶと、作成画面で行き詰まります。公式ドキュメントは、API canary、Broken link checker、Canary recorderの各ブループリントをPlaywrightランタイム非対応と明記しています（[Using canary blueprints](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FBlueprints.html)）。Visual monitoringは食い違いがあり、ブループリントのページはPlaywrightとPython+Seleniumでは使えないとする一方、`syn-nodejs-playwright-3.0`の変更履歴には「visual monitoringに対応」とあります。ブループリントから作るならPuppeteer系が確実です。X-Rayのアクティブトレースも「PuppeteerとJavaのランタイムだけ」です。トレースを有効にすると実行時間が2.5〜7%伸び、X-Ray側の料金がかかり、Firefoxで動かすCanaryでは出ません。

Playwright系を選ぶのは、既存のPlaywrightテスト資産を流用し、自作スクリプトでブラウザシナリオだけを回すと決めたときです。Python系はSeleniumのスクリプト資産を持ち込む場合、Java系はブラウザを起動しないAPI監視をJavaで書きたい場合に絞られます。

### 非推奨ランタイムの扱い

ランタイムは構成部品のサポートが切れた時点で非推奨になります。2026年は1月22日に`syn-nodejs-puppeteer-7.0`・`6.2`・`5.2`と`syn-python-selenium-3.0`・`2.1`が、2月3日に`syn-python-selenium-5.1`〜`4.0`が非推奨になりました（[Runtime versions support policy](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FRuntime%5FSupport%5FPolicy.html)）。Seleniumの個別ページは今もこれらを「サポート対象」の節に残しており、一覧表と食い違っています。一覧表を正として扱うのが安全です。

非推奨になっても既存のCanaryは止まりません。できなくなるのは、そのランタイムでの新規作成だけです。停止・開始・削除も、サポート対象のランタイムへの更新もできます。AWSは非推奨予定の60日前にメールで知らせます。ただし非推奨のランタイムは古いChromiumで自社サイトを叩き続けることになります。Chromiumの脆弱性修正を含む新版が出たら、通知を待たずに検証用のCanaryで試してから本番を寄せる運用を勧めます。Selenium系は5.1以下がPython 3.9、6.0〜10.0がPython 3.11、11.0以降がPython 3.12なので、古い版から上げるときは依存ライブラリの確認が伴います。

Puppeteer系は`syn-nodejs-puppeteer-13.1`以降で読み込むモジュール名が`Synthetics`から`@aws/synthetics-puppeteer`へ、Playwright系は`5.1`以降で`@amzn/synthetics-playwright`から`@aws/synthetics-playwright`へ変わりました。古い名前は将来廃止予定なので、ランタイムを上げるときはrequire（import）文も書き換えます。

## IP制限・Basic認証のあるサイトを監視する設定

社内IPだけを許可している管理画面や、ステージング環境の公開URLを監視したいことがあります。Canaryは既定ではAWSの共有IPから出ていくので、送信元IPを固定するにはVPCに入れます。公式ドキュメントも、NATゲートウェイ経由のインターネット接続を「Canaryに固定IPアドレスを割り当てる」方法として案内しています（[Running a canary on a VPC](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FVPC.html)）。

1. VPCで「DNS Resolution」と「DNS hostnames」の両方を有効にする。
2. パブリックサブネットにNATゲートウェイを作り、Elastic IPを監視対象の許可リストに入れる。
3. Canaryを置くプライベートサブネットのルートテーブルに、宛先`0.0.0.0/0`・ターゲットNATゲートウェイのルートを足す。
4. Canary作成時にそのVPC・プライベートサブネット・セキュリティグループ（外向き443を許可）を指定する。

この構成なら、Canaryは公開DNSで名前を引き、CDNやWAFを通って公開URLに届くので、外形監視として成り立ちます。NATゲートウェイの時間料金とデータ処理料金が監視のためだけに増える点は見込んでおいてください。

一方で、公開サイトをVPC内から内部ロードバランサのDNS名やプライベートIPで叩くCanaryは、公開サイトの外形監視にはなりません。公開DNS・CDN・WAFといった公開ユーザーの経路を通らないので、公開DNSの設定ミスで外部から誰も届かない状況でも成功を返し続けます。この構成が意味を持つのは、社内向けAPIやイントラネットを社内利用者と同じ経路から確かめる場合です。メトリクスとS3への送信だけならNATゲートウェイを置かず、CloudWatch用のインターフェースエンドポイント（`com.amazonaws.{region}.monitoring`）とS3のゲートウェイエンドポイントで済ませられます。

Basic認証やAPIキーが要るエンドポイントは、Multi checksブループリントならSecrets Managerの値を`${AWS_SECRET:シークレット名:キー}`の形で参照できます。実行ロールには`secretsmanager:GetSecretValue`と`secretsmanager:DescribeSecret`、カスタマー管理キーで暗号化しているなら`kms:Decrypt`も付けます（[Creating multi checks blueprint canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FMultiCheck%5FBlueprint.html)）。VPC・NAT・IAMをまとめて設計する段階で手が足りない場合は、[AWSのインフラ構築支援](/service/system/aws/)でも監視基盤ごとご相談いただけます。

## マルチロケーションCanaryによる複数リージョンからの監視

1つのリージョンからだけ監視していると、障害がサイト側なのか特定地域からの経路なのかを切り分けられません。マルチロケーションCanaryは、プライマリリージョンで作ったCanaryを選んだリージョンへ自動で複製し、結果をプライマリに集めます（[Multilocation canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FMultiLocation.html)）。複数拠点で同時に失敗したときだけ発報するアラームにすると、1拠点の一時的な揺らぎで人を起こさずに済みます。

- ランタイムは`syn-nodejs-puppeteer-16.0`以降か`syn-nodejs-playwright-7.0`以降が必要（Python・Java・ブラウザなしNode.jsは対象外）。
- レプリカは最大50拠点。AWSの商用リージョン全域で使え、GovCloud（US）と中国リージョンは対象外。
- 作成・更新・開始・停止・削除はすべてプライマリから行う。スクリプト・スケジュール・環境変数は全拠点で共通。
- タグとVPC設定は複製されない。コスト配分タグやVPCはレプリカのリージョンで個別に設定する。
- レプリカ1つにつき、スタンドアロンのCanary1本分の料金がかかる。3拠点にすれば実行料金はほぼ3倍。

## アラームの設定と設定値の上限

Canary作成画面でアラームの自動作成を選ぶと、`SuccessPercent`に対するアラームが作られます。1回の失敗で通知が飛ぶ設定は、ネットワークの一時的な揺らぎで夜間に人を起こします。直近3データポイントのうち2つが閾値を割ったら発報する（M out of N）設定にして、1回きりの失敗では鳴らさないようにしてください。何を「成功」と見なすか、どの水準を守るかの決め方は[SLIとは？SLOとの違いと指標の選び方・PromQLでの測り方](/tech/details/9177/)が参考になります。

| 設定項目    | APIパラメータ                  | 指定できる範囲           | 省略時         |
| ------- | ------------------------- | ----------------- | ----------- |
| メモリ     | MemoryInMB                | 960〜3008MB（64の倍数） | 公式に明示なし     |
| タイムアウト  | TimeoutInSeconds          | 3〜840秒（実行間隔以内）    | 実行間隔（最大14分） |
| 一時ストレージ | EphemeralStorage          | 1024〜10240MB      | 1024MB      |
| データ保持   | SuccessRetentionPeriod ほか | 1〜455日            | 31日         |

ブラウザを起動するCanaryでスクリーンショットの取得に失敗する、実行が不安定になるといった症状が出たら、まず`MemoryInMB`を引き上げます（[CanaryRunConfigInput](https://docs.aws.amazon.com/AmazonSynthetics/latest/APIReference/API%5FCanaryRunConfigInput.html)）。保持期間を455日にしても、Syntheticsコンソールのホーム画面で遡れるのは7日まで、個別Canaryの画面でも絶対指定で30日までです。それより古い結果はS3とCloudWatch Logsから追う前提で設計します。

実行ロールのS3権限は、欠け方で症状が変わります。S3の権限が一切ないCanaryは実行自体は続き、スクリーンショットなどの成果物だけがアップロードされません。一方、`s3:GetBucketLocation`などが一部だけ欠けているとAccess Deniedで失敗になります（[Troubleshooting a failed canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch%5FSynthetics%5FCanaries%5FTroubleshoot.html)）。初回の実行後に、S3へ成果物が届いているかを一度確認してください。

## CloudWatch Syntheticsを選ぶべきでない場面

次の3つのいずれかに当てはまるなら、CloudWatch Syntheticsは適しません。

1つ目は、実ユーザーの体験の分布を知りたい場合です。Canaryの値は監視拠点から見た1本の合成トラフィックで、特定の回線や端末だけが遅いといった偏りは実ユーザー計測（RUM）でしか見えません。

2つ目は、障害の原因を特定したい場合です。Canaryは「ユーザーから見て壊れている」ことを外側から検知しますが、遅い原因がスレッド枯渇か外部API待ちかは答えません。内部の実行時情報を見る[APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説](/tech/details/15414/)や[メトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説](/tech/details/15704/)の担当です。AWS上のサービス単位でSLOまで見たいなら、同じコンソールにある[CloudWatch Application Signalsとは｜料金の実額・SLO設計・2026年の新機能を公式資料で整理](/tech/details/3413/)と組み合わせます。

3つ目は、監視の拠点をAWSリージョンの外に置きたい場合や、監視対象と通知の大半がAWSの外にある場合です。CanaryはAWSリージョン内のLambdaから実行されるので、国内の特定キャリア網や都市ごとの到達性は測れません。また強みはアラーム・ログ・メトリクス・X-RayがAWSの中で完結する点にあり、オンプレミスや他社クラウドが中心で通知も別ツールに集約しているなら、その強みは効きません。マルチクラウドでの実装は[Datadog Syntheticsの実装手順：APIテストとブラウザテストの作り分けと頻度設計](/tech/details/16592/)で扱いました。

## CloudWatch SyntheticsとCanaryについてのよくある質問

### Syntheticsの読み方と意味は何ですか？

「シンセティックス」と読みます。syntheticは「合成の」という意味で、実ユーザーではなく合成したトラフィックで監視することを指します。AWSの日本語ドキュメントでは「合成モニタリング (canary)」と訳されており、「合成監視」もほぼ同じ意味で使われます。

### CloudWatch Syntheticsの料金はいくらですか？

Canaryの実行1回ごとに、東京リージョンで0.0019USD、米国東部で0.0012USDです。月100回までは無料。東京で5分間隔のCanaryを1本回すと月16.42USD、1分間隔で月82.08USDになり、ほかにLambda・CloudWatch Logs・S3の料金が別途かかります。

### Canaryの実行間隔は最短で何分ですか？

rate式では1分に1回が最短で、最長は1時間に1回です。時間帯を絞りたいときはcron式を使います。タイムアウトは実行間隔を超えられないので、1分間隔なら1回の処理を60秒以内に収める必要があります。

### 非推奨になったランタイムのCanaryは止まりますか？

止まりません。そのランタイムでの新規作成ができなくなるだけで、既存のCanaryは実行を続け、停止・開始・削除やサポート対象ランタイムへの更新もできます。非推奨予定の60日前にAWSからメールが届きます。

### PuppeteerとPlaywrightはどちらを選ぶべきですか？

ブループリントやX-Rayトレースを使うなら`syn-nodejs-puppeteer-18.0`です。API canary・Broken link checker・Canary recorderの各ブループリントとX-Rayのアクティブトレースは、Playwrightランタイムに対応していません。既存のPlaywrightテストを流用して自作スクリプトだけで回す場合に、`syn-nodejs-playwright-9.0`を選びます。

## 関連記事

- [外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説](/tech/details/15223/)
- [Datadog Syntheticsの実装手順：APIテストとブラウザテストの作り分けと頻度設計](/tech/details/16592/)
- [CloudWatch Application Signalsとは｜料金の実額・SLO設計・2026年の新機能を公式資料で整理](/tech/details/3413/)
- [APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説](/tech/details/15414/)
- [オブザーバビリティ（可観測性）とは？監視・APM・テレメトリとの違いと使い分け](/column/details/3077/)

---

出典: [CloudWatch Syntheticsの使い方と料金：Canaryの作成手順・東京の単価・ランタイム選定【2026年11月】](<https://www.issoh.co.jp/tech/details/4399/>)（株式会社一創）