目次
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)の自動検出
目次
- 概要
- Internet Monitor が解決する課題
- 主な特徴
- アーキテクチャ
- コアコンポーネント
- Health Event の種類
- 主要ユースケース
- 設定・操作の具体例
- 類似サービス比較
- ベストプラクティス
- トラブルシューティング
- 2025-2026最新動向
- 学習リソース
- 導入ロードマップ
- 実装チェックリスト
- まとめ
- 参考文献
概要
初心者向けメモ: 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:基本セットアップ(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