Amazon CloudWatch Synthetics (Canaries)

解決する課題

実ユーザーのトラフィックを待つ監視（リアルユーザーモニタリング）では、深夜やアクセスの少ない時間帯に発生した障害に気づくのが遅れます。また「個別のサービスは正常なのに、ユーザー視点の操作フローが壊れている」ケースは、サーバー側のメトリクスだけでは捕捉できません。CloudWatch Synthetics は：

• ユーザーがいなくても、エンドポイントや画面遷移を能動的（外形的）に定期実行して死活・性能を確認する
• ログイン、検索、カート投入といった複数ステップの業務フローをブラウザ操作として再現する
• 壊れたリンクや表示崩れ、証明書の期限切れなどを利用者より先に検知する

主要概念と用語

• Canary（カナリア）: 監視対象に対して定期的にリクエストや操作を実行するスクリプト。鉱山のカナリアが由来で、本番ユーザーが踏む前に異常を知らせる
• ブループリント: よくある監視パターンの雛形。単一 URL のハートビート、API 監視、リンク切れチェック、画面遷移（GUI ワークフロー）などが用意されている
• ハンドラ: Canary スクリプトのエントリポイント。実行されるとここから処理が始まる
• ステップ: 画面遷移系 Canary で、操作の単位。ステップごとに成功・失敗とスクリーンショットが記録される
• HAR ファイル: 実行中の HTTP リクエスト/レスポンスを記録した解析用ファイル。遅い通信や失敗したリソースの切り分けに使う
• アーティファクト: 実行のたびに生成されるスクリーンショット・HAR・ログ。S3 バケットに保存される
• ランタイム: Canary を動かす実行環境のバージョン。Node.js + Puppeteer 系と Python + Selenium 系があり、定期的に更新される
• スケジュール: Canary を実行する頻度。一定間隔（レート）または cron 式で指定する

仕様・制限・クォータ

• Canary は内部的に Lambda 関数として実行される。1回あたりの実行時間にはタイムアウト上限があり、長時間の処理は分割が必要
• 実行頻度には最短間隔があり、それより細かい間隔では実行できない
• 1アカウント・1リージョンあたりに作成できる Canary 数にはクォータがある（必要なら緩和申請する）
• アーティファクト（スクリーンショット・HAR・ログ）は S3 に保存され、保管量に応じてストレージ料金が発生する
• ランタイムにはサポート期間があり、古いランタイムは廃止される。定期的なアップグレードが前提
• リージョン単位のサービス。複数リージョンから監視したい場合は各リージョンで Canary を作成する

内部の仕組み

横にスクロール

Canary を作成すると、AWS は裏側で Lambda 関数と、実行を起動する EventBridge（スケジュールイベント）、結果を保存する S3 バケット、メトリクスを送る CloudWatch との連携をまとめて構成します。スケジュールが来るたびに Lambda が起動し、スクリプト内のハンドラを実行します。

ブラウザ操作系の Canary では、ヘッドレスブラウザ（Puppeteer または Selenium 経由）が実際にページを開き、要素のクリックや入力を行います。実行中の各ステップでスクリーンショットと HTTP トラフィック（HAR）を取得し、終了時に S3 へアップロードします。同時に、成功率・実行時間などを CloudWatch のメトリクスとして発行するため、しきい値を使ったアラームを設定できます。

• 成功・失敗の判定はスクリプトの戻りや例外に基づき、メトリクス化される
• VPC 内のプライベートなエンドポイントを監視したい場合は、Canary を VPC に接続して実行できる

設計パターン / ベストプラクティス

• ハートビートと業務フローを使い分ける: まず単一 URL のハートビートで死活を押さえ、重要導線（ログインから決済まで）は画面遷移 Canary で別に監視する
• 複数リージョンから監視する: 1リージョンだけだと監視元の障害と対象の障害を区別できない。地理的に分けて偽陽性を減らす
• テストデータを汚さない: 注文確定などの破壊的操作は、専用のテストアカウントやサンドボックス環境に向ける
• 失敗の連続回数で判定する: 単発の失敗で即アラートにせず、連続失敗をアラーム条件にして一過性のゆらぎを吸収する
• アーティファクトに保持ポリシーを設定: スクリーンショットや HAR が無制限に溜まらないよう、S3 のライフサイクルで古いものを削除する

運用・監視

• 成功率（SuccessPercent）と実行時間（Duration）のメトリクスにアラームを設定し、SNS で通知する
• 失敗時はまずスクリーンショットで「画面が何を表示していたか」を確認し、次に HAR で失敗したリクエストを特定する
• 連続失敗や遅延の傾向はダッシュボードで時系列に並べ、デプロイ時刻と突き合わせる
• 想定外の失敗が増えたら、対象サイトの変更（要素のセレクタ変更など）でスクリプトが追従できていない可能性を疑う

コスト

• 課金は主に Canary の実行回数に基づく。実行頻度が高いほど、また Canary 数が多いほどコストが増える
• アーティファクト保存先の S3 ストレージと、発行されるメトリクス・アラームにも料金が発生する
• VPC 接続時はそれに伴うネットワーク関連のコストも考慮する
• 一定量までの無料利用枠が用意されている場合がある。詳細・最新の単価は公式の料金ページで確認する
• 過剰な高頻度実行はコストを押し上げるため、重要度に応じて実行間隔を調整するのが基本

セキュリティ

• Canary には実行用の IAM ロールが必要で、S3 への書き込みや CloudWatch への発行など最小権限で付与する
• スクリプトにパスワードやトークンを直書きせず、Secrets Manager や暗号化された環境変数から取得する
• スクリーンショットや HAR には画面上の情報や通信内容が写り込むため、機微なデータを含む画面の監視では取り扱いに注意し、保存先 S3 のアクセスを制限する
• API 操作の監査は CloudTrail で記録する

関連サービス・比較

実ユーザーの体感を計測する CloudWatch RUM とよく対比されます。Synthetics は能動的（合成）監視、RUM は受動的（実トラフィック）監視で、両者は補完関係です。

ハンズオン / CLI例

# 単一 URL のハートビート Canary を作成（5分間隔で実行）
# code.zip にはハンドラを含む Canary スクリプトを格納しておく
aws synthetics create-canary \
  --name heartbeat-top \
  --artifact-s3-location "s3://my-canary-artifacts/heartbeat/" \
  --execution-role-arn "arn:aws:iam::111122223333:role/CloudWatchSyntheticsRole" \
  --runtime-version "syn-nodejs-puppeteer-latest" \
  --schedule "Expression=rate(5 minutes)" \
  --code "Handler=index.handler,S3Bucket=my-canary-code,S3Key=code.zip"

# Canary を起動状態にする
aws synthetics start-canary --name heartbeat-top

# 直近の実行結果（成功/失敗とアーティファクトの場所）を確認
aws synthetics get-canary-runs --name heartbeat-top