NSG flow logs that must move to virtual network flow logs before 30 September 2027
What does ZopNight detect here?
ZopNight flags every flow log whose target is a network security group, because Azure retires NSG flow logs on 30 September 2027 and already blocks creating new ones. After that date Azure deletes the NSG flow log resources and ends traffic analytics on them. The replacement is a virtual network flow log; ZopNight prices no saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1404 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | flow log target is an NSG |
| Source | ZopNight |
| Permissions used | Microsoft.Network/networkWatchers/flowLogs/read |
Azure is retiring NSG flow logs on a fixed date
Network Watcher’s NSG flow logs overview sets the timeline: NSG flow logs retire on 30 September 2027, and because the feature is retiring, new NSG flow logs can no longer be created. After the retirement date Azure stops supporting traffic analytics on NSG flow logs and deletes the existing NSG flow log resources in your subscription.
The successor is the virtual network flow log, which can target a virtual network, a subnet or a network interface. Microsoft also recommends it for VMs with heavy network traffic, where NSG flow logging can fail.
Listing NSG flow logs per region
Flow logs belong to the Network Watcher of each region, so run this for every region you use:
az network watcher flow-log list --location eastus \ --query "[?contains(targetResourceId, 'networkSecurityGroups')].{name:name, target:targetResourceId, enabled:enabled}" \ -o tableRows whose target is a networkSecurityGroups resource are the ones to migrate.
The only condition: an NSG target
ZopNight reads the target of each flow log and fires when it is a network security group. Unlike the cost-driven flow log checks, it does not require the log to be enabled: Azure deletes the resource on the retirement date whether or not it is logging, so the migration is due in either case. There are no metrics, prices or windows involved.
Flow logs that are not flagged
Virtual network flow logs are never flagged; they are the destination of the migration. If ZopNight cannot tell what a flow log targets, it raises nothing, since guessing “NSG” would flag the very virtual network flow logs you migrated to.
A deadline, and a volume effect ZopNight does not price
The finding carries no saving. Migration can reduce log volume, because one virtual network flow log can replace NSG flow logs set at both subnet and network-interface level on the same traffic, but how much depends on your layout, so ZopNight does not estimate it. Traffic analytics on virtual network flow logs is charged per GB processed, and log storage is billed separately. Where two logs already record the same packets, see Azure Duplicate Flow Logging.
Migrating before the deadline
- In Network Watcher, open Migrate flow logs, pick subscriptions and regions, and download the migration script and config file, as described in Migrate to virtual network flow logs.
- Or create the replacement yourself, for example
az network watcher flow-log create --location eastus --resource-group my-rg --name vnet-flowlog --vnet my-vnet --storage-account mystorage. - Confirm flow records arrive, and repoint traffic analytics at the new log.
- Disable or delete the NSG flow log. Microsoft recommends disabling NSG flow logs on the same workloads before enabling virtual network flow logs, to avoid duplicate logging and cost.