🔍 Exploring Latency Between Azure Zones: What You Need to Know
As part of my ongoing work on measuring latency between Azure zones, I’ve taken a closer look at some common questions that often come up when designing network architectures in the cloud. If you’ve ever worked on this topic, you’ve probably asked yourself at least one of these:
- What’s the latency impact of communication between subnets within the same Virtual Network (VNet)?
 - How does latency change when communicating between peered VNets?
 - What’s the effect on latency when traffic passes through a hub with a firewall in the same zone?
 - And what happens when that firewall is located in a different zone?
 
⚠️ Logical zones vs physical datacenters
Important: The mapping between logical zones (you can see on Azure portal or selection through API) and physical datacenters is unique per subscription. This means:
- Zone 1 in your subscription may map to Physical Datacenter A
 - Zone 1 in another subscription may map to Physical Datacenter B or C
 - This randomization ensures load balancing across Azure's physical infrastructure
 

If all your VM is on AZ1 and your firewall is on AZ1 but on another subscription, they can be on different datacenter.
📊 Test Scenarios and Results
Here’s what I found:
✅ Same Zone, Same Performance
Whether you're communicating between subnets or peered VNets within the same zone, there’s virtually no impact on latency. Azure’s Software Defined Network (SDN) handles everything efficiently. In my tests, I observed latencies under 40 µs, comparable to two VMs on the same subnet.
🔥 Firewall in the Same Zone
When traffic passes through a hub with an Azure Firewall in the same zone, the impact is minimal. I measured latencies under 80 µs, which is quite impressive.
⚠️ Firewall in a Different Zone
This is where things change significantly. When the firewall is in a different zone, the latency becomes the sum of all inter-zone latencies involved. In the worst-case scenario, this means crossing two inter-zone links. You can find reference figures on this dashboard:
👉 Azure Network Internal Zone Latency Benchmark Dashboard
🧱 Why Multi-Zone Design Matters
Designing across multiple availability zones is not just a best practice — it’s a must for building resilient, highly available architectures in Azure. It protects your workloads from zone-level failures and ensures continuity of service.
However, multi-zone architecture must be carefully designed. While it improves fault tolerance, it can also impact the performances.
📁 More Details and Test Setup
If you’re interested in the test methodology, scripts, and detailed results, everything is available on GitHub: 👉 vmisson/azure-netbench
🧠 Conclusion
These insights can help you make better decisions when designing secure and performant network architectures in Azure. Understanding how latency behaves across zones—and how components like firewalls impact it—is key to building efficient, scalable systems.
