NSG flow logs that duplicate an unfiltered virtual network flow log
What does ZopNight detect here?
Azure bills flow log collection per GB, so recording the same packets twice means paying twice. ZopNight flags an enabled NSG flow log when every virtual network its NSG governs is already covered by an unfiltered VNet flow log and the NSG has no NIC binding, then reports the NSG flow log's full cost as the saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1400 |
| Category | orphan |
| Severity | high |
| Metric | none — pure configuration read |
| Threshold | every governed VNet covered by an unfiltered VNet flow log |
| Source | ZopNight |
| Permissions used | Microsoft.Network/networkWatchers/flowLogs/read · Microsoft.Network/networkSecurityGroups/read |
Paying twice for the same packets
Network Watcher has two flow logging models. NSG flow logs attach to a network security group; virtual network flow logs attach to a whole network, subnet or NIC. Microsoft’s VNet flow logs overview recommends disabling NSG flow logs before enabling VNet flow logs on the same workloads, to avoid duplicate traffic recording and additional costs. Both kinds are billed per GB collected after the first 5 GB each month, per the Network Watcher pricing page, and traffic analytics adds a per-GB processing charge on top.
NSG flow logs are also on their way out: Microsoft retires them on September 30, 2027 and no longer allows new ones to be created. An NSG log left running beside a newer VNet log is pure overlap.
Finding overlapping logs
List the flow logs in a region with their targets. NSG logs point at a networkSecurityGroups
resource; VNet logs point at a virtualNetworks resource:
az network watcher flow-log list --location <region> \ --query "[].{name:name, enabled:enabled, target:targetResourceId}" -o table
az network nsg show --resource-group <rg> --name <nsg> \ --query "{subnets:subnets[].id, nics:networkInterfaces[].id}"If every subnet the NSG protects lives in a network that already has an enabled VNet flow log, the NSG log is redundant.
Three proofs before recommending a deletion
- Every network is covered. An NSG can protect subnets in more than one virtual network. Each one must have its own enabled VNet flow log; covering the first is not enough.
- The covering log is unfiltered. VNet flow logs can take filtering criteria that record only matching flows. A filtered log is not full coverage, and a log whose filter state is unknown does not count either.
- No NIC binding. If the NSG is attached to a network interface as well as subnets, that traffic is not accounted for by the network-level match, and the finding is withheld.
The NSG flow log itself must be enabled and must have a positive price.
Cases left alone
A disabled NSG flow log, an NSG with no known networks, or any coverage gap on a single network produces no finding. The goal is to never recommend deleting the only record of some traffic. Gateway subnet logs are a separate case, covered by Azure Flow Log on a Gateway Subnet.
The NSG flow log cost that disappears
saving = full monthly cost of the redundant NSG flow logcost after fix = 0Deleting the duplicate stops its collection, storage and analytics meters together.
Retiring the duplicate NSG flow log
- Confirm the covering VNet flow log is healthy and its data is arriving in the destination storage account.
- If traffic analytics ran on the NSG flow log, enable it on the VNet flow log too.
- Delete the NSG flow log:
az network watcher flow-log delete --location <region> --name <flow-log>. - Check for further NSG logs on the same workloads; one can exist at both the subnet and the NIC level.