Estimate latency between AWS, Azure and GCP regions, or rank regions by round-trip time to your users. Distance-based estimates, not live pings.
Where you place a workload decides how fast it feels. This tool estimates round-trip latency between ten regions across AWS, Azure and Google Cloud (including Ashburn, Dublin, Amsterdam and Singapore) and ranks the regions by latency to the cities your users are in.
The estimate takes the great-circle distance between two points, multiplies it by 1.5 to allow for cables that do not run in a straight line, and divides by the speed of light in fiber, about 200,000 km/s, for the round trip. Between Ashburn and Dublin that gives about 82 ms, and between Ashburn and Singapore about 233 ms. Two regions in the same metro area use a 1 ms floor.
These are estimates from distance, not measurements. Real latency depends on the provider's backbone, routing and peering, and is sometimes lower than the estimate on well-connected routes. Use the matrix to shortlist regions, then run your own measurements before you commit. For the latency of a particular distance or medium, use the network latency calculator.
The tool covers ten regions across AWS, Azure and Google Cloud: Ashburn, Boardman, Dublin, Amsterdam, St Ghislain and Singapore. For any two points it takes the great-circle distance, multiplies it by 1.5 because cables do not run in a straight line, and divides by the speed of light in fiber, about 200,000 km/s, doubling the result for the round trip.
Ashburn to Dublin comes out at about 82 ms, and Ashburn to Singapore at about 233 ms. Two regions in the same metro area use a 1 ms floor.
The lowest latency is not the only factor. Check data residency rules, which services each region offers, price, and how well the provider's backbone connects the regions you need. For users spread across the world, rank regions by latency to each user city and consider more than one region. A latency budget helps: if voice needs one-way delay under about 150 ms, the round trip to the region has to stay well inside 300 ms.
These are estimates from distance, not measurements, and region locations are approximate city centers. Real latency depends on routing, peering and the provider's private backbone, so it can be lower or higher. Use the matrix to shortlist regions, then measure from your own machines or virtual machines before you commit.
Use the best-region mode, pick the cities your users are in, and the tool ranks the regions by estimated round-trip time. Then confirm with real measurements from your own location.
The estimate uses distance only, so regions in the same cities score the same. In practice each provider's backbone and peering differ, so measure the pairs that matter to you.
Fiber routes are longer than straight lines, and the 1.5 route factor is an average. Some routes are more direct and some less, and equipment and queueing add small delays on top.
No. They are calculated from distance, a route factor and the speed of light in fiber. They are meant for planning and comparing regions, not for service-level targets.
Ten regions: AWS in Ashburn, Boardman, Dublin and Singapore; Azure in Ashburn, Amsterdam and Singapore; and Google Cloud in Ashburn, St Ghislain and Singapore.
Start a small virtual machine in each region and run ping or a TCP connection test between them at different times of day. Repeat over a few days and look at the median and the worst case.
Calculate network latency, ping distance, and data transfer times between geographic locations. Free tool for network engineers.
Estimate the circuit size a site needs from user count, application mix, busy-hour concurrency and headroom.
Find the fastest a single TCP connection can run on your link, given round-trip time, packet loss, MTU and an optional receive window.
Estimate how long a file takes to download or upload, and find out whether the link, the TCP window or packet loss is the bottleneck.