Azure Network Watcherを理解するための前提
Network Watcherは単一の「疎通確認」機能ではなく、IP Flow Verify、NSG diagnostics、Next Hop、Effective Security Rules、Connection Troubleshoot、Packet Capture、VPN troubleshootなどの診断面をまとめるAzureネットワーク運用サービス。 Network Watcherの結果はtoolごとに証明範囲が違う。IP Flow Verifyはsecurity rule、Next HopはAzure-selected route、Packet CaptureはVM/VMSSのpacket、Connection Troubleshootはpoint-in-time reachabilityを観測する。
Azureのnetworking design guidanceでは、Network WatcherはVNet作成時にregion単位で自動有効化されるstarting pointとして位置づけられている。resourceが存在すること自体を「監視設定済み」とはみなさない。 control planeの設定が正しいことと、実packet/requestが成功することは別。effective route/NSGだけで完了せずactive probeまたはflow/packet evidenceで閉じる。
継続監視はConnection Monitor、過去flowの傾向はVNet Flow Logs + Traffic Analytics、瞬間のsecurity/routing診断はIP Flow Verify/Next Hop/Connection Troubleshootと使い分ける。 incidentでは最初にsubscription、region、source、destination、protocol、port、時刻を固定し、同じtest vectorを複数toolへ渡す。別条件の結果を混ぜない。
診断結果をどう読み分けるか
NSG、UDR、peering、policy、NIC等の現在値。意図された設定を確認するが、実flow成功は証明しない。
IP Flow Verify、Next Hop、Connection Troubleshoot。狙った5-tupleやdestinationでpolicy/pathを検査する。
VNet Flow Logs、Traffic Analytics、Azure Monitor。障害時刻に何が発生していたかを時間軸で追う。
Packet Capture。guest/NICで実packetを観測し、SYN/SYN-ACK、retransmission、reset、DNS等を確定する。
障害が起きたときの調べ方
- 症状ではなくtest vectorを固定する。source resource/NIC/IP、destination FQDN/IP、protocol、destination port、expected result、UTC/JST時刻を1行で記録する。
- DNSが絡む場合は名前解決結果を固定し、以後のnetwork診断は解決されたIPでも追う。FQDN結果が時間で変わるserviceではTTLと再解決も記録する。
- IP Flow VerifyまたはEffective Security Rulesでsource/destination側のsecurity判定を確認する。Allowedはroutingやserver listenを証明しない。
- Next Hop / effective routesでsourceからdestinationへのAzure-selected routeを確認する。return pathも別方向として確認する。
- Connection Troubleshootでpoint-in-time reachabilityとhops/latency/faultを取得し、必要ならPacket Captureへ進む。
- VNet Flow Logs / Traffic Analytics / resource logsで障害時刻を遡り、単発testと実production trafficが同じ現象か照合する。
- 修正後は同一test vectorを再実行し、active probe・telemetry・application journeyの少なくとも2面で回復を確認する。
仕組みと読み方
Network Watcherの価値は「全部を一画面で判定する」ことではなく、異なる観測面を同じsource/destinationに対して段階的に重ねられる点にあります。たとえばIP Flow VerifyがAllowでもNext HopがNoneならsecurityではなくroutingへ焦点を移せます。Next Hopが期待通りでもConnection TroubleshootがUnreachableならdestination listen、guest firewall、途中のNVA、名前解決、platform faultなど別レイヤーを調べます。
逆に、いきなりPacket Captureから始めると「どのNICをどのfilterで何秒取るか」が定まらずノイズが増えます。まずcontrol-plane/synthetic toolでfailure domainを狭め、packet captureを必要な5-tupleへ絞るのが再現性の高い順序です。
運用設計
| 判断軸 | 運用設計 |
|---|---|
| Evidence contract | runbookの各stepに「入力」「出力」「その出力が証明すること」「次へ進む条件」を書く。 |
| Regional readiness | 利用regionのNetwork Watcher resource/permissions/extension依存toolを事前確認する。 |
| Retention | flow/resource logsはincident後に初めて有効化しても過去を復元できない。必要なVNetへ事前配備する。 |
| Least privilege | 診断担当者にはread + diagnostic実行に必要な最小権限を与え、security rule変更権限と分離する。 |
| Time normalization | Portal/local時刻とLog Analytics UTCを混ぜず、incident recordはUTC基準+JST併記にする。 |
確認手順 / read-only first
実行前に固定する情報
- subscription / resource group / resource ID / region
- source IP/NIC/subnet と destination FQDN/IP
- protocol / source port / destination port
- UTC time window + JST表示
- expected result と known-good comparison
Evidence to keep
- command/query textとraw JSON/CSV
- Portal screenshotだけでなくresource IDを含む機械可読結果
- 変更前/変更後の同一test vector
- negative test と adjacent critical path
- rollback実施時の復帰確認
az network watcher list -o table
az network watcher connection-monitor list --location <region> -o table
az network watcher flow-log list --location <region> -o table
az network watcher packet-capture list --location <region> -o tableGet-AzNetworkWatcher
# 個別診断は各toolの記事のread-only手順を参照この結果で何を証明できるか
| 観測結果 | 証明できること | それだけでは証明できないこと |
|---|---|---|
| IP Flow Verify: Allow | 対象VM NICへ適用されるNSG/admin rule上、その5-tupleが許可。 | route、NVA、destination listen、application、WAFの成功。 |
| Next Hop: VirtualAppliance | Azure route selectionがNVA next hopを選んだ。 | NVAがpacketを転送したこと、return pathが対称なこと。 |
| Connection Troubleshoot: Reachable | その実行時点のtestでdestinationへ到達可能と判定。 | production clientの全request成功、HTTP業務意味、将来継続性。 |
| Flow log row | 対象時刻にL4 flow metadataが記録された。 | payload内容、application response semantics、packet-by-packet timing。 |
| PCAP SYN retransmit | capture pointでSYN送信/再送が実際に観測された。 | 途中のどのhopでdropされたか。対向capture/route/security evidenceが必要。 |
よくある切り分けの失敗
| 症状 / 状態 | 疑う層 | 次の証拠 |
|---|---|---|
| Portalでは正常だが疎通不可 | control-planeとdata-planeを混同 | 同一5-tupleでIP Flow Verify→Next Hop→Connection Troubleshootへ進む。 |
| tool結果が食い違う | source/NIC/IP/時刻が違う | test vectorを再固定しresource IDまで照合する。 |
| 過去障害を再現できない | telemetry未収集/retention不足 | VNet Flow Logs/必要resource logsを事前設計する。 |
| Packet Captureが取れない | extension/region/permission/capture target不整合 | packet-capture articleのpreflightを確認する。 |
| 一部clientだけ失敗 | DNS/anycast/LB/backend/return path差 | 成功clientと失敗clientを同時刻・同一Hostで比較する。 |
変更時の確認と rollback
- 診断のためにNSG/UDR/WAFを広げる前に、read-only toolで仮説を作る。
- temporary allowやroute bypassを行う場合は期限、owner、rollback command、pre/post testを同時に持つ。
- 回復後も同一test vectorを再実行し、設定を戻した後の既存connectionと新規connectionを分けて確認する。
Current notes — 2026-09-11
2026-09時点のMicrosoft networking design guidanceでは、Network Watcherをtroubleshootingのstarting pointとし、VNet Flow Logsをproduction VNetのvisibility基盤として推奨しています。Network Watcherの各diagnostic toolは証明範囲が異なるため、単一結果だけでroot cause確定にしない設計にしています。
Related articles
Official sources
動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。