how to know where the network out total egress data has gone?

Question

how to know where the network out total egress data has gone?

Nivedita 20

We have configured Azure VNet Flow Logs with Traffic Analytics and receive an Azure Monitor alert when a VM's Network Out exceeds 10 GB within 6 hours.

Our requirement is to quickly identify the top egress destination IPs and bytes transferred for the alert period.

We found that NTANetAnalytics provides only aggregated data, AzureDiagnostics does not contain the required flow details, and the raw Storage Account flow logs require manual parsing.

Is there a native Azure feature, Log Analytics table, or KQL query that can show the top egress destination IPs and traffic volume for a VM during a specified time window without manually parsing the raw flow logs?

0 comments

Answer accepted by question author

Jose Benjamin Solis Nolasco 10,891 Volunteer Moderator

Welcome to Microsoft Q&A,

Hello @Nivedita I hope you are doing well,

If your VNet Flow Logs are being ingested into Log Analytics, first check whether tables such as AzureNetworkAnalytics_CL or NetworkWatcherFlowEvent are available. If they are, you can use a KQL query to filter the alert time window and your VM's source IP, then summarize the total bytes by destination IP to identify the top egress destinations.

If those tables are not available, Azure does not currently provide a native Log Analytics table with per-flow details. In that case, the raw VNet Flow Logs stored in the Storage Account (or a custom ingestion pipeline into Log Analytics) are required to perform this analysis.

but there isnt a native way in azure in this moment...

References:

Virtual Network Flow Logs: https://learn.microsoft.com/azure/network-watcher/vnet-flow-logs-overview
Traffic Analytics: https://learn.microsoft.com/azure/network-watcher/traffic-analytics
Network Watcher logs: https://learn.microsoft.com/azure/network-watcher/network-watcher-monitoring-overview

If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.

Nivedita 20 Reputation points

2026-08-05T15:54:24.58+00:00

Thanks @Jose Benjamin Solis Nolasco . but feel let down ..despite having Azure Monitor alerts, VNet Flow Logs, and Traffic Analytics enabled, we are still unable to determine where the outbound data went during the spike.

Our current environment has multiple VMs in a VNet, no Azure Firewall.what is the recommended Azure-native approach to investigate unexpected outbound traffic?
Jose Benjamin Solis Nolasco 10,891 Reputation points Volunteer Moderator

2026-08-05T18:22:28.7666667+00:00
Since you don't have Azure Firewall (which would give you FQDN-level logging via Firewall logs), your best native path is NSG Flow Logs v2 + Traffic Analytics, but you need to query the underlying data correctly

Traffic Analytics' built-in workbooks only show aggregated/top-N views on a delay (usually 10-min processing interval), which often isn't granular enough for a spike investigation, that's why there is not a Azure Native approach to investigate unexpected outbound traffic because is probably you wont catch those spike...

However try this it might work for you:

Step 1

Confirm you're on Flow Logs v2, not v1. v1 doesn't include byte/packet counters per flow, so top-talkers analysis is impossible. v2 adds flowState and byte/packet counts per direction.

Step 2

Query AzureNetworkAnalytics_CL directly (this is the table Traffic Analytics writes to before building its workbooks):

kql

AzureNetworkAnalytics_CL |

If AzureNetworkAnalytics_CL isn't populated (some tenants only get it with Traffic Analytics fully processed), fall back to raw flow logs already in Blob Storage and query them via Log Analytics using externaldata() or ingest them with Azure Data Explorer / Synapse for ad-hoc KQL this avoids "manual parsing" in the sense of scripting, since KQL can read JSON directly from the storage blobs.

Last step.....

Step 3

Correlate with NSG Flow Logs at the NIC/subnet level, not just VNet level, if you have multiple VMs this narrows down which VM's NIC actually generated the spike before you filter by destination.

Practical recommendation for ongoing visibility: since you lack Azure Firewall, consider enabling Azure Firewall Basic or a NAT Gateway with Flow Logs on the egress path this gives you FQDN-based logging, which is far easier to correlate with "where did the data go" than raw IP-only NSG flow logs, especially for cloud/CDN destinations where the IP alone won't tell you the actual service (S3, Akamai, etc.).

KQL is powerfull enough to give you some insight I hope this help a little bit to norrow down your spikes..
Jose Benjamin Solis Nolasco 10,891 Reputation points Volunteer Moderator

2026-08-10T00:17:24.1433333+00:00

@Nivedita Just following up, Do you need more guidance or assistance ?
Nivedita 20 Reputation points

2026-08-10T00:22:59.9166667+00:00

Thank you @Jose Benjamin Solis Nolasco . Unfortunately, both the options you suggested are outside the budget for a small startup like us, so we won't be able to proceed with them for now. We'll continue using Traffic Analytics with VNet Flow Logs to get some visibility into and monitor egress traffic as much as possible.
Jose Benjamin Solis Nolasco 10,891 Reputation points Volunteer Moderator

2026-08-10T00:31:35.5766667+00:00

@Nivedita Thanks for let us know, I hope this proceedure help you in the future.

""Please do not forget to "Accept the answer” and upvote it wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others""

1 additional answer

Your answer

Nivedita 20 Reputation points

2026-08-05T15:54:24.58+00:00

Thanks @Jose Benjamin Solis Nolasco . but feel let down ..despite having Azure Monitor alerts, VNet Flow Logs, and Traffic Analytics enabled, we are still unable to determine where the outbound data went during the spike.

Our current environment has multiple VMs in a VNet, no Azure Firewall.what is the recommended Azure-native approach to investigate unexpected outbound traffic?
Jose Benjamin Solis Nolasco 10,891 Reputation points Volunteer Moderator

2026-08-10T00:17:24.1433333+00:00

@Nivedita Just following up, Do you need more guidance or assistance ?
Nivedita 20 Reputation points

2026-08-10T00:22:59.9166667+00:00

Thank you @Jose Benjamin Solis Nolasco . Unfortunately, both the options you suggested are outside the budget for a small startup like us, so we won't be able to proceed with them for now. We'll continue using Traffic Analytics with VNet Flow Logs to get some visibility into and monitor egress traffic as much as possible.
Jose Benjamin Solis Nolasco 10,891 Reputation points Volunteer Moderator

2026-08-10T00:31:35.5766667+00:00

@Nivedita Thanks for let us know, I hope this proceedure help you in the future.

""Please do not forget to "Accept the answer” and upvote it wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others""

Answer 1

Yes. The native option is to query the NTANetAnalytics table in the Log Analytics workspace used by Traffic Analytics.

NTANetAnalytics contains aggregated flow log data with enhanced network analytics information, including fields such as source and destination IPs, bytes, protocol, ports, and time fields. Traffic analytics is designed for analyzing traffic patterns, troubleshooting connectivity, and identifying top communicating endpoints.

For a VM and alert time window, use a query like this to get the top egress destinations by total bytes:

NTANetAnalytics
| where TimeGenerated between (datetime(2024-01-01T00:00:00Z) .. datetime(2024-01-01T06:00:00Z))
| where SrcIP == "<VM private IP>"
| summarize TotalBytes=sum(BytesSrcToDest), FlowCount=count() by DestIP, DestPort, L4Protocol
| order by TotalBytes desc

If the traffic is going through an Azure Load Balancer, NTANetAnalytics can also be filtered by DestLoadBalancer:

NTANetAnalytics
| where DestLoadBalancer == '<Subscription ID>/<Resource Group name>/<Load Balancer name>'

Important limitations from the available documentation:

NTANetAnalytics is aggregated data, not per-packet or raw-flow detail.
Traffic analytics aggregates flows that share the same source IP, destination IP, destination port, NSG name, NSG rule, flow direction, and protocol.
Source port is excluded from aggregation.
In Azure Monitor logs, only the reduced aggregated record is shown.
To see all individual flows, the documented method is to use the blob_id field and inspect the raw flow log blobs in storage.
Traffic analytics ingestion can take up to 1 hour.

So, for the requirement of quickly identifying top egress destination IPs and bytes transferred during an alert window, the native Azure answer is NTANetAnalytics with KQL. If exact non-aggregated per-flow records are required, the documented path is still the raw storage blobs referenced by blob_id.

References: