AWS Latency Index

By | 6th April 2019

In modern web applications, it is of paramount importance to deal with latency correctly.  

Within an application, latency reveals itself at many different levels and with very different values. Computer latency at a human level is a good reference to understand the different timescales.

It is clear that  the dominant term, by large, is the network latency. This is something to bear in mind especially when using microservice architectures.

However, very few of us are familiar with the latency value of an internet call between two locations on Earth.

This post aims to shed some light on the subject by presenting some data collected on AWS infrastructure.

So, in the same way that the ubiquity of McDonald’s around the world has allowed economists to create the Big Mac Index, the ubiquity of AWS regions across the globe will let us create the AWS Latency Index to measure the performance of the internet calls.

Test description and results

The test consists of 4 web servers in 4 different AWS regions, Ireland, Oregon, Sydney and Sao Paulo, pinging each other once every minute. The servers return an empty response (http code 204). The latency of each call is stored in a database for later analysis.

The test was run in two different periods: from 2018-09-28 to 2018-10-23 and from 2019-02-23 to 2019-03-31.

Here’s the average value of the latency (in seconds) for each period:

origin destination Sep – Oct (2018) Feb – Mar (2019)
oregon ireland 0.269971 0.267397
ireland oregon 0.271157 0.267159
oregon sydney 0.309329 0.278629
sydney oregon 0.309452 0.278496
ireland saopaulo 0.397031 0.367805
saopaulo ireland 0.397153 0.367862
oregon saopaulo 0.403891 0.366153
saopaulo oregon 0.405521 0.365982
ireland sydney 0.550614 0.536054
sydney ireland 0.550703 0.536064
saopaulo sydney 0.672782 0.630039
sydney saopaulo 0.67287 0.629908

A first look at the values reveals that, in most cases, the results are similar in both directions up to the order of units of milliseconds. This is good news, it would have been worrying had the results been different. From now on, we will consider just one of the directions for each par of regions.

The second thing to notice is that the values of the second period are consistently better, for instance, the improvement between Oregon and Sydney is about 31 ms and between Sao Paulo and Sydney is a whopping 43 ms.

To make it clearer, let’s present the data of each direction just for the second period:

origin destination Feb – Mar (2019)
oregon ireland 0.267397
oregon sydney 0.278629
ireland saopaulo 0.367805
oregon saopaulo 0.366153
ireland sydney 0.536054
saopaulo sydney 0.630039

The values vary from 267 ms between Oregon and Ireland up to 630 ms between Sao Paulo and Sydney. According to Computer latency at a human level, that is equivalent to 21 and 49 years, respectively. Just an eternity!

The following histogram provides a visual representation of the latency between Oregon and the other regions:

Oregon latency – March 2019

It is interesting to compare the above graph with the one corresponding to the first period:

Oregon latency – October 2018

Not only is the average latency better in the second period, but the values are more concentrated around the average value making a nice distribution graph.

Here are the graphs corresponding to the other regions:

Ireland latency – March 2019
Sao Paulo latency – March 2019
Sydney latency – March 2019

If instead of histograms, we use time series analysis, we can get some interesting insights about the data. The below graph represents the values of latency between Ireland and Oregon during the sampled period (values are resampled into bins of 1 hour). The values over the 95% percentile are few and not very large, what is consistent with the histogram representation.

Ireland – Oregon, March 2019

If we compare the above graph to the one corresponding to the first period, the difference is noticeable. The number of outliers is higher and their values greater.

Ireland – Oregon, October 2018

After removing the values above the 95% percentile, the above graphs become:

Ireland – Oregon without outliers, March 2019
Ireland – Oregon without outliers, October 2018

The values of March are very well-behaved, with the median and the mean having nearly the same values. The same cannot be said of the values corresponding to October.

Latency index

Let’s focus on the results of March to calculate the latency index. We will define the latency index as the ratio between the theoretical value of the latency and the real one.

The theoretical value corresponds to the time it would take to cover the distance between two regions and back along the great circle connecting those regions and travelling at the speed of light.

origin destination latency theoretical_time theoretical/real
oregon sydney 0.278629 0.082337 0.295508
ireland sydney 0.536054 0.114806 0.214169
oregon saopaulo 0.366153 0.072217 0.197231
oregon ireland 0.267397 0.049941 0.186768
ireland saopaulo 0.367805 0.062403 0.169664
saopaulo sydney 0.630039 0.089302 0.14174

The values vary from nearly 30% between Oregon and Sydney to just 14% between Sao Paulo and Sydney.


The latency measurements obtained during the period of March 2019 are better behaved than those corresponding to October 2018. This may be down to either problems on AWS infrastructure back in October or problems on the Internet connectivity itself.

As to the latency index, it is a bit disappointing. The best result, for Oregon-Sydney, is just 30%. In other words, in the best case scenario the latency is more than 3 times the theoretical value.

In the case of Sao Paulo-Sydney is 7 times! Probably there is not direct cable between South America and Australia or the internet infrastructure in South America is not that great.

The application and the data collected can be found on AWS Index. That repository also contains 2 Jupyter Notebooks written in Python with all the details of the data analysis and calculations shown in this post. The notebooks can be executed online on

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.