Operations & Troubleshooting参照資料確認: 2026-09-11

Virtual Network Flow Logs

VNet Flow LogsをVNet単位のL4 traffic metadata基盤として設計し、NSG/admin-rule判定、throughput、gateway traffic、retention、NSG Flow Logs移行を整理する。

この記事の目次

Virtual Network Flow Logsを理解するための前提

Virtual Network Flow LogsはNetwork Watcherの機能で、VNetを流れるIP trafficのL4 metadataを記録しAzure Storageへ送る。payload captureではない。 current docsでは1分intervalでAzure platform外側から収集され、resourceやnetwork trafficのthroughput/latencyへ影響しないとされる。

recordには5-tuple、direction、flow state、encryption state、throughput等が含まれ、NSG rulesとVirtual Network Manager security admin rulesの判定も扱う。 VNet-level loggingはgateway等もcoverageに含み、NSG Flow Logsより広い一方、ExpressRoute FastPathなど未対応scenarioもある。

NSG Flow Logsは新規作成不可で2027-09-30 retirement予定。既存visibility設計はVNet Flow Logsへ移行する。 同一underlying workloadでNSG Flow LogsとVNet Flow Logsを重ねるとduplicate logging/costの可能性があるため、migrationは並行確認後にlegacyを停止する。

通信や判断の流れを追う
症状を再現設定を確認能動試験ログ / packetアプリ確認

診断結果をどう読み分けるか

Raw flow

Storage上のJSON。5-tuple/direction/state/bytes等を長期保管・外部SIEMへ。

Policy context

NSG / security admin rule判定、encryption state等。

Analytics

Traffic AnalyticsをenableするとLog Analyticsでaggregate/enrichされたquery面を得る。

Boundary

L4 metadataでありpayload、HTTP status、TLS cert、application transactionは記録しない。

判定原則あるtoolがPASSしたら、そのtoolの責任範囲だけを通過条件にします。「Allow」「Reachable」「Healthy」をnetwork/application全体の正常証明へ拡大しません。

障害が起きたときの調べ方

  1. 対象VNet、期待traffic、必要retention、Storage、Traffic Analytics利用有無を設計する。
  2. 既存NSG Flow Logsが同じworkloadにあるかinventoryし、duplicate記録を避けるmigration順序を決める。
  3. VNet Flow Log resourceをenableし、targetResourceId、formatVersion、Storage、Traffic Analytics設定を保存する。
  4. known test flowを生成し、Storage raw logまたはTraffic Analyticsにsource/destination/port/directionが現れることを確認する。
  5. incidentではtime window + target VNet + 5-tupleで絞り、Allow/Deny/flow state/bytesをrouting/security/app evidenceと相関する。
  6. retention/costを定期監視し、logging gapやunintended duplicateを検出する。

仕組みと読み方

VNet Flow Logsはpacket captureより抽象度が高く、production全体の「誰が誰へどのprotocol/portでどれだけ通信したか」を継続的に追うための基盤です。全packet payloadではなくflow metadataなので、forensics/traffic inventory/capacity/security investigationに向きます。

VNet scopeへ拡張されたことで、NSGが無いtrafficやgatewayを含むより広いtraffic visibilityを得られるscenarioがあります。ただし「flow logに無い = packetが絶対存在しない」とは限らず、supported scenario、収集遅延、target VNet、FastPath等のboundaryを必ず確認します。

運用設計

判断軸運用設計
Scopeproduction VNetごとにenableする原則とexceptionを文書化。
Storageregion/retention/security/cost/SIEM exportを設計。
Analyticsraw JSON中心かTraffic Analytics中心かを目的で分ける。
MigrationNSG Flow Logs→VNet Flow Logsはparallel validation後にlegacy停止。
Costgateway等を含む広いcoverageでvolume増加し得るためingestion/storageを監視。

確認手順 / 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実施時の復帰確認
Azure CLI — read-only first
az network watcher flow-log list --location <region> -o table
az network watcher flow-log show --location <region> --name <flow-log-name> -o jsonc
PowerShell — read-only first
Get-AzNetworkWatcherFlowLog -NetworkWatcher <watcher>
# target resource / storage / traffic analytics設定をread-onlyで確認

この結果で何を証明できるか

観測結果証明できることそれだけでは証明できないこと
Flow entry existssupported capture scopeでL4 flow metadataが記録された。payload、HTTP/TLS/application成功。
Allowed/Deny metadatanetwork policy evaluationの記録。他security layerやguest firewallの全判定。
Bytes increaseそのflowでdata transferが記録。user-perceived performance/transaction completion。
No record対象window/scopeで該当flowが見えない。通信不存在の断定前にsupport/lag/configを確認。
Gateway traffic presentVNet-level loggingがgateway trafficをcapture。ExpressRoute FastPath等unsupported pathまで全て含むこと。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
ログが来ないtarget/region/provider/storage/configflow-log resourceとStorage pathを確認。
二重に見えるNSG + VNet flow logs併用migration中か確認しlegacy停止計画へ。
Traffic Analyticsに遅延aggregation/processingraw Storage logとactive diagで切り分け。
量が急増gateway/coverage/traffic changeVNet scopeとtop talkerを確認。
FastPathを見たいsupport boundaryExpressRoute FastPathはVNet Flow Logs未対応。別telemetryへ。

変更時の確認と rollback

  • enable/disableはobservability changeとしてtraffic path変更と分離する。
  • migration中はnew logの実traffic確認前にNSG Flow Logsを削除しない。
  • rollback時もStorage上の既存record retentionは別管理であることを確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

NSG Flow Logsは2025-06-30以降new creation不可、2027-09-30 retirement予定です。current Microsoft guidanceはVNet Flow Logsへのmigrationを要求しており、本ページはVNet Flow Logsをdefaultのproduction flow-visibility基盤として扱います。

Official sources

動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。