Skip to content
TURNKEYGNU / LINUX
AppsDocumentationBlogScreenshotsGitHubTurnKey Hub
文English
EnglishDeutschEspañol日本語Português中文
Home/Blog/Mapping AWS data centers for fastest connection

From the project

Mapping AWS data centers for fastest connection

By Alon SwartzDecember 29, 20114 min read
s3awsec2amazon

Yes, that's 'fastest', not closest.

Background

A while back I published a blog post entitled Finding the closest data center using GeoIP and indexing, which described how we automatically determine the AWS regional data center to be used for storing encrypted server backups.

We used the same solution to determine the preferred region when launching cloud servers in the Hub, as well as selecting the closest APT package archive for all TurnKey deployments.

New and improved

Since the original publication, Amazon built new regional data centers in Oregon, Sao Paulo and Tokyo, so the indexes needed to be updated.

While adding support for the new regions I decided to take it a step further and add some improvements.

Improvement #1: Automatic association (distance)

The method originally used to perform automatic association of countries/states to data centers was lacking some what and needed to be improved.

We are now using the Haversine formula, which is used to determine great-circle distances between two points on a sphere from their longitudes and latitudes.

haversine1

haversine2
 

Improvement #2: Incorporated world wide underwater cables (latency)

Originally we relied on user feedback of connection latency to tweak the indexes. This didn't scale very well, so we needed a way to make it easier.

Based on Gregs Cable map, we could mashup the automatic associations and tweak the index overrides based on expected latency.

It turns out that this was a crucial part of the equasion, as a user might be physically closer to data center X, but in reality the connection to data center Y is faster. For example, previously Australia was allocated to Singapore but has been moved to California as the pipe is much fatter (see the visual map below).

Improvement #3: Open source

We originally published the indexes, but have now open sourced the whole project on github in hope that others might find it useful, and make collaboration easier.

Putting it all together

The below screenshot plots countries/states to their associated AWS regional data centers, and overlays the world wide underwater cables for reference:

aws-datacenters-mashup

Want to zoom in? Toggle active and future cables? Check out the live mashup.

Comments (7)

How do you measure latency to different AWS datacenters?

Reply 1 2012-01-01
I agree that it would be better to just go ahead and measure latency and bandwidth directly. The trick is how do you do that from all over the world. Hmmm... maybe if the Hub doesn't already have your network's routing information it asks the appliance to run a few tests and measure latency directly, then caches that information for future reference.

Global routing expert needed

Reply 2 2012-01-01
Good thing Alon open sourced the code. Now let's hope a global routing expert runs into it and decides it would be a fun way to spend some time off on the weekend.

Gotta love it!

Reply 3 2012-01-11

Just how I like my networking cheap and fast!

Interesting

Reply 4 2011-12-30

Above comments aside, I actually had no idea Virginia would be faster than Singapore (I am in Sydney Australia). I have never had need to test for speed issues because Singapore is fast enough for the db frontend apps I am developing. If I can get it faster in Virginia - SWEET! The only issue with that is when the client asks "where is the cloud", sometimes they get turned off when you say "another country".

So as far as practical use goes it may help with data heavy apps in the future, at least for my company.

I am just about to start testing cloud servers and backups with my apps after spending months testing on site installations with TKL (which all came up trumps incidentally) so this information comes with good timing.

Thanks guys!

Good catch

Reply 5 2012-01-13

Good catch Jack - thanks, it was a typo - should have been California. I've updated the blog post.

Sure Eric, go ahead.

Reply 6 2012-07-11

Sure Eric, go ahead. All I ask is that you link back to the original article.

It is "current" for TurnKey purposes

Reply 7 2015-11-07
But seeing as AWS have added Frankfurt (which we are yet to support) it could not be considered up to date in that sense...

Keep exploring

Find your next server

Browse ready-to-use appliances by the job you need to do.

Explore the app library
TURNKEYGNU / LINUX

Own your infrastructure without starting from scratch.

Explore TurnKey
AboutDocumentationFAQBlogGitHub
Free and open sourceSecure by defaultReady to deploy