Amazon CloudWatch Syntheticsの新機能マルチロケーションカナリアを試してみた
はじめに
2026年6月18日、Amazon CloudWatch Syntheticsがマルチロケーションカナリアをサポートしました。
従来との差分をまとめると以下の通りです。
| 項目 | 従来(シングルリージョン) | マルチロケーションカナリア |
|---|---|---|
| 管理箇所 | リージョンごとに個別カナリア | 設定・結果確認の起点はプライマリに集約 |
| 設定変更 | 各リージョンで個別に操作 | プライマリから一括伝播 |
| 実行結果の確認 | 各リージョンのコンソールを参照 | プライマリで一元確認 |
| アーティファクト | 各リージョンのS3バケット | プライマリのS3バケットに集約 |
| 設定ドリフト | 発生しやすい | 原則発生しない(プライマリが唯一の正) |
前提条件・制約
本機能を利用する前に以下を確認してください。
- 対応ランタイム:
syn-nodejs-puppeteer-16.0以降、またはsyn-nodejs-playwright-7.0以降のみ。Python(Selenium)・Javaランタイムは非対応です - 対応リージョン: CloudWatch Syntheticsが利用可能な商用リージョン。AWS GovCloud・中国リージョンは非対応です
- レプリカ数: 最大50か所
- グループ非対応: グループへの関連付けはできません。既存グループ所属カナリアは、先にグループから外す必要があります
- タグ: タグはレプリカに伝播しません。各レプリカリージョンで個別に設定が必要です
- VPC: VPC設定はリージョン固有のため、そのままレプリカへ引き継がれるわけではありません。本記事ではVPC接続ありのマルチロケーションカナリアは検証対象外です
コストの考え方
マルチロケーションカナリアでは、プライマリに加えてレプリカロケーションでもカナリアが実行されます。そのため、実行回数はロケーション数に応じて増加します。
Syntheticsの料金はカナリア実行1回あたり$0.0012です。31日月で5分間隔のカナリアを実行する場合、1ロケーションあたりの月間実行回数は8,928回です。
| 構成 | 月間実行回数 | Synthetics料金 |
|---|---|---|
| プライマリのみ | 8,928回 | 約$10.71 |
| プライマリ + レプリカ1か所 | 17,856回 | 約$21.43 |
Lambda、S3、CloudWatch Logsなどの付随コストも、実行回数や生成されるログ・アーティファクト量に応じて増加します。
多数のカナリアを運用する場合は、監視頻度の調整や、スクリプト内で複数URLをまとめてチェックする方法も検討できます。
検証: マルチロケーションカナリアを新規作成する
事前準備
カナリアの実行に必要なS3バケットとIAMロールを作成します。
S3バケット(東京リージョン)
aws s3api create-bucket \
--bucket cw-synthetics-multiloc-test-123456789012 \
--region ap-northeast-1 \
--create-bucket-configuration LocationConstraint=ap-northeast-1
IAMロール
カナリアが使用するLambda実行ロールを作成します。信頼ポリシーには lambda.amazonaws.com を指定し、以下の権限を付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"cloudwatch:PutMetricData",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
aws iam create-role \
--role-name cw-synthetics-multiloc-role \
--assume-role-policy-document file://trust-policy.json
aws iam put-role-policy \
--role-name cw-synthetics-multiloc-role \
--policy-name cw-synthetics-multiloc-policy \
--policy-document file://canary-policy.json
カナリアスクリプト
HTTPステータスコードを確認するシンプルなPuppeteerスクリプトを用意し、zip化してS3にアップロードします。
// nodejs/node_modules/index.js
const synthetics = require('Synthetics');
const handler = async () => {
const page = await synthetics.getPage();
const response = await page.goto(
'https://dev.classmethod.jp/articles/aws-waf-monetize-402-large-scale-bot-15m-requests/',
{ waitUntil: 'domcontentloaded', timeout: 30000 }
);
if (response.status() !== 200) {
throw new Error(`HTTP ${response.status()}`);
}
};
exports.handler = handler;
zip -r canary.zip nodejs/
aws s3 cp canary.zip s3://cw-synthetics-multiloc-test-123456789012/scripts/canary.zip
カナリアの作成
--add-replica-locations に us-east-1 を指定して作成します。
aws synthetics create-canary \
--name multiloc-test-canary \
--code 'S3Bucket=cw-synthetics-multiloc-test-123456789012,S3Key=scripts/canary.zip,Handler=index.handler' \
--artifact-s3-location s3://cw-synthetics-multiloc-test-123456789012/canary-artifacts/ \
--execution-role-arn arn:aws:iam::123456789012:role/cw-synthetics-multiloc-role \
--schedule Expression="rate(5 minutes)" \
--runtime-version syn-nodejs-puppeteer-16.0 \
--add-replica-locations '[{"Location":"us-east-1"}]' \
--region ap-northeast-1
レスポンスの MultiLocationConfig に LocationType: Primary と PrimaryLocation: ap-northeast-1 が含まれていました。
create-canaryレスポンス(抜粋)
{
"Canary": {
"Id": "f8a82070-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"Name": "multiloc-test-canary",
"Status": {
"State": "CREATING",
"StateReasonCode": "CREATE_PENDING"
},
"RuntimeVersion": "syn-nodejs-puppeteer-16.0",
"MultiLocationConfig": {
"LocationType": "Primary",
"PrimaryLocation": "ap-northeast-1"
}
}
}
レプリケーション状態の確認
get-canary でレプリカの状態を確認します。作成直後は ReplicationStatus が InProgress です。
aws synthetics get-canary --name multiloc-test-canary --region ap-northeast-1
InProgress状態のレスポンス(抜粋)
"MultiLocationConfig": {
"LocationType": "Primary",
"PrimaryLocation": "ap-northeast-1",
"Replicas": [
{
"Location": "us-east-1",
"ReplicationStatus": {
"State": "InProgress"
},
"CanaryState": "CREATING",
"LastModified": "2026-06-20T03:34:04.726000+09:00"
}
],
"ReplicationState": "InProgress"
}
約30秒後に InSync へ遷移しました。
InSync状態のレスポンス(抜粋)
"MultiLocationConfig": {
"LocationType": "Primary",
"PrimaryLocation": "ap-northeast-1",
"Replicas": [
{
"Location": "us-east-1",
"ReplicationStatus": {
"State": "InSync"
},
"CanaryState": "READY",
"LastModified": "2026-06-20T03:34:33.423000+09:00"
}
],
"ReplicationState": "InSync"
}
レプリカの実体としてバージニア北部(us-east-1)にLambda関数が作成されているかも確認しました。cwsyn-multiloc-test-canary- というプレフィックスで、ランタイムが nodejs22.x、メモリが960 MBの関数が自動作成されていました。
aws lambda list-functions \
--query "Functions[?starts_with(FunctionName, 'cwsyn-multiloc-test-canary')].[FunctionName, Runtime, MemorySize]" \
--region us-east-1
[
[
"cwsyn-multiloc-test-canary-f8a82070-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"nodejs22.x",
960
]
]
検証: 実行結果を確認する
カナリアを起動してしばらく待ってから、get-canary-runs で実行結果を確認しました。
aws synthetics start-canary --name multiloc-test-canary --region ap-northeast-1
aws synthetics get-canary-runs --name multiloc-test-canary --region ap-northeast-1
get-canary-runsレスポンス(抜粋)
{
"CanaryRuns": [
{
"Status": { "State": "PASSED" },
"Timeline": {
"Started": "2026-06-20T03:45:09.635000+09:00",
"Completed": "2026-06-20T03:45:14.762000+09:00"
},
"ArtifactS3Location": "cw-synthetics-multiloc-test-123456789012/canary-artifacts/canary/ap-northeast-1/multiloc-test-canary/2026/06/19/18/us-east-1/45-09-632",
"Location": "us-east-1"
},
{
"Status": { "State": "PASSED" },
"Timeline": {
"Started": "2026-06-20T03:45:08.559000+09:00",
"Completed": "2026-06-20T03:45:11.696000+09:00"
},
"ArtifactS3Location": "cw-synthetics-multiloc-test-123456789012/canary-artifacts/canary/ap-northeast-1/multiloc-test-canary/2026/06/19/18/ap-northeast-1/45-08-556",
"Location": "ap-northeast-1"
}
]
}
両リージョンともPASSEDでした。実行時間は東京(ap-northeast-1)が約3秒、バージニア(us-east-1)が約5秒でした。
アーティファクトのS3パスを見ると、両リージョンの実行結果がプライマリリージョンのバケット配下にリージョン別のプレフィックスで格納されていました。
- プライマリ:
.../ap-northeast-1/45-08-556 - レプリカ:
.../us-east-1/45-09-632
CloudWatchメトリクスも確認しました。Locationディメンション付きで各リージョンのSuccessPercentが発行されており、Locationディメンションを指定しない全ロケーション集計値も取得できました。いずれもプライマリリージョン(ap-northeast-1)に発行されていました。
# 全ロケーション集計
aws cloudwatch get-metric-statistics \
--namespace CloudWatchSynthetics \
--metric-name SuccessPercent \
--dimensions Name=CanaryName,Value=multiloc-test-canary \
--statistics Average --period 300 \
--start-time "2026-06-20T03:30:00+09:00" \
--end-time "2026-06-20T03:50:00+09:00" \
--region ap-northeast-1
{
"Datapoints": [
{ "Timestamp": "2026-06-20T03:40:00+09:00", "Average": 100.0, "Unit": "Percent" },
{ "Timestamp": "2026-06-20T03:35:00+09:00", "Average": 100.0, "Unit": "Percent" }
]
}
Location ディメンションを追加するとap-northeast-1・us-east-1それぞれの SuccessPercent も取得でき、両リージョンともに100% でした。
S3レポートでリージョン別の応答差を確認する
各実行のアーティファクトとしてS3にHARレポート(results.har.html)が保存されます。東京・バージニアそれぞれのレポートを確認したところ、同一ページへのアクセスでもリージョンによって異なるプロファイルが得られました。
pageTimings(ページ全体)
| 東京(ap-northeast-1) | バージニア(us-east-1) | |
|---|---|---|
| onContentLoad | 1,313ms | 1,141ms |
| onLoad | 1,413ms | 1,647ms |
主なリクエストの差
| リソース | 東京 | バージニア |
|---|---|---|
| HTMLページ本体 | 156ms | 145ms |
| dev.classmethod.jp 静的JS(複数) | 9〜34ms | 161〜433ms |
| embed.zenn.studio JS | 383ms | 676ms |
| Google Tag Manager | 109ms | 728ms |
| 画像(devio2024-media) | 159ms前後 | 94〜237ms |
dev.classmethod.jpはCloudFront経由で配信されており、オリジン(ECS/S3)は東京リージョンに配置されています。
今回の計測では静的アセットの応答が東京で大幅に速く、キャッシュミス時にオリジンまでの距離差が表れたものと考えられます。GTMはバージニアからのアクセスで遅延が目立ちました。一方、onContentLoad はバージニアの方が速く出ていますが、これはリソースの並列取得パターンの違いによるものと推測されます。
このように、マルチロケーションカナリアでは「どのリージョンからアクセスするとどのリソースが遅いか」を個別のHARレポートで把握できます。全リージョンでPASSEDでも、特定リージョンからの応答が遅いリソースを特定する手がかりになります。
検証: 削除手順(2ステップ必須)
レプリカが存在する状態で delete-canary を実行するとどうなるか確認しました。
aws synthetics delete-canary --name multiloc-test-canary --region ap-northeast-1
An error occurred (ValidationException) when calling the DeleteCanary operation:
Canary has active replicas. Replicas must be removed before deleting the primary canary.
レプリカが残っている状態ではエラーになります。削除は以下の2ステップが必要です。
Step 1: レプリカロケーションを除去する
update-canary ではレプリカの追加・削除時にも --code と --runtime-version の指定が必要です。既存設定を維持する場合でも省略できないため、現在のコード・ランタイム設定をそのまま指定します。
aws synthetics update-canary \
--name multiloc-test-canary \
--remove-replica-locations '["us-east-1"]' \
--code 'S3Bucket=cw-synthetics-multiloc-test-123456789012,S3Key=scripts/canary.zip,Handler=index.handler' \
--runtime-version syn-nodejs-puppeteer-16.0 \
--region ap-northeast-1
Replicas が空になり ReplicationState が InSync へ遷移するまで待機します(約20〜30秒)。
aws synthetics get-canary --name multiloc-test-canary --region ap-northeast-1 \
--query 'Canary.MultiLocationConfig'
Step 2: プライマリカナリアを削除する
aws synthetics delete-canary --name multiloc-test-canary --region ap-northeast-1
バージニアのLambda関数も自動削除されていました(ProvisionedResourceCleanupのデフォルト値がAUTOMATICのため、Lambda関数・レイヤーも合わせて削除されます)。
補足: 既存のシングルリージョンカナリアからの移行
対応ランタイムを使用しており、グループに所属していない既存カナリアであれば、カナリアを再作成せずにマルチロケーション化できます。update-canary で --add-replica-locations を指定するだけです。
検証のため single-to-multi-canary をシングルリージョンカナリアとして作成し、その後 update-canary でバージニアをレプリカとして追加しました。
aws synthetics update-canary \
--name single-to-multi-canary \
--add-replica-locations '[{"Location":"us-east-1"}]' \
--code 'S3Bucket=...,S3Key=scripts/canary.zip,Handler=index.handler' \
--runtime-version syn-nodejs-puppeteer-16.0 \
--region ap-northeast-1
約30秒で InSync になり、MultiLocationConfig に LocationType: Primary と Replicas が追加されていることを確認できました。カナリアのID・スクリプト・設定はそのまま引き継がれ、再作成は不要です。
まとめ
create-canary に --add-replica-locations を指定することで、マルチロケーションカナリアを作成できました。対応条件を満たす既存カナリアであれば、update-canary によるレプリカ追加で再作成せずにマルチロケーション化できます。
複数リージョンから同一エンドポイントを測定すると、リージョンごとの成功状況や応答時間の違いを比較できます。さらにHARレポートを確認することで、特定リージョンから遅く見えるリソースを特定する手がかりになります。
実行結果・メトリクス・HARレポートをプライマリで確認できるため、リージョンごとに個別カナリアを管理する場合に比べて、確認作業を集約しやすい点が便利でした。一方で、レプリカ数に比例して実行回数とコストは増加します。監視地点を増やす場合は、URLバッチングや監視頻度の調整も併せて検討するとよさそうです。







