AWSURL監視をSyntheticsで設計する方法｜CanaryスクリプトとアラートSNS連携の実践

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWSURL監視をSyntheticsで設計する方法｜CanaryスクリプトとアラートSNS連携の実践
「サービスへのアクセスが止まっている。でも、EC2インスタンスは動いているし、ログにもエラーが出ていない。」
こういった状況で、原因の特定に時間がかかることがあります。
サーバーが起動していることと、エンドポイントが正常なレスポンスを返していることは別の話だからです。

この記事では、AWS CloudWatch Syntheticsを使ったURL監視の設計手順を解説します。
この記事では、東京リージョン（ap-northeast-1）を想定環境として説明します。
Canaryスクリプトの基本設定から、CloudWatch AlarmsとSNSを連携させたアラート通知の設計まで、実践的な構成パターンを紹介します。

この記事のポイント

・CloudWatch SyntheticsはURLへのHTTPリクエストで動作確認するAWSのマネージドサービスです。
・ハートビート監視タイプのCanaryは数分の操作で作成できます。
・CloudWatch AlarmsとSNSを組み合わせると、障害時に自動でメール通知を受け取れます。
・外形監視とインフラ監視を組み合わせることで、障害の見落としを防ぐ設計になります。


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

なぜURL監視がAWSシステム設計に必要なのか

AWSのEC2やECSでサービスを動かしていると、インスタンスの死活監視はCloudWatch Metricsで取得できます。
ただし、CPUやメモリの数値が正常でも、アプリケーション層でエラーが発生してサービスが応答しないケースがあります。

典型的なケースとして、デプロイ直後にアプリケーションの起動が失敗していたり、
ALBとターゲットグループの間でヘルスチェックの設定が合っていなかったりする場合があります。

そこで、実際のURLに対してHTTPリクエストを送信し、ステータスコードとレスポンスタイムを継続的に記録する
「外形監視」が必要になります。

AWS CloudWatch Syntheticsはその外形監視を担うマネージドサービスです。
Canaryスクリプトを設定することで、定期的にURLへアクセスし、監視結果をCloudWatchに記録します。

CloudWatch Syntheticsの仕組みと位置づけ

CloudWatch Syntheticsは、あらかじめ設定したスクリプト（Canary）を定期実行し、
URLやAPIの動作状態を継続的に記録するサービスです。

Canaryは以下の種類から選択できます。

・Heartbeat Monitor：URLにGETリクエストを送信し、ステータスコードを記録します。
・API Canary：APIエンドポイントへのリクエストと、レスポンスの内容を検証します。
・Broken Link Checker：Webページ内のリンク切れを検出します。
・Visual Monitoring：スクリーンショットと過去の状態を比較します。

本記事では、最も基本的なHeartbeat Monitorを使ったURL監視の設定手順を中心に解説します。

Syntheticsの実行にはNode.jsまたはPythonのランタイムを選択します。
スクリプトの実行はAWS側のマネージド環境で行われるため、Canaryを動かすためのEC2インスタンスを用意する必要はありません。

CanaryスクリプトでURL監視を設定する手順

1. IAMロールを準備する

Canaryの実行には、IAMロールが必要です。
マネジメントコンソールからCanaryを作成する場合、IAMロールは自動作成を選択できます。

ただし、本番環境では最小権限の原則に従い、あらかじめIAMロールを手動で作成しておくことをお勧めします。
Canaryの実行に必要な最低限のポリシーは以下のとおりです。

・CloudWatchへのメトリクス書き込み（cloudwatch:PutMetricData）
・S3へのCanary実行結果の保存（s3:PutObject、s3:GetObject）
・VPC設定を使う場合はEC2 VPCインターフェイスの作成権限

AWS CLIでロールを確認する場合は、以下のコマンドを実行できます。


# Canary用IAMロールの確認（ロール名は環境に合わせて変更）
aws iam get-role --role-name CloudWatchSyntheticsRole --query 'Role.RoleName'

# アタッチされているポリシーの確認
aws iam list-attached-role-policies --role-name CloudWatchSyntheticsRole

2. Canaryを作成する（ハートビート監視）

マネジメントコンソールの「CloudWatch」→「Synthetics Canaries」→「Create canary」から作成します。

主な設定項目は以下のとおりです。

・Blueprint：「Heartbeat monitoring」を選択します。
・Application or endpoint URL：監視対象のURLを入力します（例：https://example.com/health）。
・Schedule：実行間隔を設定します。5分ごとの監視が一般的です。
・Data retention：スクリーンショットとログの保持期間を指定します。

AWS CLIで作成する場合は、以下のコマンドを使います。


# Canaryの作成（ハートビート監視）
aws synthetics create-canary \
  --name "url-health-check" \
  --code "Handler=heartbeat.handler" \
  --artifact-s3-location "s3://your-bucket-name/canary-artifacts/" \
  --execution-role-arn "arn:aws:iam::123456789012:role/CloudWatchSyntheticsRole" \
  --schedule "Expression=rate(5 minutes)" \
  --runtime-version "syn-nodejs-puppeteer-9.0" \
  --run-config "TimeoutInSeconds=60" \
  --region ap-northeast-1

# 出力例（環境により異なります）
# {
#     "Canary": {
#         "Id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
#         "Name": "url-health-check",
#         "Status": {
#             "State": "CREATING"
#         }
#     }
# }
Canaryの作成後、ステータスが「RUNNING」に変わるまで数分かかります。

3. 実行結果とステータスを確認する

Canaryが実行されると、CloudWatch SyntheticsのコンソールでSuccessとFailureの件数を確認できます。

AWS CLIでステータスを確認する場合は、以下のコマンドを使います。


# Canaryのステータス確認
aws synthetics get-canary --name "url-health-check" \
  --query 'Canary.Status.State'

# 最近の実行結果を確認
aws synthetics get-canary-runs --name "url-health-check" \
  --query 'CanaryRuns[*].{Status:Status.State,Timestamp:Timeline.Started}'

# 出力例（環境により異なります）
# [
#     {
#         "Status": "PASSED",
#         "Timestamp": "2026-11-12T10:00:00+00:00"
#     },
#     {
#         "Status": "PASSED",
#         "Timestamp": "2026-11-12T09:55:00+00:00"
#     }
# ]
CanaryのステータスがFAILEDになった場合、実行ログとスクリーンショットはS3バケットに保存されます。
S3のパスを確認し、エラーの内容を調べることで原因を特定できます。

CloudWatch AlarmsとSNSでアラート通知を設計する

CanaryのFAILEDが検知されても、自動で通知が来なければ対応が遅れます。
CloudWatch AlarmsとSNSを連携させることで、障害発生時に自動でメール通知を受け取る設計にできます。

1. SNSトピックを作成する


# SNSトピックの作成
aws sns create-topic --name "synthetics-alert" --region ap-northeast-1

# メールアドレスへのサブスクライブ
aws sns subscribe \
  --topic-arn "arn:aws:sns:ap-northeast-1:123456789012:synthetics-alert" \
  --protocol email \
  --notification-endpoint "admin@example.com" \
  --region ap-northeast-1

# 出力例（環境により異なります）
# {
#     "SubscriptionArn": "pending confirmation"
# }
サブスクライブ後、登録したメールアドレスに確認メールが届きます。
メール内のリンクをクリックして承認を完了してください。

2. CloudWatch Alarmを作成する

Canaryの失敗を検知するアラームを作成します。
SyntheticsのメトリクスはCloudWatchの「CloudWatchSynthetics」名前空間に記録されます。


# CloudWatch Alarmの作成（Canaryのエラー件数でトリガー）
aws cloudwatch put-metric-alarm \
  --alarm-name "synthetics-url-health-check-failed" \
  --alarm-description "URL health check canary failed" \
  --metric-name "Failed" \
  --namespace "CloudWatchSynthetics" \
  --dimensions "Name=CanaryName,Value=url-health-check" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:synthetics-alert" \
  --region ap-northeast-1
上記の設定は、5分間（period=300秒）のFailedカウントが1以上になるとアラームに遷移します。
評価期間（evaluation-periods）を2や3に増やすと、一時的なエラーでの誤検知を減らせます。

3. アラームのステータスを確認する


# アラームのステータス確認
aws cloudwatch describe-alarms \
  --alarm-names "synthetics-url-health-check-failed" \
  --query 'MetricAlarms[*].{Name:AlarmName,State:StateValue}' \
  --region ap-northeast-1

# 出力例（環境により異なります）
# [
#     {
#         "Name": "synthetics-url-health-check-failed",
#         "State": "OK"
#     }
# ]
アラームのStateがOKであれば、Canaryが正常に稼働していて監視が機能している状態です。
INSUFFICIENTDATAの場合は、Canaryの実行が開始されていないか、メトリクスが収集されていない可能性があります。

本番運用で気をつける設計のポイント

CloudWatch Syntheticsを本番に組み込む際に、あらかじめ確認しておきたい点をまとめます。

監視間隔とコストのバランス
Canaryの実行回数に応じて課金されます。
5分ごとに実行すると月に約8,640回の実行になります。
料金はリージョンとランタイムによって異なるため、AWSの最新の料金ページで確認してください。

監視対象URLの選定
単純に「トップページが返る」だけでなく、ユーザーが実際に使う重要な画面やAPIエンドポイントを監視対象にすることで、実際の障害をより早く検知できます。

VPC内のエンドポイントを監視する場合
プライベートサブネット内のエンドポイントを監視する場合は、CanaryをVPCに関連付ける設定が必要です。
パブリックエンドポイントとは設定が異なるため、ネットワーク設計を先に確認してください。

アラートの誤検知対策
evaluation-periodsを1にすると、一時的なネットワークの揺れで誤検知が発生することがあります。
本番では2～3に設定して、継続的な障害のみを通知するように調整することをお勧めします。

AWSのEC2やAmazon Linux環境の基本的な構築手順については、AWSのAmazon Linux環境構築スタートアップガイドで解説しています。
Syntheticsと組み合わせる本番環境を整備する際の参考にしてみてください。

まとめ

CloudWatch Syntheticsを使ったURL監視の設定手順をまとめます。
やること コマンド・操作
IAMロールの確認 aws iam get-role --role-name [ロール名]
Canaryの作成 aws synthetics create-canary --name [名前]
実行結果の確認 aws synthetics get-canary-runs --name [名前]
SNSトピックの作成 aws sns create-topic --name [トピック名]
CloudWatch Alarmの設定 aws cloudwatch put-metric-alarm
アラームのステータス確認 aws cloudwatch describe-alarms --alarm-names [名前]
CloudWatch SyntheticsのCanaryは、設定すること自体は数分で完了します。
大切なのは「何を監視するか」という設計の判断です。
重要なエンドポイントを特定し、アラートの通知先と対応手順をセットで準備しておくことで、障害時の対応が変わってきます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
＞＞AWSのAmazon Linux環境構築スタートアップガイド

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。