Flow logs on a GatewaySubnet whose network already has an unfiltered VNet flow log
What does ZopNight detect here?
A flow log attached to the `GatewaySubnet` records the traffic crossing a VPN or ExpressRoute gateway, and for ExpressRoute it misses outbound VM-to-circuit flows. ZopNight flags such a log only when an unfiltered virtual network flow log already covers the same network, and reports the gateway subnet log's full cost as the saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1402 |
| Category | orphan |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | covering unfiltered VNet flow log exists |
| Source | ZopNight |
| Permissions used | Microsoft.Network/networkWatchers/flowLogs/read · Microsoft.Network/virtualNetworks/read |
Why gateway subnet logging is expensive and incomplete
Traffic that enters or leaves a network through its VPN or ExpressRoute gateway passes through the
GatewaySubnet, so a log there collects all of it, and flow logs are billed per GB collected.
It also has a documented blind spot. Microsoft’s
VNet flow logs overview
states that outbound flows from VMs to an ExpressRoute circuit are not recorded when flow logging
is enabled on the ExpressRoute gateway subnet, and that with FastPath enabled traffic bypasses the
gateway and is not recorded there either. Those flows must be recorded at the VM’s subnet or NIC.
The same GatewaySubnet name is used for VPN gateways, so the FastPath point applies only when the
gateway is ExpressRoute. The cost argument applies to both.
Spotting gateway subnet logs
az network watcher flow-log list --location <region> \ --query "[?contains(targetResourceId, 'GatewaySubnet')].{name:name, enabled:enabled, target:targetResourceId}" \ -o tableFor each result, strip the /subnets/GatewaySubnet suffix from the target to get the owning virtual
network, and check whether that network has its own enabled flow log.
The redundancy test ZopNight applies
- The flow log is enabled and its target is a gateway subnet.
- The owning virtual network is derived from the subnet’s resource ID.
- Another enabled flow log targets that virtual network as a whole.
- That covering log is proven to have no filtering criteria, since a filtered log records only matching flows and is not full coverage.
- The gateway subnet log has a positive price.
When it stays quiet
If no network-level log covers the network, there is no finding, even though the gateway subnet log may still be poor value. Moving collection to the VM subnets is not automatically a saving: you would pay to collect those same flows somewhere else, and the net change is unknown. Only proven redundancy makes the whole figure defensible. NSG-level duplicates are handled by Azure Duplicate Flow Logging.
What removing it recovers
saving = full monthly cost of the gateway subnet flow logcost after fix = 0The network-level log keeps recording every subnet and interface in the network, gateway traffic included, so no visibility is lost.
Consolidating onto the network-level log
- Confirm the covering VNet flow log is healthy and delivering data to its storage account.
- If traffic analytics was enabled on the gateway subnet log, enable it on the network-level log.
- Delete the gateway subnet log:
az network watcher flow-log delete --location <region> --name <flow-log>. - If gateway traffic must be audited separately, capture it at the VM subnets or NICs rather than on the gateway subnet, as Microsoft advises for ExpressRoute.