6.1.3. Flow Logs and Diagnostics

Virtual network flow logs are the current mechanism, and the objective domain now names them specifically. You enable logging once at the virtual network level and every supported workload inside it is covered.

Each record carries:

• the network interface the flow applies to
• the 5-tuple — source and destination IP, source and destination port, protocol
• flow direction (inbound or outbound) and flow state (begin, continuing, end, deny)
• the encryption status of the flow
• packet and byte counts in both directions
• the rule that allowed or denied it — either an NSG rule or an Azure Virtual Network Manager security admin rule

Destination: logs are written to a standard Azure Storage account in the same region as the virtual network. Premium storage accounts are not supported. Storage is the only required destination — everything downstream of it is optional.

Traffic Analytics is that optional layer. It processes the raw logs into a Log Analytics workspace and turns them into top talkers, traffic patterns over time, blocked-traffic analysis and geo-location of flows.

NSG flow logs are the predecessor. They attach to a network security group rather than to a virtual network, which creates the two problems VNet flow logs exist to solve — traffic with no NSG in its path is never seen, and you end up enabling logging at both subnet and NIC level to get full coverage.

⚠️ Exam Trap: Do not run both on the same workload. Microsoft's guidance is to disable NSG flow logs before enabling virtual network flow logs, because the two together produce duplicate records and duplicate cost.

IP Flow Verify: Test if a specific flow would be allowed:

Test: Can 10.0.1.5 reach 10.0.2.10 on TCP 443?
Result: Allowed by rule "AllowHTTPS" in NSG "web-nsg"