目次

CloudWatch Internet Monitor 完全ガイド v2.0

インターネット接続品質監視とグローバルネットワーク可観測性

Amazon CloudWatch Internet Monitor は、AWS インフラストラクチャとエンドユーザー間のインターネット接続品質を監視し、ISP 障害・ネットワーク遅延・可用性低下を自動検出するマネージドネットワーク監視サービスです。AWS の広範な インターネット観測データを活用して、地域・ISP・ネットワーク別のヘルスイベント検出・パフォーマンススコア算出・CloudFront / Global Accelerator 効果測定を提供します。本ドキュメントは Internet Monitor の本質・アーキテクチャ・運用パターン・2026 年最新動向を体系的に解説します。

ドキュメントの目的

本ガイドは以下を対象としています。

  • 初心者向け: Internet Monitor とは何か、なぜグローバルサービスで必須かを学びたい方
  • ネットワークエンジニア向け: ISP 障害検出・BGP 経路問題の分析実装したい方
  • DevOps / SRE 向け: グローバルサービスのネットワーク品質ダッシュボード構築したい方
  • 意思決定者向け: Cisco ThousandEyes・Catchpoint・Datadog NPM との比較検討

2025-2026年の Internet Monitor 最新動向

  • AI による根本原因分析(2026年3月):ISP 障害 vs AWS ネットワーク問題の自動判定
  • Traffic Shift Recommendations(2026年2月):CloudFront/Global Accelerator の自動提案機能強化
  • Cross-Region Health Events(2026年4月):複数リージョン障害の相関分析
  • Real-time Alert(2026年3月):SNS / EventBridge への遅延 < 1 分 の即座通知
  • BGP Anomaly Detection(2026年4月):経路奪取(BGP hijacking)の自動検出

目次

  1. 概要
  2. Internet Monitor が解決する課題
  3. 主な特徴
  4. アーキテクチャ
  5. コアコンポーネント
  6. Health Event の種類
  7. 主要ユースケース
  8. 設定・操作の具体例
  9. 類似サービス比較
  10. ベストプラクティス
  11. トラブルシューティング
  12. 2025-2026最新動向
  13. 学習リソース
  14. 導入ロードマップ
  15. 実装チェックリスト
  16. まとめ
  17. 参考文献

概要

初心者向けメモ: CloudWatch Internet Monitor は「ユーザーから AWS インフラへの インターネット経由の接続品質を監視するサービス」です。「ユーザーのインターネット接続が遅い」という苦情を受けたとき、それが自社インフラの問題か、ユーザーの ISP の問題か、AWS ネットワークの問題かを自動的に判定できます。

CloudWatch Internet Monitor は AWS の グローバルネットワーク観測データ(CloudFront / Global Accelerator の接続情報)を活用して、世界中のユーザーから AWS リソースへの インターネット経由の接続品質を監視します。地域・ISP(インターネットサービスプロバイダー)別のパフォーマンススコア・可用性スコア・ラウンドトリップタイム・パケットロス・ビットレートを自動計測し、Health Events(ネットワーク異常)を検出・通知します。CloudFront / Global Accelerator の導入効果を定量評価することで、インフラ投資の ROI を可視化できます。

Internet Monitor の位置づけ

ネットワーク監視・可観測性スタック内での役割:

  • インターネット側の品質監視:CloudWatch Metrics が AWS リソース内部を監視するのに対し、Internet Monitor はユーザーから AWS までのインターネット経由の接続品質を監視
  • ISP 障害の自動検出:自社ネットワークチーム では対応不可能な ISP 障害を AWS が代わりに検出・通知
  • 地域別パフォーマンス分析:グローバルサービスにおける地域別ユーザー体験の定量評価
  • CDN / Global Accelerator の効果測定:インフラ投資の ROI を定量的に証明

Internet Monitor が解決する課題

Internet Monitor は、グローバルネットワーク監視における次の問いに答えるための基盤です。

課題 Internet Monitor のソリューション
「ユーザーのアクセスが遅い」という苦情の原因を特定したい 地域・ISP・ネットワーク別のパフォーマンススコア(0〜100)で、問題の影響範囲・原因を即座に特定
特定地域の ISP で接続障害が発生している Health Events で「ISP SoftBank の 30% ユーザーが接続不可」を自動検出・通知
CloudFront / Global Accelerator の導入効果を測定したい 導入前後のパフォーマンススコアを自動比較。インフラ投資 ROI を定量化
本番障害時に ISP 側か AWS 側か判定したい Internet Monitor が問題の所在(AWS インフラ vs ISP ネットワーク)を自動判定
グローバルユーザーの接続品質を可視化したい 世界 200+ 国・地域のユーザーからのネットワーク品質を ダッシュボールで一元管理
マルチリージョン構成でのネットワーク最適化 各リージョン別・キャリア別のパフォーマンスデータで、コンテンツ配置戦略を最適化
経路最適化(BGP)の効果を測定 Global Accelerator による Anycast 経路最適化の パフォーマンス向上を定量評価
業界 SLA を達成しているか証明 パフォーマンス・可用性の監視データで SLA 達成を顧客に証明
ネットワーク監視ツール(Cisco ThousandEyes 等)の購入判定 Internet Monitor で基本的な グローバル監視を実現した上で、追加投資判定

主な特徴

特徴 説明
AWS インターネット観測データの活用 CloudFront / Global Accelerator の膨大な接続データを分析。ISP・キャリア別の接続品質を自動計測
Health Events の自動検出 パフォーマンス低下・可用性喪失・パケットロス を自動検出。自社ネットワークチーム の手作業不要
City-Network 単位の細粒度監視 都市・ISP の組み合わせ(例:「東京 SoftBank」)ごとのパフォーマンス監視。セグメント分析容易
パフォーマンススコア(0〜100) 地域・ISP 別のパフォーマンスを数値化。閾値設定・異常検知が容易
可用性スコア(0〜100) 接続可能性を数値化。障害影響度の定量評価
ラウンドトリップタイム(RTT)測定 ユーザー↔AWS の往復遅延を計測。ネットワークレイテンシの原因特定
パケットロス・ジッター検出 音声・ビデオ品質に影響するネットワーク問題を自動検出
CloudFront / Global Accelerator との統合 これら AWS 高速化サービス の効果を パフォーマンスデータで実証
EventBridge / SNS 連携 Health Events を自動で通知。ワークフロー自動化
CloudWatch Logs・Metrics との統合 他の監視システムとの統合・相関分析が容易
クロスリージョン・クロスアカウント 複数リージョン・複数 AWS アカウントのネットワーク品質を一元管理

アーキテクチャ

【図1】Internet Monitor の データ流:

graph TD
    EU["🌍 ユーロッパのユーザー"]
    ASIA["🌏 アジアのユーザー"]
    AMERI["🌎 アメリカのユーザー"]
    
    EU -->|CloudFront/GA経由| AWSNetwork["AWS グローバルネットワーク<br/>(観測データ収集)"]
    ASIA -->|CloudFront/GA経由| AWSNetwork
    AMERI -->|CloudFront/GA経由| AWSNetwork
    
    AWSNetwork -->|分析| IMAnalysis["Internet Monitor<br/>分析エンジン<br/>(パフォーマンス計算)"]
    
    IMAnalysis -->|Health Events| EventBridge["EventBridge<br/>/SNS"]
    IMAnalysis -->|Metrics| CWMetrics["CloudWatch Metrics"]
    IMAnalysis -->|Dashboard| Dashboard["Internet Monitor Console<br/>ダッシュボード"]
    
    EventBridge -->|Notify| PagerDuty["PagerDuty / Slack"]
    CWMetrics -->|View| Dashboard
    
    style EU fill:#e1f5ff
    style ASIA fill:#e1f5ff
    style AMERI fill:#e1f5ff
    style AWSNetwork fill:#f3e5f5
    style IMAnalysis fill:#fff3e0
    style EventBridge fill:#e8f5e9
    style CWMetrics fill:#fce4ec
    style Dashboard fill:#e0f2f1
    style PagerDuty fill:#fff9c4

【図2】Internet Monitor が計測する階層:

graph LR
    User["🌐 エンドユーザー"]
    ISP["ISP / Carrier<br/>(例:SoftBank)"]
    CloudFront["CloudFront Edge"]
    Origin["Origin<br/>(例:ELB)"]
    
    User -->|RTT, Loss, Jitter| ISP
    ISP -->|インターネット経路| CloudFront
    CloudFront -->|エッジ接続| Origin
    
    Internet["Internet Monitor<br/>監視対象"]
    Internet -.->|測定| User
    Internet -.->|測定| ISP
    Internet -.->|測定| CloudFront
    
    style User fill:#c8e6c9
    style ISP fill:#bbdefb
    style CloudFront fill:#ffe0b2
    style Origin fill:#ffccbc
    style Internet fill:#f8bbd0

コアコンポーネント

1. Monitor(モニター)

Internet Monitor の基本単位。VPC / CloudFront / Global Accelerator を指定して作成。

主要設定項目:

  • Monitor Name:識別子(例:global-service-monitor
  • Resources:監視対象リソース
    • CloudFront Distribution ARN
    • Global Accelerator ARN
    • VPC ID
  • Traffic Percentage to Monitor:監視トラフィック比率(0〜100%)
  • Max City Networks to Monitor:監視対象 city-network 数(推奨:100〜500)
  • Health Threshold:Health Event トリガー閾値

2. City-Network(都市・ネットワーク)

ユーザーの地理的位置・ISP の組み合わせ。Internet Monitor が自動検出・監視。

要素 説明
City(都市) ユーザーの地理的位置 東京、ロンドン、シドニー
Network(ネットワーク) ISP / キャリア / ASN SoftBank(AS9605)、docomo(AS2516)
City-Network Pair 都市 + ネットワークの組み合わせ 東京 SoftBank、東京 NTT Comm

3. Health Events(ヘルスイベント)

パフォーマンス・可用性の低下を検出。

Health Event の種類:

Health Event
├─ Performance Event
│  ├─ RTT(ラウンドトリップタイム)が急増
│  ├─ パケットロスが増加
│  └─ ジッター(遅延の変動)が増大
├─ Availability Event
│  ├─ Connection Failures(接続失敗)の増加
│  ├─ Timeouts(タイムアウト)の多発
│  └─ 特定 City-Network からの到達不可
└─ Severity Level
   ├─ Critical(スコア 0〜20)
   ├─ Degraded(スコア 21〜60)
   └─ No Event(スコア 61〜100)

4. Performance Score(パフォーマンススコア)

0〜100 の数値で接続品質を表現。

スコア 状態 説明
0-20 Critical RTT > 500ms、パケットロス > 10%、到達不可
21-60 Degraded RTT 200-500ms、パケットロス 2-10%
61-100 Healthy RTT < 200ms、パケットロス < 2%、ジッター低

5. Availability Score(可用性スコア)

0〜100 の数値で接続可能性を表現。

スコア 状態
100 100% 接続可能
80-99 99-80% の接続成功率
0-79 < 80% の接続成功率(Critical)

6. Metrics(メトリクス)

CloudWatch Metrics として利用可能:

AWS/InternetMonitor
├─ Round Trip Time(RTT): ms
├─ Packet Loss: %
├─ Jitter: ms
├─ Traffic Volume: Mbps
├─ City Networks Degraded: count
├─ City Networks Unavailable: count
└─ Availability: % (0-100)

7. Traffic Distribution

地域・キャリア別のトラフィック分布。最適化ポイント特定に活用。

Traffic Distribution(月次):
日本
  ├─ Tokyo SoftBank: 30%
  ├─ Tokyo NTT Comm: 20%
  ├─ Osaka docomo: 15%
  └─ Other: 5%
アメリカ
  ├─ New York Verizon: 15%
  ├─ California AT&T: 10%
  └─ Other: 5%

Health Event の種類

Performance Events(パフォーマンスイベント)

{
  "eventType": "Performance",
  "severity": "Degraded",
  "cityNetwork": {
    "city": "Tokyo",
    "asn": "9605",
    "networkName": "SoftBank"
  },
  "metrics": {
    "roundTripTime": 450,  // ms(通常 < 200ms)
    "packetLoss": 5.2,     // %(通常 < 2%)
    "jitter": 120          // ms
  },
  "impact": {
    "affectedUsers": 25000,
    "percentageOfTraffic": 12.5,
    "duration": "5 minutes"
  },
  "rootCause": "BGP Route Change - ISP Level"
}

Availability Events(可用性イベント)

{
  "eventType": "Availability",
  "severity": "Critical",
  "cityNetwork": {
    "city": "London",
    "asn": "2856",
    "networkName": "British Telecom"
  },
  "metrics": {
    "availability": 45,      // % (通常 99.9%+)
    "failureRate": 55,      // %
    "connectionFailures": 12000  // count/hour
  },
  "impact": {
    "affectedUsers": 180000,
    "percentageOfTraffic": 35.0,
    "duration": "12 minutes"
  },
  "rootCause": "ISP Infrastructure Failure"
}

主要ユースケース

1. ISP 障害の自動検出・即座通知

背景: ISP 障害でユーザーアクセス不可 → 数分のうちに検出・対応が必要。

Internet Monitor の役割:

  • Health Events で「特定 ISP からの到達不可」を自動検出
  • SNS / EventBridge で即座に通知(< 1 分)
  • PagerDuty / Slack で アラート自動化

実装例:

イベント検出:
  時刻: 14:32 UTC
  Event: Availability イベント(Critical)
  City-Network: Tokyo / SoftBank / AS9605
  影響ユーザー: 25,000 人(全トラフィック 12%)
  
自動通知:
  → PagerDuty: Incident 自動作成
  → Slack #incidents: 「SoftBank Tokyo 接続失敗」
  → AWS Support: 自動チケット起票(Premium Support)

根本原因分析:
  Internet Monitor データ + CloudFront ログ
  → 「SoftBank の BGP 経路が CloudFront 経由の別経路に変更」
  → 20 分後に自動復旧

2. 地域別パフォーマンス分析による最適化

背景: インドのユーザーで遅延が高い → 原因が ISP か AWS か不明確。

Internet Monitor の役割:

  • 地域・ISP 別のパフォーマンススコア算出
  • 「India / Airtel のみ パフォーマンススコア 40」を検出
  • CloudFront / Global Accelerator 効果を定量評価

実装例:

パフォーマンス分析(月次レポート):

日本(Tokyo):
  全体: パフォーマンススコア 92(Healthy)
  ├─ SoftBank: 94 ✅
  ├─ NTT Comm: 90 ✅
  └─ docomo: 88 ✅

インド(Mumbai):
  全体: パフォーマンススコア 52(Degraded)
  ├─ Airtel: 48(RTT 380ms)❌
  ├─ Jio: 58(RTT 320ms)⚠️
  └─ Vodafone: 55(RTT 340ms)⚠️

対応:
  → CloudFront ムンバイ POP 追加
  → Global Accelerator インド トラフィック 100% へ変更
  
3か月後(改善検証):
  インド Mumbai 全体スコア: 52 → 78(50% 改善)

3. CloudFront / Global Accelerator 導入効果測定

背景: CDN 導入に 100 万ドル投資 → ROI を定量評価したい。

Internet Monitor の役割:

  • 導入前後のパフォーマンススコア比較
  • 地域別の改善度合い定量化
  • キャリア別の効果測定

実装例:

CloudFront 導入効果(6か月間測定):

北米(Los Angeles):
  導入前: パフォーマンススコア 65(Degraded)
  導入後: パフォーマンススコア 92(Healthy)
  改善度: +27 ポイント(42% 改善)
  → ユーザー体験向上・コンバージョン率 8% 増加

ヨーロッパ(Frankfurt):
  導入前: パフォーマンススコア 58(Degraded)
  導入後: パフォーマンススコア 88(Healthy)
  改善度: +30 ポイント(52% 改善)
  → ページロード時間 2.5s → 1.2s に短縮

アジア(Singapore):
  導入前: パフォーマンススコア 48(Degraded)
  導入後: パフォーマンススコア 82(Healthy)
  改善度: +34 ポイント(71% 改善)
  → RTT 380ms → 120ms に改善

ROI 評価:
  投資: $1,000,000
  効果: コンバージョン率向上 8-12%
  → 月次収益増加: $200,000
  → ROI: 6 ヶ月で回収

4. Global Accelerator による経路最適化効果

背景: BGP 経路最適化を導入 → 実際のエンドユーザー体験がどう改善したか?

Internet Monitor の役割:

  • Global Accelerator(Anycast)の経路最適化効果を定量化
  • Jitter・パケットロス低減を証明

実装例:

Global Accelerator 導入による RTT 改善:

Route A(従来経路):
  東京 → CloudFlare Tokyo → 西欧
  RTT 平均: 180ms, Jitter: 40ms

Route B(Global Accelerator 最適化):
  東京 → AWS Edge Tokyo → AWS Backbone → 西欧
  RTT 平均: 95ms, Jitter: 15ms(改善率 47%)

パケットロス改善:
  従来: 0.8%
  GA 最適化: 0.1%(87.5% 削減)

実感品質:
  Video Call: 遅延改善で顔表情の同期向上
  Live Gaming: RTT 短縮で競技性向上

5. SLA 達成の証明・レポーティング

背景: 顧客への SLA 報告 → インターネット品質データで サービス品質を証明。

Internet Monitor の役割:

  • 可用性スコア 99.5% 以上の達成を証明
  • 地域別・キャリア別の SLA 達成状況を可視化

実装例:

月次 SLA レポート:

Service Level Objective: 99.5% Availability

実績:
  全グローバル: 99.87% ✅(達成)
  北米: 99.92% ✅
  ヨーロッパ: 99.81% ✅
  アジア太平洋: 99.76% ✅
  
Health Events(月次):
  Critical: 0 回
  Degraded: 2 回(合計 8 分)
  
クレジット対象外:
  1 件の Critical イベント → ISP 側の障害(ISP が責任)
  
顧客報告:
  「SLA 99.5% 達成。パフォーマンス基準も超過達成」
  → 顧客信頼向上 / 契約更新率向上

6. マルチリージョン構成での キャパシティ計画

背景: グローバル拡張時に、どのリージョンに投資すべきか?

Internet Monitor の役割:

  • リージョン別のトラフィック量・パフォーマンス・可用性を一元把握
  • 最適なリージョン配置を データドリブン で決定

実装例:

トラフィック分布・パフォーマンス分析:

リージョン      | トラフィック | スコア | RTT  | 推奨施策
us-east-1      | 35%        | 94   | 45ms | ✅ 既存で十分
eu-west-1      | 25%        | 88   | 65ms | △ 需要増の場合POP追加
ap-northeast-1  | 25%        | 78   | 120ms | ⚠️ CloudFront POP追加
ap-southeast-1  | 10%        | 65   | 180ms | ❌ Global Accelerator導入

資本配分計画:
  優先度 1: AP (Southeast) → Global Accelerator 導入(即座)
  優先度 2: AP (Northeast) → CloudFront POP 追加(Q2)
  優先度 3: EU (West) → 監視継続(需要増時)

7. ネットワーク障害の根本原因分析

背景: 本番障害発生 → AWS インフラ側か ISP 側か不明確。

Internet Monitor の役割:

  • Health Events + CloudWatch Metrics + 外部 ISP データで 根本原因特定
  • 改善責任者(AWS vs 顧客)の明確化

実装例:

障害発生(ユーザー報告):
  14:32 UTC: 「インドのユーザー アクセス不可」

Internet Monitor による分析:
  14:33: Health Event 検出
    Type: Availability(Critical)
    City-Network: Mumbai / Airtel / AS9498
    Availability Score: 25%(通常 99.9%)
    Affected Users: 45,000 人

根本原因判定:
  ✅ AWS Origin: 正常(CloudFront/ALB 両者 正常応答)
  ✅ CloudFront Edge: 正常(エッジ疎通可能)
  ❌ Airtel ネットワーク: 障害(BGP 経路問題)
  
判定: 「Airtel ISP 障害」→ ISP の責任

対応:
  → Airtel に問題報告
  → 顧客に「ISP 障害、AWS側は正常」と説明
  → Airtel の復旧までの間、Global Accelerator で迂回ルート提供
  
復旧:
  15:15 UTC: Airtel 復旧
  Availability Score: 25% → 99%(40 分で回復)

8. BGP Hijacking / Route Leaks の検出

背景: 経路奪取(BGP hijacking)や経路漏洩による トラフィック誤転送 をいち早く検出。

Internet Monitor の役割:

  • 異常な RTT 増加・パケットロス から BGP 問題を推定
  • 2026 年:BGP Anomaly Detection で自動検出

実装例(2026年機能)

BGP Anomaly Detection(自動):
  
異常検出:
  時刻: 09:15 UTC
  現象: パフォーマンススコア急低下(94 → 35)
  RTT: 通常 60ms → 450ms(7.5倍)
  
Internet Monitor 分析:
  BGP Route Announcement 分析
  → 「Autonomous System 64512 からの異常な経路広告」
  → 通常経路 vs 異常経路の RTT 差を検出
  
根本原因:
  経路漏洩(Route Leak)by ISP の配下ネットワーク
  
即座対応:
  → AWS Incident Team 自動通知
  → 経路フィルタリング調整
  → ISP に報告・改善要求
  
復旧:
  09:22 UTC: スコア復旧(35 → 94)

設定・操作の具体例

AWS CLI でのMonitor作成

# Monitor の作成
aws internetmonitor create-monitor \
  --region ap-northeast-1 \
  --monitor-name global-service-monitor \
  --resources \
    "arn:aws:cloudfront::123456789012:distribution/XXXXXX" \
    "arn:aws:ec2:ap-northeast-1:123456789012:vpc/vpc-xxxxx" \
  --traffic-percentage-to-monitor 100 \
  --max-city-networks-to-monitor 500 \
  --health-events-config '{
    "AvailabilityScoreThreshold": 80,
    "PerformanceScoreThreshold": 75,
    "InternetHealthPercentageThreshold": 80
  }' \
  --tags "Environment=Production" "Team=NetworkOps"

# → 出力例
# {
#   "MonitorArn": "arn:aws:internetmonitor:ap-northeast-1:123456789012:monitor/global-service-monitor"
# }

# Monitor 詳細表示
aws internetmonitor get-monitor \
  --monitor-name global-service-monitor \
  --region ap-northeast-1

# Health Events リスト表示
aws internetmonitor list-health-events \
  --monitor-name global-service-monitor \
  --region ap-northeast-1 \
  --status ACTIVE

# City-Networks パフォーマンス表示
aws internetmonitor get-internet-events \
  --monitor-name global-service-monitor \
  --region ap-northeast-1

CloudFormation での Monitor 構築

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudWatch Internet Monitor for Global Service'

Resources:
  InternetMonitor:
    Type: AWS::InternetMonitor::Monitor
    Properties:
      MonitorName: global-service-monitor
      Resources:
        - !Sub 'arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution}'
        - !Sub 'arn:aws:globalaccelerator::${AWS::AccountId}:accelerator/${GlobalAcceleratorId}'
      TrafficPercentageToMonitor: 100
      MaxCityNetworksToMonitor: 500
      HealthEventsConfig:
        AvailabilityScoreThreshold: 80
        PerformanceScoreThreshold: 75
      Tags:
        - Key: Environment
          Value: Production
        - Key: Team
          Value: NetworkOps

  HealthEventSNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: internet-monitor-alerts

  HealthEventRule:
    Type: AWS::Events::Rule
    Properties:
      Description: 'Trigger on Internet Monitor Health Events'
      EventPattern:
        source:
          - aws.internetmonitor
        detail-type:
          - 'Internet Monitor Health Event'
      State: ENABLED
      Targets:
        - Arn: !Ref HealthEventSNSTopic
          RoleArn: !GetAtt EventBridgeRole.Arn

  EventBridgeRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: events.amazonaws.com
            Action: 'sts:AssumeRole'
      Policies:
        - PolicyName: PublishToSNS
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action: 'sns:Publish'
                Resource: !Ref HealthEventSNSTopic

Outputs:
  MonitorArn:
    Value: !GetAtt InternetMonitor.MonitorArn
    Description: Internet Monitor ARN

Terraform での構築

resource "aws_internetmonitor_monitor" "main" {
  monitor_name                  = "global-service-monitor"
  traffic_percentage_to_monitor = 100
  max_city_networks_to_monitor  = 500

  resources = [
    aws_cloudfront_distribution.main.arn,
    aws_globalaccelerator_accelerator.main.arn
  ]

  internet_measurements_log_delivery {
    s3_config {
      bucket_name = aws_s3_bucket.internet_monitor_logs.id
      enabled     = true
      prefix      = "internet-monitor/"
    }
  }

  health_events_config {
    availability_score_threshold   = 80
    performance_score_threshold    = 75
    internet_health_percentage_threshold = 80
  }

  tags = {
    Environment = "Production"
    Team        = "NetworkOps"
  }
}

# Health Events の EventBridge ルール
resource "aws_cloudwatch_event_rule" "internet_monitor_health" {
  name        = "internet-monitor-health-events"
  description = "Capture Internet Monitor Health Events"

  event_pattern = jsonencode({
    source      = ["aws.internetmonitor"]
    detail-type = ["Internet Monitor Health Event"]
    detail = {
      eventStatus = ["Degraded", "Critical"]
    }
  })
}

resource "aws_cloudwatch_event_target" "sns" {
  rule      = aws_cloudwatch_event_rule.internet_monitor_health.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.internet_monitor_alerts.arn

  role_arn = aws_iam_role.eventbridge_role.arn
}

CloudWatch Dashboard での可視化

{
  "widgets": [
    {
      "type": "metric",
      "properties": {
        "metrics": [
          ["AWS/InternetMonitor", "AvailabilityScore", {
            "stat": "Average",
            "label": "Availability Score"
          }],
          [".", "PerformanceScore", {
            "stat": "Average",
            "label": "Performance Score"
          }]
        ],
        "period": 300,
        "stat": "Average",
        "region": "ap-northeast-1",
        "title": "Global Internet Health"
      }
    },
    {
      "type": "metric",
      "properties": {
        "metrics": [
          ["AWS/InternetMonitor", "RoundTripTime", {
            "stat": "Average"
          }],
          [".", "PacketLoss", {
            "stat": "Average"
          }]
        ],
        "yAxis": {
          "left": {
            "label": "RTT (ms)"
          },
          "right": {
            "label": "Packet Loss (%)"
          }
        },
        "title": "Network Quality Metrics"
      }
    }
  ]
}

類似サービス比較

特性 Internet Monitor Cisco ThousandEyes Catchpoint Datadog NPM
計測方式 AWS グローバルネット Agent ベース + Probe SaaS Probe Agent + SaaS
ISP 障害検出 ✅ ネイティブ ✅ 高度 ✅ 高度 △ 限定
City-Network 監視 ✅ 自動検出 ✅ 手動設定 ✅ 手動設定 △ 限定
AWS 統合 ✅ 深い △ API 連携 △ API 連携 △ インテグレーション
CloudFront 効果測定 ✅ ネイティブ △ 可能 △ 可能 △ 可能
Global Accelerator 統合 ✅ ネイティブ ❌ なし ❌ なし ❌ なし
EventBridge 連携 ✅ ネイティブ ❌ Webhook ❌ API △ Webhook
コスト(AWS) ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐ ⭐⭐⭐
推奨用途 AWS Primary Multi-Cloud 複雑な構成 APM統合

ベストプラクティス

✅ 推奨される実装パターン

1. Health Events を即座に検出・通知

# Health Events ルール設定(EventBridge)
aws events put-rule \
  --name internet-monitor-critical-events \
  --event-pattern '{
    "source": ["aws.internetmonitor"],
    "detail-type": ["Internet Monitor Health Event"],
    "detail": {
      "eventStatus": ["Critical"]
    }
  }' \
  --state ENABLED

# SNS トピックへルーティング
aws events put-targets \
  --rule internet-monitor-critical-events \
  --targets "Id"="1","Arn"="arn:aws:sns:ap-northeast-1:123456789012:internet-monitor-alerts"

2. 地域別パフォーマンスダッシュボード

{
  "widgets": [
    {
      "type": "metric",
      "dimensions": {
        "Region": ["us-east-1", "eu-west-1", "ap-northeast-1"]
      },
      "metrics": [
        ["AWS/InternetMonitor", "PerformanceScore"]
      ],
      "title": "Performance by Region"
    }
  ]
}

3. 月次 SLA レポート自動生成

import boto3

internetmonitor = boto3.client('internetmonitor')

# 月次パフォーマンス統計取得
response = internetmonitor.get_internet_events(
    MonitorName='global-service-monitor',
    StartTime='2026-04-01',
    EndTime='2026-04-30',
    EventStatus='All'
)

# SLA 達成度計算
events = response['InternetEvents']
healthy_time = sum([e['Duration'] for e in events if e['Severity'] == 'None'])
total_time = 30 * 24 * 60  # 30 日
availability = (healthy_time / total_time) * 100

print(f"SLA 達成度: {availability:.2f}%")
print(f"SLA 目標: 99.5%")
print(f"達成: {'✅' if availability >= 99.5 else '❌'}")

トラブルシューティング

問題 原因 解決方法
Health Events が検出されない Monitor が正しく登録されていない Monitor 登録確認、リソース ARN 確認
City-Network データが不足 トラフィック量が少ない max-city-networks 増加、トラフィック分析
パフォーマンススコアが安定しない 計測サンプル不足 traffic-percentage 増加、期間延長
EventBridge 通知が来ない ルール設定ミス / IAM 権限不足 ルール確認、IAM ポリシー確認

2025-2026最新動向

AI による根本原因分析(2026年3月)

  • 自動判定:Health Events の原因を AWS / ISP / User Network で自動分類
  • 推奨施策の自動提示:「CloudFront POP 追加」「Global Accelerator 導入」等を自動提案

Cross-Region Health Events Correlation(2026年4月)

  • 複数リージョン障害の相関:複数リージョン同時障害を検出・根本原因分析
  • グローバル障害トラッキング:一つの ISP の複数リージョン障害を統一管理

BGP Anomaly Detection(2026年4月)

  • 経路奪取検出:BGP Hijacking / Route Leaks を自動検出
  • セキュリティアラート:異常経路からのトラフィックを自動ブロック

学習リソース

AWS 公式ドキュメント

  1. CloudWatch Internet Monitor 公式ガイド
  2. Internet Monitor API Reference
  3. Health Events ドキュメント

ネットワーク最適化ガイド

  1. CloudFront Best Practices
  2. Global Accelerator ガイド

導入ロードマップ

フェーズ 1:基本セットアップ(1週間)

  • [ ] Monitor 作成
  • [ ] リソース登録(CloudFront / Global Accelerator)
  • [ ] Health Events 通知設定

フェーズ 2:運用準備(2週間)

  • [ ] ダッシュボード作成
  • [ ] アラームルール設定
  • [ ] ドキュメント作成

フェーズ 3:継続監視(以降)

  • [ ] 月次 SLA レポート生成
  • [ ] パフォーマンストレンド分析
  • [ ] インフラ投資判定

実装チェックリスト

  • [ ] AWS アカウント・リージョン確認
  • [ ] CloudFront / Global Accelerator 構成確認
  • [ ] Monitor 作成
  • [ ] リソース登録・検証
  • [ ] EventBridge ルール設定
  • [ ] SNS トピック設定
  • [ ] ダッシュボード作成
  • [ ] Health Events 通知テスト
  • [ ] SLA レポート自動化
  • [ ] チーム教育・ドキュメント

まとめ

Amazon CloudWatch Internet Monitor は、AWS グローバルネットワーク観測データを活用した インターネット接続品質監視サービス です。地域・ISP別のヘルスイベント検出・パフォーマンススコア算出・CloudFront/Global Accelerator 効果測定を提供。ISP 障害を自社では対応不可能な早期に自動検出し、グローバルサービスのネットワーク品質を一元管理します。

AWS インフラが主体のグローバルサービスで、インターネット側の接続品質監視が重要な場合に有効。2026 年の AI 根本原因分析・BGP Anomaly Detection により、ネットワーク可観測性がさらに高度化します。


参考文献

AWS 公式

ネットワーク関連


最終更新:2026-04-27 バージョン:v2.0