こんにちは。行きつけのサウナが値上がりして、サウナへの愛着が試されている小菅です。
今回は Amazon CloudWatch Synthetics Canary を実際に動かして、何ができるのかを見ていきます。
「名前は聞いたことがあるけどよく知らない」という方に向けて、コンソールでの作成から実行結果の確認まで、実際の画面を交えてご紹介します。
Amazon CloudWatch Synthetics Canary とは
Amazon CloudWatch Synthetics Canary は、エンドポイントや API を外側から定期的に監視するサービスです。
「外側から」というのは、実際のユーザーと同じようにリクエストを送って動作確認する、という意味です。CPU 使用率やメモリといったインフラ側の状態を見る監視とは少し異なり、「ユーザーから見てアプリが正常に動いているか」をチェックします。
サーバーの状態は正常でも、アプリのバグやネットワーク経路の問題でユーザーが繋がれないことはありますよね。そういった問題を検知できるのが外形監視の強みです。
内部のしくみ
Canary は内部では以下のリソースで動いています。
- Lambda 関数：監視スクリプトを定期実行する本体。Canary 作成時に自動で作られます
- S3 バケット：実行ごとのログ、スクリーンショット、HAR ファイル（ページの通信記録）を保存します
- CloudWatch Metrics：成功率（SuccessPercent）や実行時間（Duration）のメトリクスが自動記録されます
- CloudWatch Logs：実行ログが記録されます
自分でスクリプトを書いてカスタマイズすることもできますが、コンソールのブループリント（テンプレート）を使えばスクリプトを書かずに始められます。今回はブループリントを使います。
料金の目安
実行 1 回あたり $0.0012 です。
https://aws.amazon.com/cloudwatch/pricing/
5 分おきに実行する場合、1 Canary で月あたり約 8,900 回の実行になります。Canary 実行料金だけで見ると月 約 $10 程度です。
これに Lambda 実行料金・CloudWatch Logs・S3 のコストが加算されます。
実際に Canary を作ってみる
今回は一番シンプルな ハートビートモニタリング ブループリントを使います。指定した URL に定期的にリクエストを送って、正常に応答するかを確認するものです。
1. Synthetics Canaries を開く
CloudWatch コンソールを開き、左のナビゲーションペインから 「Application Signals」→「Synthetics Canaries」 を選択します。
右上の「Canaryを作成」をクリックします。
2. ブループリントを選択する
「設計図を使用する」が選択されていることを確認し、設計図の一覧から 「ハートビートのモニタリング」 を選択します。
設計図はほかにも、API の動作確認・リンク切れチェック・画面の見た目の変化検知・ログイン操作の自動確認など、用途ごとに複数用意されています。テンプレートに沿って設定するだけで始められるので、スクリプトを書く必要はありません。
3. 名前と URL を設定する
Canary ビルダー セクションで Canary の名前と監視対象 URL を入力します。名前には半角英数字とハイフンが使えます。
「Locations」セクションでは、どのリージョンから監視するかを選べます。今回は東京リージョン（ap-northeast-1）を選択します。
4. スケジュール・データ保持を設定する
スケジュール セクションで実行間隔を設定します。デフォルトは 5 分おきです。「作成後すぐに開始」にチェックを入れておくと、Canary 作成直後から監視が始まります。
データ保持 セクションでは実行データの保持期間を設定できます。デフォルトは成功・障害ともに 31 日です。
5. データストレージと IAM ロールを設定する
データストレージ セクションでは、ログやスクリーンショットを保存する S3 バケットを指定します。既存のバケットを指定するか、デフォルトのまま自動作成させることもできます。
アクセス許可 セクションでは「新しいロールを作成」を選択すると、必要な権限を持つ IAM ロールを自動で作成してくれます。
設定を確認したら「Canaryを作成」をクリックします。
しばらくすると Canary が作成されて最初の実行が始まります。
URL を入れてボタンをクリックするだけで、ここまでセットアップできます。
実行結果とメトリクスを確認する
数回実行されたら、一覧から Canary 名をクリックして詳細を開いてみましょう。
可用性タブで成功率と実行履歴を確認する
詳細画面の「可用性」タブでは、成功率（SuccessPercent） のグラフと実行履歴の一覧が確認できます。
今回は 30 分間で 4 回実行され、すべて成功（100%）でした。実行履歴の各行をクリックすると、その実行のスクリーンショット・ログ・HAR ファイルを確認できます。
成功率が下がったタイミングを見ると「いつ障害が起きたか」が一目でわかります。
EC2 や ECS でホストする Web アプリに設定しておけば、深夜の障害検知やデプロイ後の動作確認に役立ちますよね。
CloudWatch Alarms と組み合わせると、SuccessPercent が閾値を下回ったときに SNS や Slack へ通知することもできます。
モニタリングタブで詳細メトリクスを確認する
「モニタリング」タブでは、期間・成功率・HTTP ステータス別のリクエスト件数がグラフで確認できます。
- 期間（Duration） — Canary の実行にかかった時間。レスポンスが遅くなってきたらここで変化として現れます
- 成功率（SuccessPercent） — 正常応答の割合
- OK（2xx）/ エラー（4xx）/ 障害（5xx） — HTTP ステータス別のリクエスト件数
「5xx が出ていないか」「4xx が増えていないか」をグラフで継続的に追えるのは、ユーザーから「エラーが出ている」と言われる前に気づける点でとても助かります。
スクリーンショットで画面の状態を確認する
実行履歴の「スクリーンショット」タブをクリックすると、Canary がアクセスした時点の画面が確認できます。
サービスは応答しているけれど画面が崩れていた、という問題もここで気づけます。
デプロイのたびに手でブラウザを開いて確認している操作を、Canary に任せられるイメージです。
HAR ファイルでリクエストの詳細を確認する
「HAR ファイル」タブでは、ページの読み込み中に発生した HTTP リクエストの詳細が確認できます。
今回の検証では 1 件の HTTP リクエスト（200 OK、1.1 KB）が 25.2ms で返ってきていることが確認できました。
実際の Web アプリでは CSS・画像・JS など多数のリクエストが含まれるため、「どのリソースが遅いか」を特定するヒントになります。
所感
今回初めて Synthetics Canary を動かしてみて、「こんなに簡単に外形監視が始められるんだ」と驚きました。
URL を入れてボタンをクリックするだけでスクリーンショット付きの死活監視が動き出すのは、手軽で導入しやすいと思いました。
内部で Lambda を使っているとは聞いていたのですが、ブループリントを使えば自分でスクリプトを書く必要がない点も助かります。
コードを書かなくていいというのは、運用チームが手を動かしやすくなりますよね。
まずは AWS ネイティブで手軽に始められる選択肢として、ぜひ手元の環境でも試してみてください。
小菅 信幸(執筆記事の一覧)
仙台在住/サウナをこよなく愛するエンジニア
2024 Japan AWS All Certifications Engineers
2025 Japan All AWS Certifications Engineers
2026 Japan All AWS Certifications Engineers
