← All resources

Azure VNet Analytics: Tools, Flow Logs and Research Use

12 min read
Azure VNet Analytics: Tools, Flow Logs and Research Use

Azure VNet Analytics: Tools, Flow Logs and Research Use

Researcher comparing exported network flow tables

Azure VNet analytics is not one product. It is a stack: virtual network flow logs record the traffic, a Log Analytics workspace stores and queries it, Traffic Analytics summarizes it, and Network Insights shows topology and health. If you need to measure, explain or defend what happened on an Azure virtual network, you will likely use more than one layer. This guide shows which to pick, what it costs you in attention and budget, and how to make the final analysis reproducible.

We write this for researchers: PhD students, postdocs and lab engineers who run experiments, simulations or studies on Azure and need network data they can justify to a supervisor or reviewer.

Plotstudio
Make Network Analysis Reproducible
PlotStudio AI can plan, run, and document statistical analysis on exported network data, with code and results available for review.
Visit PlotStudio AI

TL;DR

  • Flow logs are the raw data. VNet flow logs record IP traffic through a virtual network. Traffic Analytics and your own queries sit on top of them.
  • Migrate now if you still use NSG flow logs. They retire on September 30, 2027, and new ones can no longer be created.
  • Network Insights is for orientation, Traffic Analytics is for investigation. Only the second gives you query-based traffic analysis.
  • Dashboards are not a method. For publishable work, export the data, state your assumptions and run documented statistics, ideally in code someone else can rerun.
  • PlotStudio AI adds the agentic analytics layer that plans, runs and documents the statistical work on exported network data, alongside R, Python and Jupyter.

Table of Contents

What “Azure VNet analytics” actually covers

Search results for this phrase mix several Microsoft services, which is why the topic feels muddled. Four pieces matter:

  1. Virtual network flow logs, a feature of Azure Network Watcher that logs IP traffic flowing through a virtual network. Flow data goes to Azure Storage, and from there you can export it to a visualization tool, SIEM or IDS, according to Microsoft’s overview.
  2. Traffic Analytics, a cloud-based solution that processes flow logs to show user and application activity, traffic patterns, top talkers, open ports and geographic distribution. It needs a Log Analytics workspace.
  3. Azure Monitor Network Insights, which gives a topology, health and metrics view of deployed network resources without configuration.
  4. Azure Virtual Network Manager, which centrally manages virtual networks and includes a network verifier for reachability testing. It is a configuration and verification tool, not a traffic analytics tool.

Knowing which question you are asking decides which layer you need.

Question Layer Output type
What does my network look like, and is it healthy? Network Insights Topology, health, metrics
Who talked to whom, how much, and when? VNet flow logs plus Traffic Analytics Aggregated flow records, dashboards
Why can resource A or B (not) reach each other? Virtual Network Manager network verifier Reachability analysis of configuration
Is traffic behavior different between conditions? Exported flow data plus statistical analysis Tests, models, effect sizes

The last row is the one no Azure dashboard answers for you. We come back to it below.

Flow logs: the data your analysis stands on

VNet flow logs work at Layer 4 of the OSI model and record all IP flows through a virtual network. Logs are collected at one-minute intervals, written as JSON, and do not affect your resources or network traffic.

For a research design, three details matter:

  • Scope. VNet flow logs capture traffic at the virtual network level instead of requiring configuration per NIC or subnet. Microsoft’s guidance also notes they carry virtual network encryption status and Virtual Network Manager security admin rule information that NSG flow logs omit.
  • Granularity. Flow logs are event-based records, which makes them suitable for forensic work and audit trails. Azure Monitor metrics are aggregated data points that suit real-time dashboards and alerting. Microsoft’s network monitoring design guide covers the distinction. Choose by the unit of analysis your study needs: a time series of counts, or individual flow tuples.
  • Cost. Virtual network flow logs are charged per gigabyte collected, with a free tier of 5 GB per month per subscription. If you enable Traffic Analytics, its pricing applies on top.

The NSG flow log deadline

If your lab inherited a setup built on NSG flow logs, plan the move. Microsoft states that NSG flow logs retire on September 30, 2027, that new ones can no longer be created, and that you should migrate to virtual network flow logs. Existing NSG flow log data in storage accounts stays accessible after retirement, but Traffic Analytics will no longer support NSG flow logs.

For longitudinal studies this creates a real methodological risk: a schema or scope change midway through data collection. Record the switch date in your methods notes and check whether the two log types define fields identically before you pool the data. Do not assume they do.

Traffic Analytics: what it gives you and what it does not

Traffic Analytics turns raw flow logs into something a human can read. It supports IntraVNet, InterVNet and site-to-site flow types, and surfaces traffic patterns, top talkers and open ports. It removes the need to write custom KQL for basic operational awareness.

Practical points before you switch it on:

  • It needs a Log Analytics workspace. It is a processing layer, not a standalone product.
  • Processing interval is a choice. When you create a VNet flow log with Traffic Analytics, you can pick every 1 hour or every 10 minutes, and the default is one hour. If your study needs near-real-time resolution, the default may be too coarse. Note the interval in your methods section either way, because it shapes every time-based figure you report.
  • Budget for it. Traffic Analytics is billed by data volume processed, per the Microsoft documentation. Check current rates in the Azure pricing calculator for your region before you commit grant money.

Querying with KQL

Dashboards are fine for orientation. For anything you will publish, query the workspace directly. Microsoft publishes the Traffic Analytics schema and aggregation rules and sample KQL queries. Saved queries are the closest thing the Azure side has to a reproducible method: anyone with workspace access can rerun the same text and get the same rows.

Read the schema page carefully. Traffic Analytics aggregates flows, so a row is not a single connection. Treating aggregated rows as independent observations is the sort of error a reviewer will catch.

Network Insights and the network verifier

Network Insights is the quick look. It shows topology across subscriptions, regions and resource groups through an interactive topology view, which is useful for a methods figure or for checking that the environment matches your design. Connectivity health depends on Connection Monitor, and detailed flow dashboards appear only after you explicitly enable Traffic Analytics, as Microsoft’s Network Insights page explains.

The Virtual Network Manager network verifier answers a different question. Where Traffic Analytics tells you what happened, the verifier tests whether two resources should be able to communicate under the current security and routing configuration. If a reviewer asks you to justify an isolation assumption, such as “the control workload could not reach the experimental subnet,” that is the kind of evidence to bring. See Microsoft’s network verifier concept page.

Observed network flows versus tested reachability

Where dashboards stop and statistics start

Suppose you run a distributed-systems experiment on Azure and want to know whether a new scheduling policy changed east-west traffic between subnets. Flow logs and Traffic Analytics give you bytes and flows per hour per pair of endpoints. They do not tell you:

  • whether the difference between conditions exceeds day-to-day variation
  • whether repeated measures on the same subnet pair need a mixed-effects model rather than a simple t-test
  • how you handled missingness when a log interval has no records
  • whether you corrected for multiple comparisons across dozens of endpoint pairs

That is analysis, not monitoring. A defensible workflow looks like this:

  1. Define the question and unit of analysis before touching data: flow, endpoint pair or time bin.
  2. Fix collection parameters and record them: flow log type, processing interval, workspace region, date range.
  3. Query with saved KQL and export the result as a table. Keep the query text with the data.
  4. Profile and clean: check duplicates, gaps, time zones and aggregation artifacts. Report exclusions.
  5. Choose the method and its assumptions (for example a mixed-effects model with endpoint pair as a random effect) and write them down before running.
  6. Run it as code, inspect intermediate output, and archive the script, outputs and figures together.

Steps 4 to 6 are where researchers who never trained as programmers lose weeks, and where a supervisor’s “I cannot reproduce your numbers” comes from.

Our perspective: an agentic layer on top of the tools you already use

We build PlotStudio AI, and we do not think it replaces anything in a researcher’s stack. R, Python, Stata, SPSS, SAS, RStudio and Jupyter provide statistical computing. Azure provides the telemetry. What has been missing is a layer that can take a question, plan the investigation, execute it, check its own intermediate results and document the whole thing. We call that agentic analytics for researchers.

Three things matter to us for network data like this:

  • Review before execution. With Plan Mode, you can read and modify the proposed approach, including methods, assumptions and steps, before anything runs. For a flow-log study, that is where you catch an inappropriate independence assumption.
  • Real code, not one-shot answers. PlotStudio AI writes and runs actual code and keeps methodology, code, statistics, charts and results available for review, so a supervisor can inspect how a number was produced.
  • Local execution. Analyses can run on your own machine. Flow logs can reveal internal addressing and usage patterns, and if your study touches human participants or special-category data, keeping the dataset off conventional cloud analytics platforms simplifies your data protection story.

A chat tool that answers “what were my top talkers?” is useful for a minute. A research workflow needs the plan, the code and the audit trail. That is the gap we designed for.

— Aymen

Using PlotStudio AI on exported flow data

Once your KQL results are exported as a table, the workflow is straightforward: connect the file, state the objective (for example, compare hourly inter-subnet byte volume between two scheduling policies, accounting for repeated measures), review the plan, and let the agents execute. Completed work is preserved as a searchable Analysis Page and can be exported as a notebook or PDF report. If your group has fixed conventions, Skills let you encode required procedures and reporting expectations so the analysis follows them.

We stay honest about scope: PlotStudio AI analyzes tabular data you bring to it. Collecting and querying flow logs remains an Azure job. For other data types, our guides on local AI data interpretation and Excel analysis with timestamped plans show the same plan-run-document pattern, and the AI for academic research guide covers the wider toolkit. If your institution wants a managed deployment on Azure, see our enterprise Azure deployment guide.

Using PlotStudio AI on exported flow data — overview diagram

Trying it: plans and pricing

There is a Free Trial on the pricing page, which is the lowest-risk way to test it on a real export. Paid options are Managed Credits at 69.99 USD per month, and Bring Your Own Key at 39.99 USD per month. Researchers can also take Bring Your Own Key at 399.90 USD per year through the academic page. Organizations evaluating a managed rollout can look at the enterprise page, which lists a one-off pilot fee of 500 USD.

A short checklist before you collect data

  • Use VNet flow logs, not NSG flow logs, for anything that will run past September 2027.
  • Record the flow log type, processing interval, workspace and date range in your protocol.
  • Estimate gigabytes per month and price both flow log collection and Traffic Analytics processing.
  • Save every KQL query next to the exported data.
  • Decide your statistical model and assumptions before running them, and review the plan.
  • Archive code, outputs and figures together so the analysis can be rerun.

FAQ

Is Azure Traffic Analytics the same as Network Insights?

No. Network Insights gives a no-configuration view of topology, health and metrics. Traffic Analytics must be enabled explicitly and processes flow logs to give query-based insight into traffic patterns. Many projects use both.

Does Traffic Analytics have a free tier?

Microsoft’s documentation describes Traffic Analytics as billed by data processed and does not describe a free tier for it. Flow logs themselves include a free allowance of 5 GB per month per subscription. Check current regional rates before budgeting.

What happens to my NSG flow log data after September 30, 2027?

Existing data in your storage accounts remains accessible, according to Microsoft. However, the feature retires and Traffic Analytics will no longer support NSG flow logs. Migrate to VNet flow logs well before then.

Can I run statistical tests inside Azure’s analytics tools?

Traffic Analytics and KQL are built for aggregation, visualization and alerting, not for formal inference such as mixed-effects models or multiple-comparison corrections. For that, export the data and analyze it in R, Python or a tool such as PlotStudio AI that records the method and code.

Sources