CloudWatch Synthetics CanaryによるURL外形監視

はじめに

Webサービスを安定して運用するうえで、外形監視は欠かせない仕組みです。
可用性や応答性能を“ユーザー視点”で定期的にチェックすることで、予期せぬ障害の早期検知や影響範囲の最小化につながります。AWSではCloudWatch Synthetics Canaryを利用することで、Webサイトの稼働確認やAPIの応答チェックなど、さまざまな外形監視を実現できます。
本記事では、CloudWatch Synthetics Canaryを活用したURL外形監視の実践ポイントを解説します。

CloudWatch Synthetics Canaryとは？

CloudWatchのSynthetics Canaryは、JavaScript（Node.js）で記述されたスクリプトを定期的に実行し、ユーザーと同じ視点からWebサービスの状態を自動的に検証するメカニズムです。
Webサイトの稼働確認や応答性能チェックに加え、APIの応答検証やユーザー操作のシミュレーション（ログインやフォーム入力など）チェックまで幅広く対応しています。

Canary実行環境のアーキテクチャ

Synthetics Canaryは、単独のサービスではなく複数のAWSサービスが連携した複合アーキテクチャとして機能します。この内部構造を理解しておくことは、実際の監視設定や運用時のトラブルシューティングにおいて重要です。

Lambda関数の自動デプロイ

表面上はCloudWatchの機能として提供されていますが、Synthetics Canaryの実行基盤はLambda関数です。
Canaryを作成すると、その裏側でLambda関数（cwsyn--*）が自動的にデプロイされます。
この際、監視対象のURLやチェックロジックを含むスクリプトコードも自動的に作成されるため、ユーザーは基本的な設定を行うだけで監視を開始できます。
このLambda関数は、AWS提供のSyntheticsランタイムレイヤー（Node.jsまたはPython）を利用します。このレイヤーには、ブラウザをプログラム上で操作するためのPuppeteerというパッケージや、テスト実行用のSyntheticsライブラリが組み込まれており、環境構築の手間なく監視ロジックに集中できます。

連携リソースと権限管理

Synthetics Canaryの実行結果は、CloudWatch Metrics、CloudWatch Logs、Amazon S3の3つのリソースに保存されます。

また、Synthetics Canary実行に必要な権限についてはIAMロールで制御しており、既存のIAMロール利用や、最小限の権限を持つIAMロールの自動作成でも対応が可能です。これには主に、CloudWatchへの書き込みや、S3バケットへのオブジェクト配置などの権限が含まれます。

設定の流れ

Synthetics Canaryは、用途ごとに用意された設計図を利用することで、AWSコンソールから数ステップで作成できます。 ここでは、基本的なハートビートモニタリング（URL疎通確認）を題材に、設定の流れを解説します。

① 設計図を選択する
各設計図の中からハートビートのモニタリングを選択します。
対象URLのページ読み込み、スクリーンショットの撮影、HTTPステータスの確認を自動で行うスクリプトです。

② Canary名と監視対象の設定
Synthetics Canaryの名称と、監視対象のエンドポイントURLを設定します。

③ ランタイムとスクリプトの調整
Canaryを実行するランタイムバージョン（syn-nodejs-puppeteer-x.xなど）を指定します。これはバックエンドのLambdaランタイムと連動しています。Lambdaのランタイムサポート終了の影響を受けるため、セキュリティやパフォーマンスの観点から、常に最新のランタイムを選択することが推奨されます。

設計図選択により、スクリプトエディタには実行コードが自動生成され、そのまま修正なしで利用できます。
中間リダイレクト（301/302）も自動追従し、最終到達先が2xxなら成功と判定されます。もし中間リダイレクトを異常扱いにしたい、または特定のHTML要素の描画完了まで厳密に待機させたい場合などは、ここでコードを手動調整します。

④ 実行スケジュールの設定
Canary実行の頻度とタイムアウト設定を定義します。
例えば、5分毎の一定間隔で実行し、スクリプトが停止するまでの最大待機時間（タイムアウト）は1分とする、といった設定を行います。

⑤ データ保持の設定
Canaryの実行履歴データを保持する期間を設定します。「成功時」と「失敗時」で個別に期間を設定できるため、コスト最適化の観点から調整が可能です。

⑥ データストレージの設定
Canaryの実行結果（アーティファクト）を保存するS3バケットを指定します。
デフォルト設定の場合は、新規バケット（cw-syn-results-*）が自動生成されます。既存のログ集約用バケットがある場合は、そちらを指定することも可能です。

⑦ エフェメラルストレージの設定
Canaryが一時ファイル置き場として利用する /tmpディレクトリの容量を設定します。
今回のような、単純なハートビートモニタリング（URL疎通確認）であればデフォルト設定のままで問題ありません。
スクリプトをカスタマイズして、数百MB以上の大きなファイルをダウンロードして検証するような特殊な要件がある場合などは調整します。

⑧ アクセス許可の設定
Canaryが利用するIAMロールを設定します。
「新しいロールを作成」を選択すると、Canary実行に必要な権限を定義したポリシーを持つロールが自動生成されます。

⑨ CloudWatch アラームの設定
Canary作成と同時に、監視アラームを設定できます。
以下の設定例では、SuccessPercent（成功率）のメトリクスを監視対象としています。

⑩ VPCの設定
監視対象がプライベートサブネットにある場合や、IPアドレス制限のあるサイトを監視する場合に設定します。VPC、サブネット、セキュリティグループから、Canary（Lambda関数）を配置するネットワーク情報を指定します。

実践ケーススタディ

以下は、基本設定だけではカバーしきれない、実際の案件で直面した課題とその解決策を解説します。

IP制限のあるURL監視

社内システムやステージング環境など、特定のIPアドレスからのアクセスのみを許可しているサイトを監視するケースです。 Canaryはデフォルト設定ではAWS管理のパブリックIPプールを使用するため、実行のたびにIPアドレスが変わり、許可リストへの登録に対応できません。
この課題は、CanaryをVPC配置し、NAT Gatewayを経由させて送信元IPを固定化することで解決できます。以下の前提条件と設定ステップで実装可能です。

① VPCのDNS設定を確認
Canaryが対象URLの名前解決を行うために、配置するVPCの「DNS解決」と「DNSホスト名」が有効になっている必要があります。

② Canary用セキュリティグループの作成
Canary（Lambda関数）に割り当てるセキュリティグループを作成します。Canaryは外部からの通信を受けないため、インバウンドルールは不要です。
・インバウンドルール: なし
・アウトバウンドルール:
　・TCP 443 (HTTPS) : 0.0.0.0/0
　・TCP 80 (HTTP) : 0.0.0.0/0 （※対象がhttpを含む場合）
　・UDP 53 / TCP 53 (DNS) : 0.0.0.0/0 （※サイトの名前解決に必須）

③ NAT Gatewayへのルートを持つサブネットの準備
Canaryを配置するためのプライベートサブネットを用意します。このサブネットのルートテーブルで、インターネット（0.0.0.0/0）へのターゲットがNAT Gatewayに向いていることを確認します。単一のNAT GatewayではAZ障害時に監視が停止するリスクがあるため、本番運用では複数のAZにそれぞれサブネットとNAT Gatewayを配置し、Canaryの設定でも複数サブネットを選択することを推奨します。

④ CanaryのVPC設定
Canary作成画面（編集画面）の「VPC設定」にて、手順③のプライベートサブネットと、手順②のセキュリティグループを選択します。

⑤ サイト側での許可設定
対象サイトのアクセス許可リストに、NAT GatewayのElastic IPを登録します。

Basic認証サイトの監視

開発中のサイトや社内ツールなどでBasic認証がかかっている場合、Canaryから単純にURLへアクセスすると401エラーとなり監視に失敗します。
対応としてスクリプトに認証情報（ID/Password）を記述する必要がありますが、ソースコードへのハードコーディングはセキュリティ上推奨されません。Secrets Managerに認証情報を保存し、Canary実行時に動的に取得する構成がベストプラクティスです。
以下のステップで実装可能です。

① Secrets Managerへの認証情報保存
Secrets Managerに認証情報を保存します。

② IAMロールへの権限追加
Canaryの実行ロールに対し、Secrets Managerから値を取得するための権限を追加します。Canaryで使用するIAMロールに以下ポリシーを追加します。
・Action: secretsmanager:GetSecretValue
・Resource: 手順①で作成したシークレットのARN

③ スクリプトへの認証ロジック組み込み
スクリプトエディタでコードを編集し、認証を通すロジックを追加します。

・
・
const syntheticsLogHelper = require('SyntheticsLogHelper');

// ▼▼▼ 追加ここから ▼▼▼
const AWS = require('aws-sdk');
const secretsManager = new AWS.SecretsManager();
// ▲▲▲ 追加ここまで ▲▲▲

const loadBlueprint = async function () {
・
・
let page = await synthetics.getPage();

// ▼▼▼ 追加ここから ▼▼▼
// ※ 'YOUR_SECRET_NAME' は作成したシークレットの名前に書き換え
    const secretName = 'YOUR_SECRET_NAME'; 

    try {
        const secretData = await secretsManager.getSecretValue({ SecretId: secretName }).promise();
        const { username, password } = JSON.parse(secretData.SecretString);

        await page.authenticate({ username, password });

        log.info('Basic authentication credentials set successfully.');

    } catch (err) {
        log.error(`Failed to retrieve secret or authenticate: ${err}`);
        throw err;
    }
// ▲▲▲ 追加ここまで ▲▲▲

for (const url of urls) {
・
・

これにより、認証情報をコードに露出させることなく、セキュアにBasic認証サイトを監視できます。

サイトパフォーマンスの監視

ユーザー視点でのサイト表示速度（パフォーマンス）を監視したい場合、CloudWatch Metricsに出力されるCanary全体のDurationメトリクスをそのまま利用すると実際のパフォーマンスとは異なる結果となるため注意が必要です。
Canary全体のDurationは、実際のページ読み込み時間に加え、Lambdaコンテナの初期化（コールドスタート）やブラウザの起動処理といったインフラ側のオーバーヘッドが含まれるため、純粋なユーザー体感速度とは乖離があります。
そのため、正確なパフォーマンスを知るためには、全体のDurationではなく、Stepごとの実行時間を監視する必要があります。 Syntheticsのスクリプト処理は自動的にステップ分けされており、CloudWatchにはCanaryNameに加えてStepNameというディメンションを持つメトリクスが発行されています。
アラームを作成する際は、このStepName付きのDurationに対して閾値を設定することで、インフラ側の要因を排除した、ユーザー視点でのサイトパフォーマンスの変化を正確に捉えることができます。
以下のキャプチャは、全体のDuration（約17秒程度） と Step別（ページロード）のDuration（約1.5秒程度） を比較したものです。それぞれのDuration数値に大きな差があることがわかります。

全体Duration

Step指定のDuration

おわりに

本記事では、CloudWatch Synthetics Canaryを用いたURL外形監視について、基礎的な設定からアーキテクチャの内部構造、そして実運用で直面しやすい課題とその対処方法までをご紹介しました。Synthetics Canaryは、単なるPing監視（死活監視）とは異なり、「ユーザーと同じブラウザ視点」でシステムの健全性を継続的に確認できるサービスです。
外形監視は、ユーザーの信頼を支える仕組みのひとつですので、その仕組みを理解し、見るべき指標を押さえておくことで、より安心感のあるシステム運用につなげられます。
本記事の内容が、みなさまの環境や要件に合った外形監視基盤を検討・構築する際のヒントになれば幸いです。