ある企業が AWS 上で稼働する EC2 ベースの Web アプリケーションについて、ユーザーから「特定の地域でサイトにアクセスできない」という苦情が寄せられています。調査チームは障害が発生している地域からのアクセス状況を再現し、問題を特定したいと考えています。また、将来の障害を事前に検知するための継続的な監視も必要です。最も適切な実装はどれですか？
- A. Amazon CloudWatch Synthetics でカナリア（Canary）を作成し、問題が報告されている地域のユーザーのアクセスシミュレーションを実行する。Canary のスクリプトでログイン→商品検索→購入フローを模倣し、エラーや高レイテンシーを検知した場合に CloudWatch Alarm で SNS アラートを送信する
- B. Route 53 ヘルスチェックを設定して EC2 インスタンスの HTTP ステータスを監視し、500 エラーが発生したらフェイルオーバーを実行する
- C. CloudWatch の EC2 メトリクス（CPU、ネットワーク）を監視し、閾値を超えたらアラームを発火する
- D. ALB アクセスログを S3 に保存し、週次で Athena を使って問題のある地域からのリクエストを分析する
解答と解説を見る
正解: A
CloudWatch Synthetics のカナリアは特定の地域（Lambda 関数のリージョンを指定）から実際のユーザーと同じブラウザ操作をシミュレートし、エンドツーエンドの可用性と性能を継続的に監視します。ログインから購入までのビジネスフローを含むテストにより、特定地域での問題を早期に検知できます。問題の再現と継続的な監視の両方を一つのサービスで実現できます。 C: EC2 メトリクスのモニタリングはサーバー側のリソースを監視しますが、特定の地域ユーザーの体験や end-to-end の機能テストはできません。 B: Route 53 ヘルスチェックはエンドポイントの基本的な疎通確認に有効ですが、複数ステップのユーザーフローのシミュレーションや特定地域からのアクセステストには対応していません。 D: ALB ログの週次分析は事後分析であり、リアルタイムの検知と継続的な監視要件を満たしません。
📚 関連サービスの解説: Amazon CloudWatch ・ Amazon SNS