CloudWatch Syntheticsとは？Canaryの作り方・ランタイム選定・料金をAWS外形監視の実装目線で解説

CloudWatch Syntheticsは、AWSアカウント内のLambda上で「Canary」と呼ばれる監視スクリプトを定期実行し、公開中のWebページやAPIを外側から叩き続けるサービスです。外形監視そのものの定義や内部監視・死活監視との違いは外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説にまとめてあるため、この記事はAWSで実際に組む側の判断材料――どのランタイムを選ぶか、実行間隔と本数でいくら掛かるか、どこで設定を間違えると外形監視として機能しなくなるか――に絞ります。記載したバージョンと料金は2026年7月28日時点のAWS公式ドキュメントの値です。

まとめ：CloudWatch Syntheticsの選定と料金の結論

結論から書きます。監視対象がAWS上にあり、アラーム・ログ・メトリクスをCloudWatchに寄せたいなら、外形監視の実装先としてCloudWatch Syntheticsは第一候補です。ランタイムの既定解はsyn-nodejs-puppeteer-16.1。API監視・リンク切れ検出・ビジュアルモニタリング・Canary Recorderの各ブループリントとX-Rayアクティブトレースが、いずれもPlaywrightランタイムに対応していないためです。自作スクリプトでブラウザシナリオだけを回すと決めているならsyn-nodejs-playwright-7.1で構いません。

費用はCanary1本あたり1実行0.0012USDの従量課金。5分間隔で回すと月10.37USD、1分間隔なら月51.84USDです（いずれも30日換算、実行料金のみ）。実行回数に対する課金なので、URLが増えたときCanaryを本数分作るか、HTTP・DNS・SSL・TCPを最大10チェックまで1本に束ねるMulti checksブループリントを使うかで実行料金が桁で変わります。

設定で最も事故が多いのはVPC接続です。CanaryをVPC内に閉じるとユーザーが実際に通るDNSやCDN、WAFを経由しなくなり、外形監視の目的そのものを満たさなくなります。

Canaryの実体：アカウント内に作られるLambdaとS3バケット

CloudWatch Syntheticsが動かすCanaryは、独立した監視エージェントではなくLambda関数です。Canaryを作ると、Synthetics側が用意したランタイムコードを含むLambdaレイヤー（名前がSyntheticsで始まるもの）が関数に付与され、指定したスケジュールで関数が起動してブラウザまたはHTTPクライアントを走らせます。後述のIAM権限とVPC設定が必要になる理由も、この構造から来ています。

Canary作成時にアカウント内へ発生するリソース

自動生成されるリソースは、作成時にどの選択をしたかで変わります。コスト按分やタグ付けの対象を洗い出すときは、次の命名を手掛かりに検索してください。

S3バケットにはスクリーンショット、HARファイル、実行レポートが蓄積されます。Canaryを削除してもこのバケットとオブジェクトは残るため、監視対象を入れ替えるたびに作り直す運用ではストレージ料金が静かに積み上がるでしょう。ライフサイクルルールを最初に入れておくのが安全です。

実行結果をアラームと通知につなぐ経路

Canaryは実行ごとにCloudWatchSynthetics名前空間へメトリクスを発行します。基本はSuccessPercent（成功率）とDurationの2つ。加えて2xx／4xx／5xx／RequestFailedがあり、これらはsyn-nodejs-2.0でUI Canary向けに追加されたのち、syn-nodejs-puppeteer-2.2以降はAPI Canaryでも発行されます。Canary作成画面でアラームの自動作成を選ぶとSynthetics-Alarm-{canaryName}-{index}という名前で作られ、これをSNSトピックに紐付けてメールやチャットへ流す形です。

1回失敗しただけで呼び出しが飛ぶ設定は、ネットワークの一時的な揺らぎで夜間に人を起こします。評価期間を複数回に設定し、連続失敗で初めて発報させるのが実務的な落としどころでしょう。何を成功と見なすかの基準そのものを整理したい場合はサービスレベル指標(SLI)とサービスレベル目標(SLO)とは何か？信頼性を測る基本概念と役割を解説が参考になります。

ランタイムは4系統：Playwright・Puppeteer・Selenium・Javaの選び分け

Canaryはランタイムバージョンを1つ指定して動きます。ランタイムはSyntheticsのライブラリコードと依存関係のLambdaレイヤーをまとめたもので、命名はsyn-{言語}-{フレームワーク}-{メジャー}.{マイナー}です。同じメジャー番号どうしが後方互換であることは、Puppeteerランタイムのドキュメントにのみ明記されています。他系統のページに同じ記述はないため、メジャー番号だけを根拠に互換性を前提にしないでください。

最新ランタイムと同梱されるフレームワーク・ブラウザのバージョン

Javaランタイムはブラウザもフレームワークも含みません。画面の描画を確認せずHTTPエンドポイントの応答だけを見るAPI監視向けで、X-Rayトレースの発行には対応します。ブラウザ操作を伴うシナリオ監視は、Node.js系かPython系のいずれかになります。

ブループリントとX-Rayトレースで決まる系統の選択

最新版という理由だけでPlaywrightランタイムを選ぶと、直後の作成手順で行き詰まります。用意されたブループリントのうち4種類がPlaywrightに対応していないためです。API canary、Broken link checker（リンク切れ検出）、Visual monitoring（ビジュアルモニタリング）、Canary recorderは、いずれも公式ドキュメントにPlaywrightランタイム非対応と明記されています。ビジュアルモニタリングはPython+Seleniumでも使えません。

もうひとつの分岐がAWS X-Rayのアクティブトレースです。対応するのはsyn-nodejs-2.0以降のPuppeteerランタイムとJavaランタイムだけで、Playwrightランタイムでは選べません。さらに、Puppeteer系を選んでもブラウザにFirefoxを指定したCanaryではトレースが出ない点に注意が必要です。トレースを併用するならChromiumで実行します。有効化すると実行時間が2.5〜7%伸び、X-Ray側で別途課金が発生し、アジアパシフィック（ジャカルタ）はまだ対応していません。実行ロールにはxray:PutTraceSegmentsが要ります。

残る2系統の使いどころは限られます。既存のSeleniumスクリプト資産を持ち込むならPython系、ブラウザを起動しないAPI監視をJavaで書きたいならJava系です。

型定義パッケージのバージョンと名前空間の移行

スクリプトの型定義を使う場合、npmの型定義パッケージのバージョンはCanaryのランタイムに合わせる必要があります。2026年7月28日時点のnpmレジストリでの最新は次のとおりで、ランタイム側の7.1／16.1にはまだ追い付いていません。

npm i -D @aws/[email protected]
npm i -D @aws/[email protected]

あわせて名前空間の移行にも注意してください。syn-nodejs-playwright-5.1以降で@amzn/synthetics-playwrightから@aws/synthetics-playwrightへ、syn-nodejs-puppeteer-13.1以降でSyntheticsから@aws/synthetics-puppeteerへ変わりました。旧名前空間は将来のリリースで廃止予定とされているため、古いランタイムから上げる際はimport文の書き換えが必須です。

非推奨ランタイムの扱いと2026年に到来した移行期限

ランタイムは構成部品のサポートが切れた時点で非推奨になります。2026年に入ってからの非推奨は2回。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・5.0・4.1・4.0が非推奨日を迎えました。なおSeleniumの個別ページ側は4.0〜5.1を「まだサポート対象」の節に残したままで、非推奨日一覧表と記述が食い違っています。一覧表のほうが個別ページからリンクされている参照先なので、そちらを正として扱うのが妥当でしょう。

ここは誤解されやすい点なので明確に書きます。非推奨になっても既存Canaryは止まりません。停止するのは「そのランタイムで新しくCanaryを作ること」だけで、動いているCanaryはそのまま実行を続け、停止・開始・削除も従来どおり操作できます。サポート対象のランタイムへ更新することも可能です。AWSは非推奨予定の60日前に、該当ランタイムのCanaryを持つアカウントへメールで通知します。

公式が規定しているのは「ランタイムは構成部品がサポートされなくなった時点で非推奨にする」という点まで。裏返せば、非推奨ランタイムには新しい脆弱性対応が入らない前提で扱うべきだ、という判断になります。2023年以前に作ったまま触っていないCanaryがある環境では、Chromium 92や111といった相当古いブラウザで自社サイトを叩き続けている状態になり得ます。

移行時に見落としやすいのがPythonのマイナーバージョン境界です。Selenium系は5.1以下がPython 3.9、6.0〜10.0がPython 3.11、11.0以降がPython 3.12。非推奨になった5.1から最新へ上げると必ずPythonのマイナー版が2段変わるため、依存ライブラリの互換確認が伴います。まずはランタイムバージョンの一覧を取り、上の表の最新版へ寄せる作業から着手してください。

Canaryの作成手順と設定できる値

作成はCloudWatchコンソールのApplication Signals＞Synthetics Canariesから行います。現行ドキュメントの導線はこの位置なので、古い記事の画面キャプチャとはメニューの場所が異なる点に留意してください。CloudFormationで作る場合はAWS::Synthetics::Canaryリソースを使いますが、こちらは自作スクリプトを持ち込む前提です。

設計図テンプレートとスクリプト持ち込みの使い分け

作成方法は、用意された設計図（ブループリント）を選ぶか、自作のNode.jsスクリプトをアップロードするか、S3から取り込むかの3通り。S3から取り込む場合はs3:GetObjectとs3:GetObjectVersionの権限が必要で、バケットはCanaryを作成するリージョンと同じでなければなりません。

ブループリントは7種類あります。URLの死活を見るHeartbeat監視（syn-nodejs-puppeteer-3.1以降は複数URLを1本で監視可能）、複数エンドポイントをHTTPステップとして叩くAPI canary、リンク切れ検出のBroken link checker、基準画像と比較するVisual monitoring、Chrome拡張の記録を使うCanary recorder、そしてスクリプトを書かずに操作を組めるGUI workflow builderとMulti checksです。前述のとおり、このうちAPI canary・Broken link checker・Visual monitoring・Canary recorderはPlaywrightランタイムでは選べません。

スクリプトを自分で書く判断は、GUI workflow builderで組めない要件が出てから下せば足ります。GUI workflow builderはClick、Verify selector、Verify text、Input text、Click with navigationの5アクションを組み合わせられるため、ログインフォームにユーザー名とパスワードを入力して送信し、遷移後の画面に特定の文字列が出ることまではコードなしで確認できます。分岐処理や外部API連携が要る段階になって初めて、スクリプトの持ち込みを検討してください。

Canary Recorderで記録したスクリプトを本番へそのまま載せない理由

Chrome拡張のCloudWatch Synthetics Recorderは、ブラウザ上のクリックと入力を記録してNode.jsスクリプトを生成します。ベースはオープンソースのheadless-recorderで、生成物はコピーしてブループリントのインラインエディタに貼るか、S3経由で取り込む形。長い操作手順の下書きを作る道具としては速いです。

ただし本番Canaryへそのまま載せる使い方は勧めません。生成されたスクリプトには2つの構造的な弱点があるためです。ひとつはセレクタで、id属性を持たない要素はCSSセレクタとして記録されるため、画面側のマークアップが変わると監視が壊れます。監視対象の障害ではなく監視スクリプトの都合で失敗が出れば、アラートは早晩無視されるようになるでしょう。

もうひとつはアサーションです。Recorderは要素やテキストの存在確認を生成しません。操作を伴わない検証は記録対象外のため、記録したままのスクリプトは「操作が例外なく最後まで流れた」ことしか判定しません。エラーメッセージが表示されていても、決済ボタンが押せて画面遷移さえすれば成功として記録されます。生成後に検証コードを手で足すこと、ダブルクリックやコピー&ペースト、キー組み合わせ（CMD+0など）、ポップアップ内の操作は記録されないことを前提に使ってください。

実行間隔・タイムアウト・メモリ・データ保持で指定できる範囲

スケジュールは1回限りの実行、rate式による継続実行、cron式の3通り。コンソールからrate式で作る場合、選べる間隔は1分に1回から1時間に1回までです。より複雑な時間帯指定が要るならcron式を使います。

メモリを1GBのまま動かす必要はありません。ブラウザを起動するUI Canaryでスクリーンショットの取得に失敗する、あるいは実行が不安定になる場合、MemoryInMBを引き上げるのが最初の対処になります。タイムアウトを自分で設定するときは、Lambdaのコールドスタートとcanary計装の起動時間を見込んで15秒より短くしないことが公式に明示されています。

実行結果の保持期間は成功・失敗それぞれ1〜455日で指定できますが、保持期間を長くしてもコンソールで遡れる範囲は別に制限されます。Syntheticsコンソールのホーム画面は相対・絶対いずれも7日まで、個別Canaryの画面は相対7日・絶対30日までしか表示できません。それ以前の実行結果を追う必要がある運用では、S3のアーティファクトとCloudWatch Logs側を参照する前提で設計してください。

実行間隔とCanary本数で決まる料金

CloudWatch SyntheticsはCanaryの実行回数に対する従量課金で、1回の実行ごとに0.0012USDです。無料利用枠として月100回のCanary実行が付きます。30日換算でCanary1本あたりの実行料金を出すと次のようになります。

上の金額はCanaryの実行料金のみで、無料枠100回は差し引いていません。AWSの料金ページに載っている例は31日基準の44,640回で53.57USDなので、本表と数USDずれます。実際の請求にはLambdaの実行時間、CloudWatch Logsの取り込みと保存、S3のストレージが別建てで乗ります。ブラウザを起動するUI Canaryは1回の実行が数十秒に及ぶことがあり、スクリーンショットも毎回S3へ積まれるため、API監視だけのCanaryより付随コストが大きく出るでしょう。単価は米国東部リージョンの例なので、リージョンごとの最新の単価はAWS公式の料金タブで確認してください。

削減の手段は2つあります。ひとつは実行間隔の仕分け。監視対象が20URLあるとして全部を1分間隔にすると実行料金だけで月1,036.80USDですが、売上に直結する導線の3本だけを1分間隔にし、残り17本を15分間隔に落とせば月214.27USDまで下がります。検知が1分遅れて困るページと、15分後に気付けば足りるページを分ける作業が、そのまま費用の設計になります。

もうひとつがCanaryの本数そのものを減らす手段です。課金は実行回数に対してかかるので、10URLを10本のCanaryで回すか1本に束ねるかで実行料金は10倍違います。Multi checksブループリントはHTTP・DNS・SSL・TCPのチェックを最大10個まで1本のCanaryにまとめられる仕組みで、公式も「コストを削減する」と明記。各チェックにアサーションを設定でき、認証はBasic・API Key・OAuth・Sigv4に対応しSecrets Managerと連携します。ただしCanaryとしての成否は1本にまとまるため、対象ごとに別々のアラームを張って通知先を分けたい監視は、束ねずにCanaryを分けてください。

マルチロケーションCanaryで複数リージョンから同じシナリオを流す

同一のCanaryを複数のAWSリージョンから同時に実行できる機能がマルチロケーションCanaryです。プライマリリージョンでCanaryを作成・管理すると、選んだレプリカリージョンへSyntheticsが自動で複製し、実行結果・メトリクス・アーティファクトはプライマリ側に集約されます。作成、更新、開始、停止、削除といった変更操作はすべてプライマリから行い、非同期でレプリカへ伝播する仕組みです。

利用要件は明確です。ランタイムがsyn-nodejs-puppeteer-16.0以降またはsyn-nodejs-playwright-7.0以降であること、レプリカは最大50拠点まで、対応はAWSの商用リージョン全域でGovCloud(US)と中国リージョンは対象外。単一リージョンからしか監視していない構成では、経路上の障害なのか特定地域からの到達性の問題なのかを切り分けられません。海外からのアクセスがある事業では、この機能が入るまでリージョンごとにCanaryを自前で複製する必要がありました。

運用前に把握しておくべき制約を挙げます。タグはレプリカへ複製されないため、コスト配分タグを効かせるにはレプリカ側のリージョンで個別に付与します。VPC設定もプライマリから継承されないので、レプリカごとにVPC・サブネット・セキュリティグループを指定してください。一方で環境変数はプライマリからすべてのレプリカへ適用され、スクリプトとスケジュールは全ロケーション共通に固定されます。そしてコストはレプリカ数に比例し、レプリカ1つがスタンドアロンのCanary1本と同額です。前節の表で言えば、5分間隔のCanaryを3拠点に展開すると月10.37USDではなく31.11USDになります。

IAMロールの使い回しとVPCサブネット指定で失敗する条件

Canary実行ロールの権限と既存ロールを流用する条件

コンソールでCanaryを作るとき、実行用のIAMロールは自動生成させるか既存のものを指定するかを選べます。自動生成なら必要な権限は揃った状態で作られますが、このとき作られるロールは作成したCanary専用で、他のCanaryには再利用できません。Canaryを数十本運用する環境でこれを繰り返すと、IAMロールとポリシーが本数分だけ増えていきます。

複数Canaryで共用するロールを手で作り、作成時にそれを指定する運用へ切り替えると管理対象が減ります。既存ロールの指定に要る権限は、SyntheticsとLambdaにロールを渡すためのiam:PassRoleとiam:GetRoleの2つ。なおS3の権限が一切ないCanaryでも、ランタイム側の対応により実行そのものは成功します。ただしスクリーンショットやHARファイルはアップロードされません。権限不足が「Canaryが落ちる」形では現れず、証跡だけが静かに欠ける点に注意してください。

VPC接続したCanaryが外形監視として成立しない構成

VPC内のエンドポイントを監視する場合は、Canary作成時にVPC・サブネット・セキュリティグループを指定します。前提として、VPC側でDNS ResolutionとDNS hostnamesの両方を有効にしておく必要があります。サブネットはプライベートサブネットを選ばなければなりません。Lambdaは実行時にIPアドレスを割り当てられないため、パブリックサブネットでは構成できないという制約です。

もうひとつ必須なのが、メトリクスをCloudWatchへ、アーティファクトをS3へ送り出す経路の確保です。VPCが既にインターネットアクセスを持つなら追加作業は要りません。閉じたVPCの場合、パブリックサブネットにNATゲートウェイを置いてプライベートサブネットのルートテーブルに0.0.0.0/0を足すか、VPCを閉じたままCloudWatch用のインターフェースエンドポイントcom.amazonaws.{region}.monitoringとS3のゲートウェイエンドポイントを張るかの二択です。後者はNATゲートウェイの月額固定費とデータ処理料が掛からないぶん、監視用途では有利になります。IPv6のみ、あるいはデュアルスタックのエンドポイントを監視するなら、デュアルスタックサブネットとEgress-Only インターネットゲートウェイを用意し、Ipv6AllowedForDualstackを設定します。

ここで判断を明確にしておきます。VPC内に閉じたCanaryは、外形監視とは呼べません。外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説で整理したとおり、外形監視が価値を持つのは、実ユーザーと同じ経路――名前解決、CDN、WAF、ロードバランサ、TLS終端――を通って初めて分かる障害を捕まえられるからです。VPC内部からプライベートIPへ直接HTTPリクエストを投げるCanaryは、その手前の経路を丸ごと飛ばします。DNSの設定ミスでサイトに到達できない状況でも、このCanaryは緑のまま成功を返し続けるでしょう。

VPC接続は「内部向けAPIやイントラネットのアプリケーションが、社内から到達可能か」を確かめる用途に使うものだと割り切ってください。公開サイトの外形監視が目的なら、CanaryはVPCに入れずインターネット経由で公開URLを叩かせます。

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

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

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

ふたつ目は、障害の原因を特定したい場合です。Canaryは「ユーザーから見て壊れている」ことを外側から検知しますが、なぜ壊れているかは答えません。応答が遅い原因がスレッド枯渇なのか外部API待ちなのかを切り分けるには、内部の実行時情報が要ります。この用途を担うのはAPM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説やメトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説で扱う手法。外形監視と合わせて何をどこまで見えるようにするかという設計思想はオブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説が全体像になります。

みっつ目は、AWS以外の環境が監視対象の中心にある場合です。CloudWatch Syntheticsの利点はアラーム、ログ、メトリクス、X-RayがすべてAWS内で完結する点にあり、監視対象がオンプレミスや他社クラウド中心ならその利点が効きません。監視拠点の数や通知の柔軟さでは外形監視の専業サービスが上回ります。監視対象がAWSにあるかどうかが、この判断の分岐点です。

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

CloudWatch Syntheticsとは何ですか？

AWSアカウント内のLambda上でCanaryと呼ばれる監視スクリプトを定期実行し、公開中のWebページやAPIを外部から叩いて可用性と応答を確認するCloudWatchの機能です。スクリプトはNode.js（PlaywrightまたはPuppeteer）、Python（Selenium）、Javaで記述でき、結果はCloudWatchメトリクスとアラーム、S3のスクリーンショットやHARファイルとして残ります。

Syntheticsの読み方は何ですか？

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

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

Canaryの実行1回につき0.0012USD、月100回までが無料利用枠です。30日換算で5分間隔のCanary1本が月10.37USD、1分間隔で月51.84USDになり、別途Lambda・CloudWatch Logs・S3が請求されます。単価は米国東部リージョンの例のため、東京リージョンでの見積もりは料金タブで単価を確認してください。

Canaryの実行間隔は最短でどのくらいですか？

コンソールからrate式で作る場合、1分に1回から1時間に1回の範囲です。より細かい時間帯制御が要るならcron式を使います。タイムアウトは3〜840秒で指定でき実行間隔を超えられませんが、Lambdaのコールドスタートを見込んで15秒より短くしないよう推奨されています。

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

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

PuppeteerとPlaywrightはどちらのランタイムを選ぶべきですか？

ブループリントを使うならsyn-nodejs-puppeteer-16.1です。API canary、Broken link checker、Visual monitoring、Canary recorderの4種はPlaywrightランタイムに対応していません。X-Rayのアクティブトレースを出す場合も同じくPuppeteer系かJava系になります。Playwright系を選ぶのは、自作スクリプトでブラウザシナリオだけを回すと決めたときです。

関連記事

• 外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説
• メトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説
• APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説
• サービスレベル指標(SLI)とサービスレベル目標(SLO)とは何か？信頼性を測る基本概念と役割を解説
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説