Franck Pachot
Posted on November 12, 2022
Everybody wants to know how far they are from an AWS region. This even when not working in IT: my kids know which AWS region they connect to when playing Fortnite.
New region in Switzerland
I'm back from the AWS Swiss User Group Lausanne where the first topic was the new AWS Swiss region in Zurich. It is on average 10% more expensive than Frankfurt but there are two reasons to go to a region in your country: legal constraints and lower latency.
It can be obvious that connecting within your country is faster. However, on the internet, the fastest way may not be the shortest one. It depends on the internet routes. Let's try it. I live near Lausanne (Switzerland), and will ping an AWS server in the new region eu-central-2 in Zurich (250 km, in Switzerland) and the one I used until now, eu-central-1 in Frankfurt (550 km, in Germany):
The Lausanne-Zurich way should stay in Switzerland and be faster than Lausanne-Frankfurt, right?
Without having to know a server to ping in each region, I can ping the DynamoDB service and show the connect time with with curl -w "%{time_connect}:
Franck:~ $ curl -w "%{time_connect} $name\n" \
http://dynamodb.eu-central-2.amazonaws.com/ping
healthy: dynamodb.eu-central-2.amazonaws.com 0.144338
Franck:~ $ curl -w "%{time_connect} $name\n" \
http://dynamodb.eu-central-1.amazonaws.com/ping
healthy: dynamodb.eu-central-1.amazonaws.com 0.082063
This is 144 milliseconds to Zurich and 82 milliseconds to Frankfurt, the opposite of what I expected. However, the routes can change. If you run the same to the same destination several times, you may get lower latency:
Franck:~ $
for r in eu-central-2 eu-central-1 ; do
for i in {1..10} ; do
curl -w "%{time_connect} $name\n" \
http://dynamodb.$r.amazonaws.com/ping
done
echo
done
healthy: dynamodb.eu-central-2.amazonaws.com 0.083545 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.083080 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.083567 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.085773 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.064574 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.054981 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.085418 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.059449 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.057155 us-west-1
healthy: dynamodb.eu-central-2.amazonaws.com 0.075989 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.096158 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.061988 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.059302 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.048715 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.067701 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.079070 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.057664 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.052125 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.057473 us-west-1
healthy: dynamodb.eu-central-1.amazonaws.com 0.065644 us-west-1
Connect time to all AWS regions
I'll ping every DynamoDB service in all AWS regions worldwide and sort them by latency to get a TCP connect.
- I get the list of AWS regions with an Amazon DynamoDB service from https://status.aws.amazon.com/services.json
- I ping them with http://dynamodb.eu-central-2.amazonaws.com/ping where
eu-central-2is the region name - I get the connect time from
curlwith%{time_connect} - I convert seconds to milliseconds and sort it on that
You need to install curl and jq for that. The connects 10 times to each region and displays the minimum connect time for each:
for i in {1..10} ; do
for name in $(
curl -s https://status.aws.amazon.com/services.json |
jq -r '.[]|select(.service_name=="Amazon DynamoDB")|.region_id'
)
do
curl -sw "%{time_connect}\n" http://dynamodb.$name.amazonaws.com/ping
done
done |
awk '
t[$2]==0 || t[$2]>$NF{t[$2]=$NF}
END{for(r in t)printf("%8.2f ms to %-s\n",t[r]*1000,r)}
'| sort -n
Here are the results from home (I live near Lausanne in Switzerland):
91.36 ms to dynamodb.eu-central-1.amazonaws.com
96.03 ms to dynamodb.eu-west-1.amazonaws.com
110.03 ms to dynamodb.eu-central-2.amazonaws.com
110.66 ms to dynamodb.eu-west-2.amazonaws.com
120.62 ms to dynamodb.eu-north-1.amazonaws.com
121.05 ms to dynamodb.eu-west-3.amazonaws.com
123.72 ms to dynamodb.eu-south-1.amazonaws.com
173.18 ms to dynamodb.us-gov-east-1.amazonaws.com
182.34 ms to dynamodb.us-east-2.amazonaws.com
188.49 ms to dynamodb.ca-central-1.amazonaws.com
193.64 ms to dynamodb.us-east-1.amazonaws.com
199.27 ms to dynamodb.me-south-1.amazonaws.com
227.94 ms to dynamodb.me-central-1.amazonaws.com
260.93 ms to dynamodb.ap-south-1.amazonaws.com
266.01 ms to dynamodb.us-west-1.amazonaws.com
269.80 ms to dynamodb.af-south-1.amazonaws.com
273.51 ms to dynamodb.ap-southeast-3.amazonaws.com
286.98 ms to dynamodb.ap-east-1.amazonaws.com
288.28 ms to dynamodb.us-west-2.amazonaws.com
291.29 ms to dynamodb.us-gov-west-1.amazonaws.com
291.33 ms to dynamodb.ap-southeast-1.amazonaws.com
298.87 ms to dynamodb.sa-east-1.amazonaws.com
311.29 ms to dynamodb.ap-northeast-3.amazonaws.com
333.56 ms to dynamodb.ap-northeast-1.amazonaws.com
334.21 ms to dynamodb.ap-northeast-2.amazonaws.com
358.49 ms to dynamodb.ap-southeast-2.amazonaws.com
This is interesting. The faster connect to the new region in Zurich in eu-central-2 is 110.03 milliseconds, slower than Frankfurt in Germany (eu-central-1) which is 91.36 milliseconds.
Tracing the route though internet
Let's traceroute to understand it better:
Franck:~ $ tracert dynamodb.eu-central-2.amazonaws.com
1 1 ms 1 ms 1 ms INTEL_CE_LINUX [172.22.22.1]
2 12 ms 19 ms 9 ms 193-164-24-1.sefanet.net [193.164.24.1]
3 13 ms 10 ms 12 ms v125-4500x.sefanet.ch [217.119.144.212]
4 18 ms 17 ms 16 ms e9-c1.sefanet.ch [217.119.144.194]
5 9 ms 12 ms 10 ms e8-b2.sefanet.ch [217.119.144.226]
6 12 ms 15 ms 12 ms 10.250.2.241
7 22 ms 30 ms 23 ms 213.230.52.147
8 35 ms 23 ms 28 ms decix1.amazon.com [80.81.194.152]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 45 ms 31 ms 27 ms 13.248.68.72
I traced all location Latitude/Longitude from ipinfo.io:
- 193.164.24.1 is my cable provider (SEFA)
- 213.230.52.147 is the internet provider (Netplus), in Zurich:
- 80.81.194.152 is a German internet exchange point (DE-CIX), apparently the connection to Amazon, and this is Frankfurt
- 13.248.68.72 is my final destination, Amazon in Zurich
In the above route, the connection goes out of my internet provider network in Zurich, enter the Amazon network in Frankfurt and come back to Zurich. This is not very optimal but that's how internet works.
Hybrid Cloud
I've run the same from an OCI (The Oracle Cloud) machine in Zurich:
Even from another cloud also in Zurich (and it could even happen that they share the same data centers, I know that Oracle Cloud is hosted in Equinix, but AWS do not disclose it) it is faster to connect to another region.
Here is the result of my script to get the fastest of 10 connections to each AWS region:
Encryption and Direct Connect
The conclusion: in the cloud, do not guess anything when going through the internet. If you want to keep your data in your country, be sure that the network is encrypted (example for YugabyteDB: Encryption in transit) and to have predictable performance, use dedicated network (like AWS Direct Connect) . Without it, connecting to a region in the same country is not a guarantee of staying there or taking the shortest route.
Posted on November 12, 2022
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.