Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Recommended Outbound Connectivity

StandardV2 NAT Gateway is the next evolution of outbound connectivity in Azure. As the recommended solution for providing secure, reliable outbound Internet access, NAT Gateway continues to be the default choice for modern Azure deployments. With the highly anticipated general availability of the new StandardV2 SKU, customers gain access to the following highly requested upgrades:

• Zone-redundancy: Automatically maintains outbound connectivity during single‑zone failures in AZ-enabled regions.
• Enhanced performance: Up to 100 Gbps of throughput and 10 million packets per second - double the Standard SKU capacity.
• Dual-stack support: Attach up to 16 IPv6 and 16 IPv4 public IP addresses for future ready connectivity.
• Flow logs: Access historical logs of connections being established through your NAT gateway.

This blog will focus on how enabling StandardV2 NAT Gateway flow logs can be beneficial for your team along with some tips to get the most out of the data.

What are flow logs?

StandardV2 NAT Gateway flow logs are enabled through Diagnostic settings on your NAT gateway resource where the log data can be sent to Log Analytics, a storage account, or Event hub destination. “NatGatewayFlowlogV1” is the released log category, and it provides IP level information on traffic flowing through your StandardV2 NAT gateway.

Enable NATGateway Flow Logs through Diagnostics setting on your StandardV2 NAT gateway resource.

Schema output as seen on Log Analytics for a NAT gateway traffic flow.

Why should I use flow logs?

Security and compliance visibility

Prior to NAT gateway flow logs, customers could not see NAT gateway information when their virtual machines connect outbound. This made it difficult to:

• Validate that only approved destinations were being accessed
• Audit suspicious or unexpected outbound patterns
• Satisfy compliance requirements that mandate traffic recording

Flow logs now provide visibility to the source IP -> NAT gateway outbound IP -> destination IP, along with details on sent/dropped packets and bytes.

Usage analytics

Flow logs allow you to answer usage questions such as:

• Which VMs are generating the most outbound requests?
• Which destinations receive the most traffic?
• Is throughput growth caused by a specific workload pattern?

This level of insight is especially useful when debugging unexpected throughput increases, billing spikes, and connection bottlenecks.

To note: Flow logs only capture established connections. This means the TCP 3‑way handshake (SYN → SYN/ACK → ACK) or the UDP ephemeral session setup must complete. If a connection never establishes, for example due to NSG denial, routing mismatch, or SNAT exhaustion, it will not appear in flow logs.

Workflow of troubleshooting with flow logs

Let's walk through how you can leverage flow logs to troubleshoot a scenario where you are seeing intermittent connection drops.

Scenario: You have VMs that use a StandardV2 NAT gateway to reach the Internet. However, your VMs intermittently fail to reach github.com.

Step 1: Check NAT gateway health

Start with the datapath availability metric, which reflects the NAT gateway's overall health.

• If metric > 90%, this confirms NAT gateway is healthy and is working as expected to send outbound traffic to the internet. Continue to Step 2.
• If metric is lower, visit Troubleshoot Azure NAT Gateway connectivity - Azure NAT Gateway | Microsoft Learn for troubleshooting tips.

Step 2: Enable StandardV2 NAT Gateway Flow Logs

To further investigate the root cause, Enable StandardV2 NAT Gateway Flow Logs (NatGatewayFlowLogsV1 log category in Diagnostics Setting) for the NAT gateway resource providing outbound connectivity for the impacted VMs. It is recommended to enable Log Analytics as a destination as it allows you to easily query the data. For the detailed steps, visit Monitor with StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn.

Tip: You may enable flow logs even when not troubleshooting to ensure you’ll have historical data to reference when issues occur.

Step 3: Confirm whether the connection was established

1. Use Log Analytics to query for flows with source IP == VM private IP and destination IP == IP address(es) of github.com. The following query will generate a table and chart of the total packets sent per minute from your source IP to the destination IP through your NAT gateway in the last 24 hours.

   NatGatewayFlowlogsV1
   | where TimeGenerated > ago(1d)
   | where SourceIP == '10.0.0.4'  //and DestinationIP == <"github.com IP">
   | summarize TotalPacketsSent = sum(PacketsSent) by TimeGenerated = bin(TimeGenerated, 1m), SourceIP, DestinationIP
   | order by TimeGenerated asc

2. If there are no records of this connection, it is likely an issue with establishing the connection because flow logs will only capture records of established connections. Take a look at SNAT connection metrics to determine whether it may be a SNAT port exhaustion issue or NSGs/UDRs that may be blocking the traffic.
3. If there are records of the connection, proceed with the next step.

Step 4: Check if there are any packets dropped

In Log Analytics, query for the total "PacketsSentDropped" and "PacketsReceivedDropped" per source/outbound/destination IP connection.

1. If "PacketsSentDropped" > 0 - NAT gateway dropped traffic sent from your VM.
2. If "PacketsReceivedDropped" > 0, NAT gateway dropped traffic received from destination IP, github.com in this case.
3. In both instances, it typically means the either the client or server is pushing more traffic through a single connection than is optimal, causing connection-level rate limiting.
4. To mitigate:

• • Avoid relying on one connection and instead use multiple connections.
  • Distribute traffic across multiple outbound IP addresses by assigning more public IP addresses to the NAT gateway resource.

Conclusion

StandardV2 NAT Gateway Flow Logs unlock a powerful new dimension of outbound visibility and they can help you:

• Validate cybersecurity readiness
• Audit outbound flows
• Diagnose intermittent connectivity issues
• Understand traffic patterns and optimize architecture

We are excited to see how you leverage this new capability with your StandardV2 NAT gateways!

Have more questions?

As always, for any feedback, please feel free to reach us by submitting your feedback. We look forward to hearing your thoughts and hope this announcement helps you build more resilient applications in Azure.

For more information on StandardV2 NAT Gateway Flow Logs and how to enable it, visit:

Manage StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn

Monitor with StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn

To see the most up-to-date pricing for flow logs, visit Azure NAT Gateway - Pricing | Microsoft Azure.

To learn more about StandardV2 NAT Gateway, visit What is Azure NAT Gateway? | Microsoft Learn.