Azure Network Watcher

解決する課題

• VM やサービスに到達できないとき、NSG・ルート・ファイアウォールのどこで止まっているのかを手作業で追うのは大変で、原因の切り分けに時間がかかる
• 「この送信元から宛先への通信は許可されるのか拒否されるのか」を、実際に通信せずに設定だけから判定したい
• ネットワーク内を流れる通信を記録して、誰がどこへどれだけ通信したかをセキュリティ分析やトラブル調査に使いたい
• 複雑になった仮想ネットワークの構成（トポロジ）を俯瞰し、サブネットや接続関係を把握したい
• 特定区間のパケットを実際にキャプチャして、より深いレベルで挙動を確認したい

主要概念と用語

• Network Watcher: リージョン単位で有効化される、ネットワークの監視・診断・ログ機能を束ねたツール群（サービス）。個別の診断機能の入れ物と考えるとよい
• 接続のトラブルシューティング（Connection Troubleshoot）: ある送信元（VM など）から宛先への到達性を実際にテストし、経路上のどこで失敗したか（NSG・UDR・遅延など）を返す
• IP フローの確認（IP Flow Verify）: 5 タプル（送信元 IP・ポート、宛先 IP・ポート、プロトコル）と方向を与えると、NSG ルールに基づき許可か拒否かを判定し、拒否ならどのルールが原因かを示す
• 次ホップ（Next Hop）: 指定した宛先 IP へ向かうパケットが、次にどこへ転送されるか（インターネット・仮想アプライアンス・VNet ピアリングなど）と適用ルートを返す
• NSG 診断 / 有効なセキュリティルール: 対象 NIC・サブネットに実際に適用されている NSG ルールの合成結果を確認する
• VNet フローログ（旧 NSG フローログ）: 仮想ネットワークを通過する IP トラフィックを記録し、ストレージへ保存するログ。Traffic Analytics と組み合わせると可視化・分析できる
• パケットキャプチャ: 対象 VM 上で実際のパケットを取得し、ストレージや Blob に保存する。深い解析に使う
• トポロジ: リソースグループ/VNet 内のネットワーク構成（サブネット・NIC・接続関係）を図として表示する
• 接続モニター（Connection Monitor）: 拠点間・VM 間・エンドポイントへの到達性と遅延を継続的に監視し、しきい値超過を検知する

仕様・制限・クォータ

• Network Watcher はリージョンごとに有効化される。多くの場合、VNet を作成したリージョンで自動的に有効化されるが、明示的に有効化・管理することもできる
• 機能の多くはAzure 上のリソース（VM・NIC・VNet など）を対象とする診断であり、対象には Azure 側のエージェントや拡張機能が必要な場合がある（例: パケットキャプチャや接続モニターは VM 拡張機能を利用）
• IP フロー確認や次ホップは設定（NSG・ルート）に基づく論理判定で、実際にパケットを流さずに結果を返す。一方、接続トラブルシューティングやパケットキャプチャは実トラフィックを伴う
• VNet フローログは記録先のストレージアカウントが必要で、保持期間や取得対象を設定する。Traffic Analytics を使う場合は Log Analytics ワークスペースも必要
• 旧来の NSG フローログは VNet フローログへ移行が進んでいる。新規構築では VNet フローログの利用が推奨される
• 同時に取得できるパケットキャプチャ数や、フローログの保持・容量などには上限・クォータがある（最新値は公式ドキュメントで確認）

内部の仕組み

Network Watcher の診断は大きく**「設定ベースの論理判定」と「実トラフィックを伴う実測」**に分かれます。

• 論理判定系（IP フロー確認・次ホップ・有効なセキュリティルール）: 対象リソースに適用されている NSG・UDR・システムルートを評価エンジンで合成し、「許可/拒否」「次の転送先」を返す。実際の通信は発生しないため、安全かつ高速に切り分けできる
• 実測系（接続トラブルシューティング・接続モニター・パケットキャプチャ）: 対象 VM 上のエージェント/拡張機能を介して実際にプローブやキャプチャを行い、ホップごとの到達性・遅延・損失や生パケットを取得する
• フローログ: プラットフォーム側が VNet を通過する IP フローのメタデータ（5 タプル、許可/拒否、バイト/パケット数など）をストレージへ書き出す。Traffic Analytics はそれを Log Analytics に取り込み、地理・アプリ別などに集計・可視化する
• トポロジ: リソースグラフを読み取り、サブネット・NIC・接続の関係を図に起こす

設計パターン / ベストプラクティス

• 切り分けは論理判定 → 実測の順: IP フロー確認・次ホップ・有効なセキュリティルールで設定面を先に潰し、残った問題を接続トラブルシューティングやパケットキャプチャで深掘りする
• フローログは VNet フローログを既定に: 新規は VNet フローログ＋Traffic Analytics を標準化し、トラフィックの可視化・異常検知・セキュリティ分析の基盤にする
• 継続監視は接続モニター: 重要な拠点間・サービス間の到達性と遅延を接続モニターで常時監視し、劣化をアラート化する（単発の診断と使い分ける）
• 記録先と保持の設計: フローログ/キャプチャの保存先ストレージのライフサイクル管理や保持期間を決め、コストとコンプライアンス要件を両立させる
• 権限の最小化: 診断やキャプチャは機微な情報に触れ得るため、実行できるロールを限定し、操作を監査ログに残す

運用・監視

• Azure Monitor / Log Analytics と連携し、フローログや接続モニターの結果を集計・アラート化する
• 接続モニターのしきい値（到達率・往復遅延・損失）を設定し、劣化を継続的に検知する
• 障害対応のランブックに、IP フロー確認 → 次ホップ → 接続トラブルシューティングという切り分け手順を組み込んでおくと初動が速い
• フローログは容量が増えやすいため、保持期間とストレージのライフサイクルを定期的に見直す

コスト

• 課金は主に実行・記録を伴う機能で発生する。論理判定系（IP フロー確認・次ホップなど）の軽量チェックは比較的低コスト、もしくは回数に応じた課金になる
• VNet フローログは処理されたデータ量や記録先ストレージ容量、Traffic Analytics で取り込むLog Analytics の取り込み量がコスト要因になる
• 接続モニターはテスト数や実行頻度に応じて課金される。重要区間に絞って設計するとコストを抑えられる
• パケットキャプチャは保存先ストレージの容量が中心。取得範囲・サイズ上限・保持期間を絞ると無駄が減る
• 変動する具体的な単価は公式の料金ページで確認すること

セキュリティ

• フローログやパケットキャプチャは通信内容やメタデータを含むため、保存先ストレージのアクセス制御・暗号化を徹底し、最小権限で扱う
• 診断機能の実行権限は RBAC で限定し、誰が・いつ・どのリソースを診断したかを監査ログに残す
• VNet フローログ＋Traffic Analytics は、想定外の通信・拒否トラフィックの急増などを検知するセキュリティ運用の素材になる
• パケットキャプチャは機微情報を含み得るため、取得は必要最小限の区間・期間に限定し、取得後は速やかに保護・削除する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 到達性問題の切り分けを標準化し、診断を自動化・観測可能にする中核ツール。ランブック化で初動を短縮できる
• 信頼性（Reliability）: 接続モニターで重要区間の到達性・遅延を常時監視し、劣化を早期検知してフェイルオーバーや是正につなげる
• セキュリティ: フローログによる通信の記録と分析が、異常検知・監査・インシデント調査の基盤になる
• コスト最適化: フローログ/キャプチャの保持と接続モニターのテスト範囲を適切に絞ることで、可観測性とコストを両立させる

試験で問われるポイント

関連サービス・比較

• 役割としては、AWS の VPC Reachability Analyzer（到達性の論理判定） と VPC Flow Logs（トラフィック記録） を合わせたような位置づけにあたる。Azure ではこれらが Network Watcher という1 つのツール群にまとまっている
• Network Watcher 自体は通信経路に介在せず、診断・記録・可視化に徹する。実際の制御は NSG・UDR・Azure Firewall などが担い、Network Watcher はそれらが正しく効いているかを確かめる役割
• 継続的な可観測性は Azure Monitor / Log Analytics と連携して実現する。フローログや接続モニターの結果はこれらに集約してアラート化するのが定石

ハンズオン / CLI例

# リソースグループ（例）
az group create --name demo-rg --location japaneast

# 対象リージョンで Network Watcher を有効化
az network watcher configure \
  --resource-group demo-rg \
  --locations japaneast \
  --enabled true

# IP フロー確認: 指定の VM が宛先 80 番への送信を許可されるか判定
az network watcher test-ip-flow \
  --resource-group demo-rg \
  --vm demo-vm \
  --direction Outbound \
  --protocol TCP \
  --local 10.0.0.4:12345 \
  --remote 93.184.216.34:80

# 次ホップ: 宛先 IP へ向かうパケットの次の転送先と適用ルートを確認
az network watcher show-next-hop \
  --resource-group demo-rg \
  --vm demo-vm \
  --source-ip 10.0.0.4 \
  --dest-ip 93.184.216.34

# 接続トラブルシューティング: VM から外部 FQDN への到達性をテスト
az network watcher test-connectivity \
  --resource-group demo-rg \
  --source-resource demo-vm \
  --dest-address www.contoso.com \
  --dest-port 443