Amazon CloudWatch Internet Monitor - ISP 障害を即座に検出しユーザー影響を可視化する
CloudWatch Internet Monitor は、インターネット経由でアプリケーションにアクセスするエンドユーザーの可用性とパフォーマンスを、ISP・都市・ASN 単位で継続的に監視するサービスである。AWS のグローバルネットワーク観測データを活用し、パフォーマンス劣化の検出から DNS ルーティング切り替えの判断支援までを一貫して提供する。
エンドユーザー視点の監視が必要になった背景
従来の CloudWatch メトリクスは、EC2 の CPU 使用率や ALB のレイテンシなど AWS インフラ側の指標を中心に監視してきた。しかし、アプリケーションがいくら正常に稼働していても、ユーザーと AWS リージョンの間のインターネット経路に問題があれば、エンドユーザーは遅延やタイムアウトを経験する。ISP の障害、海底ケーブルの損傷、特定地域の BGP ルーティング異常など、AWS の管理外で発生するネットワーク問題は少なくない。実際、大手 ISP の障害は年間数十件規模で発生しており、影響を受けるユーザー数は数百万に達することもある。CloudWatch Internet Monitor はこの盲点を埋めるために設計されたサービスで、AWS が世界中に展開する CloudFront や Route 53 のインフラから収集したネットワーク観測データを活用し、エンドユーザーが実際に体感しているインターネット品質を可視化する。サーバー側のメトリクスだけでは見えない問題を、ユーザーに最も近い地点から捉えるという発想の転換がこのサービスの核心である。
AWS グローバルネットワークの観測データを活かす仕組み
Internet Monitor の最大の特徴は、独自のプローブやエージェントをユーザー側に配置する必要がないことにある。AWS は CloudFront の 600 以上のエッジロケーションと Route 53 のリゾルバネットワークを通じて、世界中のインターネット経路のパフォーマンスデータを常時収集している。Internet Monitor はこの膨大な観測データを、ユーザーが指定した AWS リソース (CloudFront ディストリビューション、VPC、WorkSpaces ディレクトリなど) のトラフィックパターンと突き合わせることで、特定の ISP や都市からのアクセスにおけるラウンドトリップタイム (RTT) と可用性の変動を推定する。たとえば、東京の NTT ドコモ回線からのアクセスで RTT が通常の 15ms から 120ms に跳ね上がった場合、Internet Monitor はその異常を 5 分以内に検出し、ヘルスイベントとして通知する。この検出速度は、ユーザーからの問い合わせを待つ従来の運用と比較して、障害認知までの時間を大幅に短縮する。監視対象リソースを登録するだけで、エージェントレスかつリアルタイムに近い監視が始まる点が運用負荷の低さにつながっている。
ヘルスイベントの検出ロジックとしきい値設計
Internet Monitor は、監視対象トラフィックの可用性スコアとパフォーマンススコアを 0-100 の範囲で算出し、これらが設定したしきい値を下回るとヘルスイベントを生成する。デフォルトのしきい値は可用性が 95%、パフォーマンスが 95% に設定されているが、アプリケーションの SLA に応じてカスタマイズできる。重要なのは、Internet Monitor がグローバル全体のスコアだけでなく、都市・ISP (ASN) の組み合わせごとにスコアを算出する点である。全体の可用性が 99% であっても、大阪の特定 ISP 経由のアクセスだけが 80% に低下していれば、その局所的な劣化をヘルスイベントとして捕捉する。ヘルスイベントには影響を受けるトラフィック量の推定値も含まれるため、全ユーザーの 0.5% に影響する軽微な問題と、30% に影響する重大な障害を区別して対応の優先度を判断できる。EventBridge との統合により、ヘルスイベントの発生を Lambda や SNS に連携し、自動的な対応フローを構築することも可能である。しきい値を厳しくしすぎるとノイズが増え、緩すぎると検出が遅れるため、初期運用では 1-2 週間のベースラインを観察してから調整するのが実践的なアプローチとなる。
DNS ルーティング切り替えの判断を支える可視化
Internet Monitor が提供するトラフィックインサイトは、マルチリージョン構成における DNS ルーティングの切り替え判断に直結する。たとえば、東京リージョンと大阪リージョンでアクティブ-アクティブ構成を組んでいる場合、東京リージョンへの経路で特定 ISP のパフォーマンスが劣化したとき、該当ユーザーのトラフィックを大阪リージョンに振り向けるべきかどうかを判断する材料が必要になる。Internet Monitor のコンソールでは、影響を受けている都市・ISP の組み合わせ、推定トラフィック量、RTT の増加幅がマップ上に可視化される。さらに、Route 53 のヘルスチェックと組み合わせることで、Internet Monitor のヘルスイベントをトリガーにフェイルオーバーを自動実行する構成も実現できる。Azure Front Door にも類似のグローバルトラフィック監視機能があるが、Internet Monitor は CloudFront や Route 53 との統合が深く、AWS エコシステム内で完結する点が設計上の利点となる。手動切り替えの場合でも、Internet Monitor のダッシュボードで劣化の範囲と深刻度を確認してから判断できるため、過剰反応による不要なフェイルオーバーを防げる。
コスト構造と監視対象リソースの設計
Internet Monitor の料金は、監視対象リソースが処理するトラフィック量に基づく従量課金制である。モニター 1 つあたり月額の固定費はなく、監視対象の CloudFront ディストリビューションや VPC を通過するトラフィックのうち、Internet Monitor が分析する割合に応じて課金される。監視対象トラフィックの上限はモニターごとに設定でき、最大 500,000 都市ネットワーク (都市と ASN の組み合わせ) まで対応する。コストを抑えるには、全リソースを 1 つのモニターに集約するのではなく、ビジネスクリティカルなアプリケーションに絞ってモニターを作成するのが効果的である。たとえば、社内向けの管理画面と顧客向けの本番サービスを別々のモニターで管理し、本番サービスのモニターにのみ厳しいしきい値とアラート連携を設定する。1 つのモニターに登録できるリソースは最大 50 個で、VPC の場合はリージョンごとに 1 つずつ登録する形になる。CloudFront ディストリビューションを監視対象にすると、そのディストリビューションを経由する全トラフィックの地理的分布とパフォーマンスが自動的に分析されるため、追加の設定なしに広範な可視性が得られる。
運用設計のポイントと他の監視サービスとの使い分け
Internet Monitor を効果的に運用するには、CloudWatch の他の監視機能との役割分担を明確にすることが重要である。Synthetics はプローブを定期実行して特定エンドポイントの応答を能動的に監視し、RUM はブラウザに埋め込んだ JavaScript で実ユーザーの体験を計測する。Internet Monitor はこれらとは異なり、AWS のネットワークインフラから得た観測データでインターネット経路全体の健全性を受動的に監視する。3 つを組み合わせると、インフラ層 - アプリケーション層 - ユーザー体験層の三層監視が実現する。実運用では、ヘルスイベントを EventBridge 経由で Slack や PagerDuty に通知し、オンコールエンジニアが影響範囲を確認してからフェイルオーバーの要否を判断するフローが一般的である。ヘルスイベントの履歴は CloudWatch Logs に保存でき、月次レビューで ISP 別の障害傾向を分析してマルチリージョン設計の改善に活かせる。関連書籍 (Amazon) も参考になる。