NSG flow logs are records of traffic decisions made by Azure network security groups. They show whether flows were allowed or denied, which rule was involved, and where the traffic was headed. In 2026 they are a legacy operational signal: existing logs still matter for investigations, but new NSG flow logs can no longer be created. A learner should understand them as historical evidence and a migration concern, not as the preferred design for new network logging.
NSG flow logs are Azure Network Watcher records that capture allowed and denied traffic through network security group rules. Microsoft has retired new NSG flow log creation and directs teams to migrate existing logging to virtual network flow logs before the September 30, 2027 retirement date.
Technically, NSG flow logs sit in the Azure networking and observability layer. They are produced through Network Watcher, tied to network security groups, and commonly stored in a storage account with optional traffic analytics in Log Analytics. They observe control decisions around virtual network traffic, but they do not replace packet capture, firewall logs, or application telemetry. Because Microsoft is moving customers to virtual network flow logs, operators should treat NSG flow logs as legacy diagnostic resources that require inventory and migration planning.
Why it matters
NSG flow logs matter because network incidents often begin with a simple question: did Azure allow this packet path or block it? Flow data helps security, platform, and application teams prove whether an NSG rule participated in a failure, exposure, or unexpected connection. The retirement timeline raises the stakes. Teams that ignore existing NSG flow logs may lose familiar investigations, traffic analytics views, storage paths, and compliance evidence when the feature is removed. The practical value is not just historical logging; it is knowing where legacy diagnostics still exist, which workloads depend on them, and how to move evidence collection to virtual network flow logs without creating blind spots.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In Network Watcher, existing NSG flow log resources appear with status, target network security group, storage account, retention, traffic analytics workspace, and region details for migration review.
Signal 02
In Log Analytics or traffic analytics workbooks, the term appears when analysts query allowed and denied flows, top talkers, blocked ports, and rule-level network behavior.
Signal 03
In Azure CLI inventory output, resource lists expose Microsoft.Network networkWatchers flowLogs entries, connected storage IDs, workspace references, provisioning state, and timestamps used for audit evidence.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Inventory legacy network flow evidence before migration to virtual network flow logs.
Investigate allowed and denied traffic decisions involving network security groups.
Preserve historical network evidence for compliance and incident response.
Compare storage, workspace, and dashboard dependencies before retirement.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Migrating public-sector network evidence before retirement
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
HarborWorks, a municipal public works agency, used legacy NSG flow logs to investigate traffic between field-service applications and a water-sensor platform. The networking team needed migration before the retirement date without losing audit evidence.
🎯Business/Technical Objectives
Inventory every active NSG flow log across six subscriptions.
Preserve one year of investigation history during migration.
Rebuild traffic analytics dashboards around the replacement signal.
Reduce connectivity triage time for field-service incidents.
✅Solution Using NSG flow logs
The platform group used NSG flow logs as the starting inventory for the migration. Azure CLI listed Network Watcher flow log resources, target NSGs, storage accounts, retention settings, and connected Log Analytics workspaces. Each record was mapped to the virtual network, application owner, and workbook that depended on it. The team then configured virtual network flow logs for the same traffic boundaries, routed data to a governed workspace, and updated Kusto queries to compare allowed and denied flows by source subnet, destination port, and rule outcome. Storage lifecycle rules kept historical NSG files for compliance while new dashboards used the replacement flow logs. Before closing the change, operators replayed three prior incidents and confirmed the new queries answered the same questions.
📈Results & Business Impact
All 42 legacy flow log resources were inventoried and assigned owners.
Dashboard migration finished 11 months before the retirement deadline.
Average network triage time dropped from 75 minutes to 38 minutes.
Compliance retained historical storage evidence without keeping duplicate live logging.
💡Key Takeaway for Glossary Readers
NSG flow logs are still valuable when they guide a disciplined migration from legacy evidence to current network observability.
Case study 02
Proving segmentation for an industrial control network
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
AstraForge operated robotic assembly lines connected to analytics services in Azure. Security reviewers needed proof that engineering workstations could not reach production control endpoints except through approved jump paths.
🎯Business/Technical Objectives
Validate denied traffic evidence for restricted control subnets.
Identify any unexpected allowed flows before audit signoff.
Move future monitoring to virtual network flow logs.
Keep plant operations dashboards understandable for nonnetwork engineers.
✅Solution Using NSG flow logs
The network team reviewed existing NSG flow logs for subnets that protected control-data collectors. They used storage exports and Log Analytics queries to separate denied inbound attempts, allowed maintenance sessions, and traffic that bypassed the expected service port. One outdated rule allowed a diagnostic VM to reach collectors directly, so the team removed the exception and verified the next flow log window showed denial. After that, they configured virtual network flow logs for the virtual networks, rebuilt workbook panels with plain labels, and added an alert when denied attempts rose above the historical baseline. The security group kept NSG flow log archives as audit history but documented that all new operational monitoring would use the replacement dataset.
📈Results & Business Impact
One unauthorized diagnostic path was removed before the audit window.
Denied-flow evidence covered 100% of reviewed restricted subnets.
Workbook readers reduced false escalations by 30% after label cleanup.
Future monitoring shifted away from the retiring NSG-only signal.
💡Key Takeaway for Glossary Readers
NSG flow logs help prove network intent, but operators should translate that proof into a supported logging model before relying on it.
Case study 03
Cleaning up duplicate flow logging for a gaming platform
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Northstar Play ran multiplayer back-end services across several virtual networks and had inherited NSG flow logs, firewall logs, and appliance logs. Incident responders complained about noisy, conflicting network evidence.
🎯Business/Technical Objectives
Find duplicate network logging streams for production game services.
Cut unnecessary storage and analytics cost without losing investigations.
Prepare a retirement-safe replacement for NSG flow logs.
Standardize queries for blocked matchmaking traffic.
✅Solution Using NSG flow logs
Platform engineers started with NSG flow logs because they were the oldest and least consistently owned diagnostic source. CLI inventory identified storage accounts with high retention, flow logs attached to deleted application boundaries, and workbooks that no one opened during incidents. The team compared one month of blocked traffic findings against Azure Firewall logs and new virtual network flow logs. Where signals overlapped, they shortened NSG archive retention and retired stale workbooks. For active game-service networks, they moved investigation queries to virtual network flow logs and kept firewall logs for perimeter decisions. A runbook now explains which dataset to use for matchmaker latency, blocked ports, or suspected lateral movement.
📈Results & Business Impact
Network logging storage fell by 24% after stale NSG archives were reduced.
Responders removed four duplicate dashboards from the incident process.
Blocked matchmaking investigations used one approved query set.
The team completed migration planning before new seasonal traffic launched.
💡Key Takeaway for Glossary Readers
NSG flow logs can expose useful history, but cost and clarity improve when teams retire duplicate legacy signals deliberately.
Why use Azure CLI for this?
Azure CLI is useful because NSG flow log work is usually an inventory, evidence, and migration problem across many subscriptions. Portal views are fine for one NSG, but CLI can list existing flow log resources, export JSON, compare regions, capture storage and workspace IDs, and feed migration scripts. It also helps prove that no new design depends on a retired capability.
CLI use cases
Inventory existing Network Watcher flow log resources by subscription and resource group before planning virtual network flow log migration.
Show a specific flow log resource and capture its target NSG, storage account, retention, traffic analytics, workspace, and provisioning state.
Export flow log configuration to JSON so security, networking, and compliance teams can map each legacy signal to a replacement.
Compare NSG, virtual network, and workspace locations to find unsupported or risky logging paths before an incident response exercise.
Before you run CLI
Confirm the tenant, subscription, resource group, Network Watcher region, target NSG, storage account, and Log Analytics workspace before collecting evidence.
Use read-only commands first, because delete or update actions can remove diagnostic evidence and disrupt compliance reporting.
Check whether provider registration for Microsoft.Network exists and whether your account has Network Contributor, Reader, or monitoring permissions at the right scope.
Choose JSON output for automation and table output for human review; include timestamps because retirement and migration status are time-sensitive.
What output tells you
The resource ID shows which Network Watcher region owns the flow log and which subscription and resource group must be included in migration planning.
The targetResourceId identifies the NSG being observed, while storageId and workspaceResourceId show where evidence is written or analyzed.
Provisioning state, enabled flags, retention days, and traffic analytics settings tell operators whether logging is active, stale, partial, or ready to migrate.
Timestamps and policy details help auditors confirm whether the environment still depends on NSG flow logs after new creation was retired.
Mapped Azure CLI commands
Term-specific Azure CLI evidence workflow
direct
az network watcher flow-log list --location <region>
az network watcher flow-logdiscoverNetworking
az network watcher flow-log show --location <region> --name <flow-log-name>
az network watcher flow-logdiscoverNetworking
az resource show --ids <flow-log-resource-id>
az resourcediscoverNetworking
az network watcher list --output table
az network watcherdiscoverNetworking
Architecture context
Technically, NSG flow logs sit in the Azure networking and observability layer. They are produced through Network Watcher, tied to network security groups, and commonly stored in a storage account with optional traffic analytics in Log Analytics. They observe control decisions around virtual network traffic, but they do not replace packet capture, firewall logs, or application telemetry. Because Microsoft is moving customers to virtual network flow logs, operators should treat NSG flow logs as legacy diagnostic resources that require inventory and migration planning.
Security
Security value is direct because NSG flow logs expose patterns that can confirm segmentation, detect unexpected inbound attempts, and support investigations after a suspicious connection. They do not enforce policy themselves; the NSG rules enforce the decision, and the log records the result. Risk appears when teams mistake missing logs for safe traffic, retain raw log files without access controls, or keep using a retiring signal as the only network evidence source. Storage accounts that hold flow logs need least-privilege access, private networking where appropriate, encryption, lifecycle rules, and monitoring. Migration plans should preserve security evidence, map old NSG views to virtual network flow logs, and confirm that alerting still covers blocked and allowed flows.
Cost
Cost impact comes from storage, analytics ingestion, retention, and operational effort. Flow logs can generate large files for busy networks, and traffic analytics can add Log Analytics ingestion and query cost. Long retention may be justified for compliance, but keeping every flow record forever can become expensive and noisy. Retirement adds migration cost: teams must inventory existing settings, create virtual network flow log replacements, update dashboards, and retrain responders. FinOps owners should review storage lifecycle rules, workspace ingestion volumes, data export needs, and duplicate logging with firewalls or network appliances. The cheapest design is not always the best; the right design keeps enough evidence to investigate incidents without paying for unused legacy data.
Reliability
Reliability impact is diagnostic rather than runtime. Turning NSG flow logging on or off does not usually make an application faster or more available, but losing the signal can slow outage recovery and increase the blast radius of troubleshooting mistakes. During a connectivity incident, flow logs help operators separate routing, DNS, firewall, load balancer, and NSG causes. The retirement path creates reliability risk if runbooks, workbooks, or alerts still assume NSG flow logs are available. Reliable operations require a migration inventory, tested virtual network flow log replacement, validated storage retention, and incident drills that prove teams can still answer which traffic was allowed, denied, or missing.
Performance
NSG flow logs have indirect performance impact. They are not a packet forwarding accelerator and usually do not affect application latency directly, but they improve diagnostic speed when traffic is slow, blocked, or asymmetric. Query performance matters when log volume is high: poorly scoped Log Analytics searches or large storage downloads can make investigations sluggish. Operators should filter by time range, NSG, rule, source, destination, port, and direction instead of searching entire retention windows. Migration to virtual network flow logs can also improve operational performance if dashboards are redesigned around current schemas. The goal is faster isolation of network symptoms, not more log collection for its own sake.
Operations
Operators inspect NSG flow logs through Network Watcher, storage containers, traffic analytics, Log Analytics workbooks, and Azure CLI inventory commands. Day-to-day work includes finding existing flow log resources, confirming retention settings, checking storage account access, validating that traffic analytics still receives data, and documenting migration status. Because new NSG flow logs are no longer created, change workflows should flag any request that tries to add them to a new network. Good runbooks include the NSG name, subscription, region, Network Watcher resource, destination storage account, workspace, retention period, owner, migration target, and the exact Kusto queries or storage paths used during incidents.
Common mistakes
Designing a new network diagnostics plan around NSG flow logs even though new flow log creation has already been retired.
Assuming disabled or missing flow logs prove traffic was not attempted, instead of checking virtual network flow logs, firewalls, packet capture, and application telemetry.
Leaving log storage accounts broadly accessible, which turns useful network evidence into sensitive metadata available to too many operators.
Migrating dashboards without validating query schemas, causing incident responders to trust empty charts during a production connectivity outage.