はじめに
皆さんこんにちは！2025年度新入社員の 福井 です！
部署に配属されてから5カ月が経過し、もうすぐ2025年が終わろうとしています。
今回はAWSのハンズオンを通して得た知見を共有します。
少しでもみなさんの学びのきっかけになれば幸いです。
日々アプリケーションを運用していると、こんな経験はないでしょうか？
アプリの動作が遅いことにユーザーからの報告が来て初めて気づく
CloudWatchメトリクスでは正常なのに、実際の画面ではエラーが出ていた
このような、アプリ監視におけるあるあるを解消する手段の一つが、Amazon CloudWatch Synthetics (CloudWatch Synthetics)です。
本記事では、CloudWatch Syntheticsを使った「アプリの外形監視」について紹介します。
内部監視と外形監視
はじめに、とあるWebサイトの利用フローを想像してみます。
一見するとこのフローは非常にシンプルですが、実際の利用環境では多くの潜在的な失敗が潜んでいます。
正しいID / パスワードを入力してもログインが失敗する
ページは遷移できたが、画面のボタンが反応しない
CSSが崩れてUIが完全に壊れて見える
多くの場合、これらはユーザーの問い合わせによって初めて発覚します。
つまり、メトリクスやログなどの "内部監視だけ"では、ユーザー体験の異常には気づけません。
AWS Well-Architected Framework の観点から
AWS が提供する Well-Architected Framework は、高品質なアーキテクチャを構築するためのベストプラクティスです。特に運用上の優秀性(Operational Excellence) では次のような監視姿勢が重要だと明確に述べられています。
異常はユーザーより先に検知すること
サービスの状態は自動で監視されるべきである
ユーザー体験を含めて"想定した通りの挙動か"を確認すること
ユーザーからの問い合わせで気づく監視体制は、これらの原則に反しておりアンチパターンに該当します。
ここで求められるのは、ユーザーからの行動そのものを監視する仕組み( 外形監視 )です。
そしてAWSでそれを担うのが CloudWatch Synthetics です。
CloudWatch Synthetics
CloudWatch Synthetics の外形監視は、ユーザーの代わりにWebサイトへアクセスし、ログイン・ページ操作・表示崩れの有無など「ユーザー体験そのもの」を自動チェックする仕組みです。
その裏側では、複数のAWSサービスが連携しながら監視を支えています。
上記は代表的な構成例で、各コンポーネントについて整理します。
AWS Lambda
CloudWatch Synthetics が Web サイトにアクセスする際、実際の処理を実行しているのは AWS Lambda です。
そして、この Lambda の中で動作する “監視専用のスクリプト” が Canary で、ブラウザ操作・ログイン・画面の状態確認といった ユーザー操作そのものを模擬する役割 を担っています。
言い換えると
Lambda は Canary を動かすためのエンジン、
Canary はユーザー操作を模してページを動かし、画面や機能に問題がないかをチェックする仕組み
と言えます。
この2つが組み合わさることで、CloudWatch Synthetics は「ユーザー体験そのものを自動で確認する」外形監視を実現しています。
Amazon S3
CloudWatch Syntheticsの外形監視では、単なる「成功/失敗」だけでなく、実際にCanaryがブラウザを操作した証跡を細かく残すのが特徴です。これらの成果物は全てAmazon S3 に自動保存されます。
主な保存内容は次の通りです。
🔹 スクリーンショット
Canary実行中の各チェックポイントで画面キャプチャを自動撮影します。
UIの崩れやCSSの読み込み失敗など内部監視では見えない"画面そのものの異常"を後から確実に確認できます。
🔹 HAR ファイル
ブラウザのネットワーク通信情報を記録したファイルです。
ここにはレスポンスの遅延や各リクエストのステータスコードなどが保存されます。
🔹 Canary 実行レポート
Canary の実行結果がJSON 形式で保存されます。
Amazon CloudWatch Logs
CloudWatch Logs には、Canary を実行する Lambda 関数内部で発生した処理のログがすべて集約されます。Canary の裏側で何が起きていたかを可視化する重要なコンポーネントであり、外形監視の結果だけでは分からない問題の根本原因を特定するうえで欠かせません。
AWS Identity and Access Management
Canary が安全に実行されるための権限を制御する役割を持ちます。
具体的には以下のようなアクセス権限がLambdaに付与されます。
S3 への書き込み権限
監視結果を保存するためCloudWatch Logs への出力権限
Lambdaの内部処理のログを記録するため
このように複数のAWSサービスが密接に連携しながら監視を支えています。
料金体系
初期費用や最低利用料金はかからず、使った分だけコストが発生する従量課金制です。
料金はリージョンごとに異なります。また、Canary 実行ごとに S3 や CloudWatch Logs など、関連サービスの利用料が別途発生する点に注意です。
アジアパシフィック(東京)の場合： USD 0.0019 / Canary実行
無料利用枠：1か月あたり100回までCanaryを実行可能
実際にCognito認証の外形監視に挑戦
今回、Amplifyで用意した監視用ページにCanaryがアクセスし、CognitoでのログインからAPI Gateway , Lambdaによるトークン交換までの一連の認証フローが正常に動くかを自動で確認する仕組みを設計しました。
今回、上記構成(Amplify～Lambda)の設計方法に関しては、割愛します。
CloudWatch Synthetics の設定
①
まずCloudWatchのコンソール画面にアクセスし、左側のナビゲーションメニューから「Synthetics Canaries」を選択します。次に「Canaryを作成」をクリックします。
②
次にCanaryの基本情報を設定します。
スクリプトタイプの選択
今回は簡単にURLの稼働チェックを行うため、スクリプトタイプの選択ではBlueprint(設計図)というAWSが用意してくれているテンプレートを使用し、実行可能なスクリプトを即座に自動生成してもらいました。設計図の種類は、ハートビートのモニタリングを選択しました。その他にHTTPステータス確認など基本的な監視タイプが揃っています。Canaryビルダーの設定
Amplifyで事前に作成した監視対象のURLをここにコピー＆ペーストします。
また「スクリーンショットを撮る」のチェックボックスもオンにしておきます（任意）。
これを有効にすると、Canaryの実行ごとに 実際のブラウザで表示された画面のキャプチャ が自動で保存されます。スケジュールの設定
Canaryの実行スケジュールに関して、今回は通常のWebサイト監視なので実行間隔を「1分」に設定しました。アクセス許可とストレージ設定
CloudWatch Syntheticsがテスト結果を保存・実行するための設定を行います。
今回は、 下記の権限を付与しました。
・AmazonS3FullAccess
・CloudWatchLogsFullAccess
・CloudWatchSyntheticsFullAccessアラーム連携
せっかく監視しても、異常が起きた時に気づけなければ意味がありません。 CloudWatchアラームを設定して、メール通知を受け取るようにしました。
最後に「Canaryを作成」をクリックすると、Canary完成です！
作成したCanary一覧にて、数分待つと、最新の実行結果に"Success"または"Failed"が表示されます。
詳細画面を見ていきます！
Canaryの実行と結果確認
この画面では、作成したCanaryの動作状況をひと目で確認できます。
アプリの可用性や応答状況をリアルタイムで把握できる、いわゆる監視ダッシュボードみたいなものです！
ステータス(左上の円グラフ)
ここでは現在実行中の Canary の稼働結果の内訳を示しています。
具体的には、「Success（成功）」「Failed（失敗）」「Passed with retries（再試行で成功）」「Failed with retries（再試行しても失敗）」といった結果を色分けして可視化します。
今回は"成功"と出ています。Canary実行グラフ
今回、監視の実行間隔を「1分」に設定しているため、各実行結果が点としてプロットされています。
これにより、どの時刻にエラーが発生したかを直感的に把握でき、たとえば「深夜帯だけ失敗している」といった時間帯ごとの傾向も簡単に確認できます。
次にCanary一覧テーブルから、監視対象のCanaryを選択し、詳細情報を見てみましょう。
Canary詳細画面
ここでは個々の監視実行の結果をより詳しく確認できます。
- Canary 実行ステップ
CloudWatch Synthetics の Canary は、実際のユーザーと同じようにログインの流れを 4 ステップで検証していることが分かります。今回は全て成功しています。
スクリーンショット
実際にCanaryが監査対象のURLにアクセスした時のブラウザ画面のキャプチャを表示してくれます。
「失敗したステップのみ」を表示するフィルターもあり、異常発生時の状態を即座に確認できます。
ログ
ここでは、CloudWatch Logs に記録された実行ログを確認できます。
テストが失敗した場合は、HTTPステータスコードやタイムアウトの発生状況など、原因を特定するための詳細情報を参照できます。
このようにスクリーンショットで「現象」を、ログで「原因」を把握できるため、問題の早期発見と切り分けをスムーズに行えます。
まとめ
アプリの安定稼働を守るには、「動いているはず」ではなく「実際に動いている」を確かめることが大切です。
CloudWatch Synthetics は、その“確かめる”作業を自動化し、スクリーンショットやログを通じて、問題の早期発見の一助となってくれます。
運用の第一歩として、CloudWatch Synthetics をぜひ利用してみましょう！
Japan AWS Jr. Championを目指してます！
