Azure NSG Flow Logs and VNet Flow Logs: Setup Guide

If you are currently using NSG Flow Logs, you need to know that they are being retired. New NSG Flow Log resources cannot be created after 30 June 2025, and the feature will be fully retired by 30 September 2027. The replacement is VNet Flow Logs, which captures everything NSG Flow Logs captured and more. If you are setting up network traffic monitoring for the first time, start with VNet Flow Logs directly. If you have existing NSG Flow Logs, plan the migration.

This guide covers both: what flow logs capture, how to set them up, what the transition from NSG to VNet Flow Logs looks like, and how to use the output for security investigation and compliance evidence.

What flow logs capture

Flow logs record Layer 4 IP traffic flowing through your Azure network. Each log entry contains: source and destination IP addresses, source and destination ports, protocol (TCP or UDP), traffic direction (inbound or outbound), the action taken (allow or deny), and volume information (bytes and packets in version 2 logs).

This is network forensics data. When something goes wrong, whether a breach investigation, an unexpected connection from an unfamiliar IP, or a compliance audit asking for evidence of network controls, flow logs are the record that answers the question "what actually traversed this network and was it allowed or blocked."

NSG Flow Logs associate with individual Network Security Groups. VNet Flow Logs associate with the virtual network or subnet itself, capturing traffic at a broader scope and including traffic that NSG Flow Logs miss in certain scenarios (such as traffic to network interfaces without an NSG attached).

Enable VNet Flow Logs

VNet Flow Logs require Azure Network Watcher to be enabled in the region where your VNet is deployed. Network Watcher is a regional service and must be present in every region you want to monitor.

Enable Network Watcher:

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations uksouth \
  --enabled true

Create a storage account for flow log storage. Flow logs are written to Azure Blob Storage in JSON format. The storage account should be in the same region as the VNet to avoid cross-region data transfer charges:

az storage account create \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --location uksouth \
  --sku Standard_LRS \
  --kind StorageV2

Enable VNet Flow Logs on a VNet:

In the Azure Portal, navigate to Network Watcher > Flow logs. Select Create, choose Virtual Network as the flow log type, and select the VNet you want to monitor. Specify the storage account and the retention period in days (set to at least 90 days; longer for regulated workloads).

Version 2 of the flow log format includes byte and packet counts per flow, which version 1 omits. Enable version 2 where available.

Enable Traffic Analytics if you want processed insights rather than raw JSON. Traffic Analytics uses Log Analytics to aggregate flow data, identify traffic patterns, flag anomalous traffic, and produce dashboards. It adds cost (both the Log Analytics ingestion and a Traffic Analytics processing charge) but significantly reduces the analytical burden.

Enable NSG Flow Logs (existing environments only)

If you are working with an existing environment that uses NSG Flow Logs and you are not ready to migrate immediately, the configuration follows the same pattern but attaches to NSGs rather than VNets:

az network watcher flow-log create \
  --resource-group myResourceGroup \
  --name myFlowLog \
  --nsg myNSG \
  --storage-account /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account} \
  --enabled true \
  --format JSON \
  --log-version 2 \
  --retention 90 \
  --traffic-analytics true \
  --workspace /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}

Migration path from NSG to VNet Flow Logs: create VNet Flow Logs on the same VNet where your NSGs are deployed, validate the output matches your expectations for a few weeks, then disable the NSG Flow Logs. Do not delete them until you have confirmed the VNet Flow Logs are capturing everything you need.

Read and query the output

Raw flow logs land in your storage account in a path structure: insights-logs-flowlogflowevent/resourceId=/SUBSCRIPTIONS/{subId}/RESOURCEGROUPS/{rg}/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/{nsg}/y={year}/m={month}/d={day}/h={hour}/m=00/macAddress={mac}/PT1H.json

Each hourly JSON file contains an array of flow records. For operational use, querying raw JSON files is impractical. Route to Log Analytics instead. Once in Log Analytics, the NTANetAnalytics and AzureNetworkAnalytics_CL tables (for Traffic Analytics) let you query with KQL.

Find all denied traffic in the last 24 hours:

AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where FlowStatus_s == "D"
| summarize count() by SrcIP_s, DestIP_s, DestPort_d
| order by count_ desc

Find traffic to a specific IP (useful during incident investigation):

AzureNetworkAnalytics_CL
| where TimeGenerated between (datetime(2025-01-01) .. datetime(2025-01-02))
| where SrcIP_s == "203.0.113.50" or DestIP_s == "203.0.113.50"
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowStatus_s, FlowDirection_s

For Security Operations Centres, flow logs can be routed to a SIEM via Event Hub. The architecture is: VNet Flow Logs > Log Analytics > Diagnostic Settings to Event Hub > SIEM connector. This works with Microsoft Sentinel, Splunk, and any SIEM that consumes Event Hub data.

Set up alerts on traffic anomalies

Traffic Analytics surfaces several pre-built anomaly signals: malicious traffic identified via Microsoft threat intelligence, unusual ports, and geo-location anomalies (traffic from unexpected countries). These appear in the Traffic Analytics dashboard and can be connected to Azure Monitor alerts.

For custom alerting on specific patterns, use scheduled query alerts in Azure Monitor that run KQL queries against your Log Analytics workspace on a defined cadence. A daily alert for any new outbound connections to public IPs that were not present the previous day is a useful baseline for detecting lateral movement or C2 activity.

Retention for regulated workloads

Flow log retention requirements vary by framework. FCA and PRA operational resilience guidance and PCI DSS both reference the need for detailed network audit trails, often for 12 months. UK GDPR does not specify a network log retention period, but the ability to investigate and evidence a personal data breach typically requires at least 6-12 months of network data.

Set retention in Log Analytics (under workspace settings) to match your longest applicable requirement. Storage-tier retention (raw JSON in blob) can be set separately and is cheaper for archival; Log Analytics retention is more expensive but queryable. A common pattern: 90 days in Log Analytics for operational use, 13 months in cold storage for compliance archival.

Where Critical Cloud comes in

Network visibility is foundational to both security operations and compliance evidence. Setting up VNet Flow Logs correctly, routing them to a queryable store with the right retention, and integrating them with observability and alerting that a team actually uses, is how we approach it for regulated businesses. As the world's first Powered by Datadog accredited partner, we surface network flow data alongside application and infrastructure signals in a single correlated view, so an anomalous connection is seen in context of what the application was doing at the same time. See how Critical Support works.