How do you enable Azure network security group flow logs?

How Azure NSG Flow Logs fit into network visibility

Azure network security group flow logs are a packet metadata source, not a full payload capture. They tell you which flows were allowed or denied, which direction they moved, and which rules were involved, so they are useful for baselining, troubleshooting, and incident review. For an Azure-first reference point on how NSGs sit alongside broader cloud controls, Microsoft Azure Security Guide is the most direct internal companion.

Because the logs are generated from NSG enforcement points, the value depends on whether the NSG is attached to the right subnet or network interface and whether the Network Watcher region matches the resource region. If those do not line up, you can easily end up with a gap that looks like “no traffic” when the real problem is logging coverage.

What has to be in place before you switch it on

Enable flow logs through Azure Network Watcher in the same region as the NSG, then point the output to a storage account that your investigation workflow can actually read later. The storage target is part of the control, because the logs are only useful if they are retained, searchable, and protected against accidental deletion or overbroad access. If you need dashboards or summarized trends, turn on traffic analytics after the raw export is working.

Log delivery also depends on storage design choices. Keep retention long enough to support the kinds of investigations you expect, and make sure access to the storage account is limited to the people and systems that need it. If retention is too short or access is too loose, you may still have “enabled logging” on paper but lose the evidence you need when a question arises.

What to check when the logs do not look right

Most setup problems are configuration mismatches rather than product defects. Check the NSG association, the region used by Network Watcher, the storage account region and permissions, and whether traffic analytics is pointed at the same logging source you intended. If the environment spans several subscriptions or regions, verify that each NSG has been enabled deliberately instead of assuming a template or policy rollout covered everything.

For cloud logging and retention patterns that apply across Azure, AWS, and GCP, the Cloud Logging and Audit Trail Guide is useful because it treats audit logging as an operational evidence problem, not just a checkbox. That matters here because NSG flow logs are most valuable when they are treated as part of a broader audit trail, not a standalone feature.

When you want to move from raw flow data to detection and response, NDR Guide helps frame how flow logs support baseline building, anomaly detection, and SOC triage. That is the practical next step once the export path is stable.

Risk and Threat Considerations

Flow logs are often enabled for visibility, but the real risk is silent failure of evidence. If the wrong NSG is selected, the region is mismatched, or storage permissions are weak, teams may believe they have monitoring when they actually have a blind spot or a tamperable record.

Failure mechanism: A misaligned NSG or logging region prevents collection, while weak storage retention or access control allows evidence loss, overwriting, or unauthorized viewing.

Impact: Investigations lose source-of-truth network evidence, making it harder to reconstruct lateral movement, confirm rule behavior, or prove whether traffic was blocked or allowed.

Practitioner Guidance

What to verify: Confirm that the NSG you care about is the one producing the logs, that the storage account is in the expected region and subscription context, and that the retention setting matches your incident response window. If the environment is large, verify coverage per NSG rather than assuming a single enablement step applied everywhere.

What good looks like: A successful setup gives you consistent flow records, readable storage, and a clear handoff from raw logs to either ad hoc investigation or traffic analytics reporting. You should be able to explain where the logs are written, who can access them, and how long they remain available.

Practitioner takeaway: Treat NSG flow logs as an evidence pipeline, not a toggle, because the control only works when collection, retention, and access are all aligned.

Related resources from NHI Mgmt Group

• How do you detect Azure network security group changes?
• How should security teams simplify analysis of Azure Activity logs when OperationId and CorrelationId do not reliably group related events?
• How should security teams use network flow logs to spot anomalous traffic in a tailnet?
• How do you enable VCN flow logs in Oracle Cloud Infrastructure?