1.はじめに
クラウド利用が当たり前となった今、ネットワークのトラフィック監視はこれまで以上に重要な役割を担うようになりました。特にAzure環境では、Network Security Group(NSG)・Azure Firewall・ネットワークマネージャー(ANM)など複数のレイヤーで通信が評価されるため、どこで通信が止まっているのかを把握することが以前より難しくなっています。
これまでAzureの主力はNSGフローログでしたが、2026年3月時点ではすでに新規作成ができず、2027年9月30日には完全廃止されることが発表されています。
そこで新たな監視手段として登場したのが仮想ネットワークフローログ(以下、VNetフローログ)です。仮想ネットワーク(VNet)全体を俯瞰してログを取得でき、従来のNSGフローログでは見えなかったトラフィックも可視化できます。
本ブログでは、このVNetフローログの基本とNSGフローログとの違いを、実際の検証を交えて分かりやすく紹介していきます。
2.仮想ネットワークフローログ(VNetフローログ)とは
そもそもフローログとは何なのか?
フローログとは、ネットワーク上を流れる通信(フロー)を単位として記録するログです。
ここでいう「フロー」とは、通信元/宛先のIPアドレスやポート、プロトコルなどの組み合わせで識別される、一連の通信を指します。
Azureのフローログでは、「どの通信が」「許可されたのか/拒否されたのか」といった情報を、Azureのネットワーク基盤側で観測・記録します。そのため、OSやアプリケーションのログとは異なり、ネットワーク制御の観点から通信の成否を把握するためのログである点が特徴です。
仮想ネットワークフローログ(VNetフローログ)は、Azure Network Watcherが提供するVNet全体の通信を可視化するログ機能です。Azureの基盤側で観測したトラフィックをもとに、ネットワーク内部でどのような通信が発生しているかを把握できます。
ログ取得範囲は柔軟で、VNet・サブネット・NIC単位から選択可能です。これにより、ネットワーク全体を俯瞰したい場合にも、特定箇所を詳細に分析したい場合にも対応できます。取得したログはAzure上で保存できるため、リアルタイムだけでなく、発生後の調査や長期的な通信傾向の分析にも活用できます。
このようにVNetフローログは非常に強力な監視手段ですが、すべての情報が取得できるわけではありません。あらかじめ取得できる内容とできない内容を理解しておくことが重要です。
VNetフローログで取得できる主な情報
- 通信元/宛先IPアドレス・ポート
- プロトコル(TCP/UDPなど)
- 通信の許可(Allow)/拒否(Deny)の結果
- 通信を評価した制御レイヤーやルール(NSG、ANMなど)
VNetフローログでは取得できない情報
- パケットの中身や通信内容
- OSやアプリケーションのエラーログ
- HTTPステータスコードなどアプリケーション層の情報
VNetフローログは、「どこで通信が許可・拒否されたか」を把握するためのログであり、通信内容の詳細やアプリケーションの挙動を確認する場合は、別のログと組み合わせて分析する必要があります。
3.NSGフローログとVNetフローログの違い
ここまでで、VNetフローログがAzureネットワーク全体を対象としたログ収集の基盤であることを紹介しました。
本章では、従来のトラフィック監視の中心であったNSGフローログと比較しながら、VNetフローログがどのように機能し、どの場面で効果を発揮するのかを整理します。
3.1 そもそもNSGフローログとは
NSGフローログはNSGを通過したトラフィックを記録するログ機能です。
ログ化される対象は「NSGが評価した通信」に限定されており、記録される内容もNSGのルールによって許可(Allow)または拒否(Deny)された結果に基づきます。
3.2 設定箇所の違い
NSGフローログは、NSGを窓口としてログを取得する仕組みです。
そのため、VNet全体のログを取得したい場合、各サブネットやNICにNSGを割り当て、それぞれでフローログを有効化する必要がありました。
一方、VNetフローログはVNet全体を観測対象とします。
フローログを有効化する際の設定はVNet単位で1箇所に集約されるため、構築難度は非常に低くなっています。また、VNetだけでなくサブネット単位・NIC単位での設定も可能なため、用途に応じて柔軟にログを構成できます。
3.3 ログの取得範囲
NSGフローログは、前述の通りNSGを通過するトラフィックのみを監視できます。
それに対し、VNetフローログはVNet全体を俯瞰して監視するため、以下のようなNSG以外のレイヤーを通るトラフィックも含めて取得することができます。
- ネットワークマネージャー(Security Adminルール)
- Azure Firewall
- オンプレミス接続(VPN/ExpressRoute)を含むゲートウェイ経由の通信
- Private Endpoint /Application Gateway 経由通信
3.4 評価レイヤーの可視化
NSGフローログは、NSGで評価された通信のみを記録します。一方Azureでは、NSG以外にもANMやAzure Firewallなど複数のレイヤーで通信が評価されています。
VNetフローログでは、AclGroup/AclRuleとして「どのレイヤーが通信を許可/拒否したか」を確認できるため、NSGだけでは把握できない評価ポイントを可視化できます。
ただし、すべてのレイヤーで詳細なルール名まで取得できるわけではありません。(例:Azure Firewallのルール名はVNetフローログでは確認できない)
そのため、VNetフローログは各レイヤーの評価結果を俯瞰するのに有効ですが、詳細分析には個別のリソースログとの併用が必要となります。
3.5 まとめ
これまでの結果を表にまとめました。
| 項目 | NSGフローログ | VNetフローログ |
|---|---|---|
| 設定箇所 | NSGに対して設定 | VNet/サブネット/NIC単位で設定可能 |
| ログの取得範囲 | NSGを通過する通信のみ | VNet内で発生する通信を幅広く取得 |
| 評価レイヤー | NSGのルールのみ | NSG/ANMなど複数レイヤーの評価結果を横断 |
NSGフローログは、NSGを通過した通信に対する許可・拒否の結果を確認するためのログであり、特定の制御点に着目したトラフィック監視に適しています。
一方、VNetフローログは、NSGやANM、Azure Firewallなど複数の制御レイヤーを横断して、通信を可視化できる点が特徴です。複数の制御が組み合わさった環境において、「どこで通信が止まっているのか」を切り分けたい場合に有効です。
これが、VNetフローログがAzureネットワーク監視において重要な役割を果たす大きな理由です。ただし、VNet全体を対象とすることからNSGフローログに比べて、ログ量は増えやすく、コストも上昇しやすくなっています。そのため、各自の利用目的に応じた設計が重要になります。
4.実際に使ってみた
ここまででVNetフローログの特徴を整理してきました。
では実際にVNetフローログを設定し、通信がどのように記録されるのかを確認していきましょう。

図1.検証環境のVNet構成図
◆ 検証環境
➢VNet構成
VNet-Prod (10.0.0.0/16) 内に以下のサブネットを構成しています:
- AppSubnet (10.0.1.0/24):Azure VM (vm-app)
- BlockedSubnet (10.0.2.0/24):Azure VM (vm-blocked)
- AzureFirewallSubnet (10.0.3.0/26):Azure Firewall (Basic SKU)
- AzureFirewallManagementSubnet (10.0.3.64/26)
- AzureBastionSubnet (10.0.4.0/26):Azure Bastion(Developer SKU)
➢制御設定
- UDRにより 0.0.0.0/0 を Azure Firewall へルーティング
- NSGで 443 ポート Inbound を拒否(BlockedSubnet 側のみ配置)
- ANMで 445 ポート Inbound を拒否
- Azure Firewall アプリケーション規則で
*.google.com宛て Outbound を許可
※ネットワークマネージャー(ANM)とは、複数ネットワークに対するセキュリティ規則や接続構成を一元的に適用できる管理サービスです。Azureの通信評価はANM→NSG→Azure Firewallの順で行われ、上位レイヤーの評価が通過した後に次の制御へ進みます。
◆ VNetフローログ設定
- VNetフローログ:ストレージアカウントへ保存(既定動作)
- Traffic Analytics:有効化し、Log Analytics ワークスペースにも分析・集計されたデータを保存

図2.VNetフローログの設定画面1

図3.VNetフローログの設定画面2
◆ 制御レイヤー設定
- ANM,NSG,Azure Firewallの各種設定は次のようにしました。

図4.ANMの制御設定

図5.NSGの制御設定

図6.Azure Firewallの制御設定
◆ テスト1:vm-app → vm-blocked への 80/443/445 ポート疎通確認
vm-app から vm-blocked のプライベートIP宛に、PowerShell の Test-NetConnection を用いて疎通確認を行いました。

図7.80/443/445ポートの疎通確認結果
80番は通信可能、443・445番はNSGおよびANMの設定により拒否されることを確認しました。
➢VNetフローログでの記録結果
次のクエリを用いて、対象通信のログを抽出しました:
|
1 2 3 4 5 6 7 |
NTANetAnalytics | where DestPort in (80, 443, 445) and DestIp has "10.0.2.4" and SrcIp has "10.0.1.4" and FlowDirection has "Inbound" | project FlowStartTime, SrcIp, DestIp, DestPort, FlowDirection, FlowStatus, AclGroup, AclRule |
VNetフローログでは、80番ポートがAllowed、443・445番ポートがDeniedと正しく記録され、さらに AclGroup /AclRule の情報から「どの評価レイヤーで拒否されたか」を確認できます。

図8.VNetフローログの結果1
➢NSGフローログとの比較
NSGフローログではNSGを通過した通信のみ記録されるため、今回の例では445番ポート拒否が記録されません。これはANMがNSGを通るより先にブロックしたためであり、NSGフローログ単体では運用上の抜け漏れが生じる典型例です。
一方、VNetフローログでは複数の制御レイヤーを横断して可視化できます。
◆ テスト2:vm-app → インターネット(google / yahoo / bing)
Microsoft Edge を用いて外部サイトへアクセスし、Firewall のアプリケーション規則がどのように反映されるか検証しました。

図9.ブラウザの疎通確認結果
➢VNetフローログでの記録結果
AzureFirewallSubnet を観測ポイントとして、以下のクエリで Firewall 経由の外向き通信を確認しました。
|
1 2 3 4 5 |
NTANetAnalytics | where SrcSubnet == "test/vnet-prod/azurefirewallsubnet" and FlowType == "ExternalPublic" | project FlowStartTime, SrcIp, DestPort, L4Protocol, FlowDirection, FlowStatus, SrcSubnet, DestPublicIps |
出力されたログより、検証で試行した通信先のうちGoogle.comに対応する142.x.x.x(Google AS)宛て通信のみが記録されていることから、google.com 宛て通信のみが許可されていることが確認できました。
なお、Firewallの詳細なルール名はVNetフローログでは取得できないため、Firewallのログと併用することでより正確な分析が可能です。

図10.VNetフローログでの記録結果2
◆ 検証結果まとめ
- VNetフローログは NSG だけでなく ANM や Firewall を含む複数レイヤーの「評価結果」を横断して確認できる
- 各リソースのルール名の詳細がすべて取得できるわけではないため、ログの特性を理解して使う必要がある
- ANM → NSG → Firewall といった複数の制御が関与する環境でも、通信の許可/拒否の「理由」に早くたどりつける
日々の運用だけでなく、トラブルシューティングやネットワーク設計の検証にも非常に有用です。
5.まとめ
今回は、VNetフローログの概要からNSGフローログとの違い、そして実際の検証結果まで紹介してきました。
NSGフローログの廃止が正式に発表されている現在、VNetフローログはAzureネットワーク監視の新しい標準となる機能です。本ブログが、機能理解や導入検討の一助になれば幸いです。
双日テックイノベーションでは、Azure環境の構築から運用設計まで幅広く支援しています。
NSGフローログからの移行やVNetフローログの新規構築をご検討の際は、ぜひお気軽にご相談ください。お客様の環境に最適なクラウド運用をご提案いたします。
この記事を書いた人

- Azure支援デスク 管理者
- 双日テックイノベーション(旧:日商エレクトロニクス)特設サイト「Azure導入支援デスク」サイトマスターです。