Microsoft: Measuring Latency and Throughput Between Azure Regions
If you want to implement disaster recovery, latency and throughput between your primary and secondary location are key factors. These determine how quickly and how much data you can transport to the secondary location, and hence how much data will be lost in case of failure of the primary location. More formally, the latency and throughput determine the possible recovery point objective. In this post I will walk through measuring latency and throughput between Azure regions, so you can determine the best configuration for your scenario.
Latency is determined by the speed of light and the number of infrastructure components between the source and destination. This means that the closer the primary and secondary location are, the lower the latency. The catch is that if the primary and secondary location are too close together, they could potentially be hit by the same (natural) disaster. When Microsoft picks locations for Azure regions, they are selected to be a safe distance apart for most major disasters (earthquake, flood, and so on).
Options for connecting virtual networks in different regions
In Azure there are three ways to connect virtual networks in different regions:
In this post I will focus on VPN and virtual network peering, but you could use the same method to measure latency and throughput in a configuration with ExpressRoute. Before I go into how you measure latency and throughput, let’s look at the architectural differences between the three options.
Read the entire article here, Measuring Latency and Throughput Between Azure Regions – Michiel van Otegem’s Blog
Via the fine folks at Microsoft