This is using "ping", i.e. ICMP echoes. That's easy to implement, but problematic in more ways than you might at first think. Firstly, some network elements may be configured to give ICMP echo request/response packets a different delivery priority, which could invalidate results for your probably-not-ping-based application. Secondly, a virtual machine may have more jitter in scheduling the transmission and the response. Thirdly, you don't get a picture of how congested the route is - is it good for a gigabit blast, or only a trickle of data?

But there's a deeper problem: ping measures round-trip time.

Interesting fact about IP routing: quite often, route out != route back. There's no requirement that paths in the Internet be symmetric, and very often, they aren't. What's more, congestion is often one-way.

So let's say you have a 92ms RTT between two sites; you can't know, from the ping alone, if that's an even 46ms each way, or 53ms one way and 39ms the other, or perhaps even 83ms + 9ms. If your application is sensitive enough to latency that this tool might be interesting, then it's quite possible that such asymmetric results are also relevant.

(obviously the speed of light can give you lower bounds on the split, if you have knowledge of DC locations).

There have been substantial projects to accurately measure one-way latency. For example, the RIPE Test Traffic project from the RIPE NCC (https://www.ripe.net/analyse/archived-projects/ttm) was a large-scale and long-running observatory that kept more statistics besides, such as packet loss. Sadly the successor to this service appears not to measure one-way latency. For precision, it required both an appliance and a GPS antenna to be installed, so major cloud providers were unlikely to cooperate.