Two branch sites had consistently slow access to Azure workloads. I initially blamed the last-mile circuits and replaced both, but performance did not improve. Tracing the path showed that traffic was hairpinning through a distant region before reaching the VNet.
The built-in Azure latency graphs looked normal because they measure from Azure's edge or backbone, not from the branch sites themselves. Once I ran hop-by-hop tests from each branch to the actual workloads, the routing problem became obvious.
How are you baselining this in practice? Do you rely on ExpressRoute and peering metrics, or do you run your own end-to-end probes from every branch? The Azure measurements and my branch-side results differ enough that I no longer trust the built-in metrics alone.
3 Answers
Measure from the branch to the actual workload, not just from Azure’s edge. We run recurring probes from each site and check latency, packet loss, and the route path. A scripted MTR or similar trace is usually enough to expose hairpinning, unexpected UDRs, or an inefficient regional path.
The built-in Azure numbers are not necessarily wrong—they answer a different question. They measure from Azure infrastructure inward, while you need to measure from the branch socket all the way to the workload. If your sites already use a WAN monitoring platform, its hop-by-hop data can be convenient; otherwise, scheduled probes from every branch give you a solid baseline. Check UDRs and routing announcements before replacing circuits.
We use Network Watcher tests from VMs in each Azure region, with endpoints outside Azure as a comparison. Monitoring failure rates is especially useful, and we alert when they cross a threshold. Azure backbone latency is usually less actionable for us because we cannot change much about it; the branch-to-service result is what matters operationally.
That was the key lesson for us too. The route table looked fine at a glance, but the next hop sent traffic through a region much farther away than expected.