AWS Cloudwatch Syntheticsを試してみる（Route53との違い）

CloudwatchにSyntheticsの新機能が追加されたので使ってみました。
サイトの死活監視が可能なようで、
Route53のHealthCheckと少し被っているのかと思ったのですが、
Route53よりも、より詳細なリクエストを送ることが可能なようです。
まずはベーシックなハートビートのモニタリングを動かしてみました。

機能概要

ハートビートのモニタリングでは、
指定したURLへのリクエストが成功するかを検証します。
いわゆるサイトの死活監視です。

設定方法

対象のURLをAmazonのサイトにしてみます。
https://www.amazon.co.jp/

URLの欄を入力するとスクリプトに反映されるようです。

こちらで作成し、2~3分ほど待ちます。

作成されると裏側でS3やLambdaが自動生成されるようです。
多分裏ではcloudformation(SAM)が動いているっぽいですね。

実行後のイメージ

実行後に下記アウトプットが取得できました。

スクリーンショット

HARファイル

ログ

自動生成されたスクリプトが実行された際のログが出力されるようです。

S3へのエビデンス保存

さらに、上記がS3に保存されているため、過去に遡ってスクリーンショットを見ることができます。

aws s3 ls s3://cw-syn-results-xxxxxxx-ap-northeast-1/canary/www-amazon-co-jp-f81-bf25b112823a/successes/2020/05/03/14/05-37-778/
2020-05-03 23:05:39    1265313 00-loaded-loaded.png
2020-05-03 23:05:39     105985 2020-05-03T14-05-19-265Z-log.txt
2020-05-03 23:05:39     678506 results.har.html

Route53との違い

Route53ヘルスチェックの死活監視との主な違いは下記かと思いました。

Route53のメリット

• 複数拠点から死活監視が可能
• 複数拠点からのリクエスト成功率を統計的に判断材料としている

Syntheticsのメリット

Lambdaなので、VPC内からのリクエストが可能（一般公開しないサイト監視が可能）

Syntheticsのデメリット

Syntheticsは単一リージョンのLambdaからの死活監視なので、
例えば対象リージョンのLambdaに障害があった場合が心配です。
死活監視としては信頼性に弱みがあるかと思いました。

Route53との使い分け

上記理由から一般公開されたサイトの死活監視であれば、
本記事執筆時点ではRoute53を利用した方が便利かと思います。
ただ、Syntheticsはスクリーンショットの自動取得が可能なので
Route53のヘルスチェックと併用はありかと思いました。

あとは、Syntheticsは複雑なリクエストを設定可能です。
死活監視に複雑なリクエストの設定が必要であればSyntheticsの方が良いと思います。
これらの利用イメージは、次回以降でまとめてみようと思います。