If you pay attention to Amazon Web Services (AWS), you may have seen an announcement about a year ago that hosting would soon be available in China (Beijing). And if you've looked into it, you no doubt noticed that it's not truly part of AWS — it's actually a separate company (a joint venture) and requires a separate account. While many of the services are the same, they lack much of the seamless integration with the broader AWS ecosphere.
No fault to Amazon here — it's a valiant effort and no doubt getting better by the day. The list of available services has grown since the launch, and it's apparent that Amazon is committed to this endeavor.
So back to the title of this post — What's the best Amazon Web Services region for serving China? The answer is, as usual: It depends.
Regional Latency
Full disclosure time: I am an avid AWS user, but I have not yet created an AWS-China account. Because of this, and my need to provide some improved APAC hosting in a jiffy, I decided to go with the next best thing — AWS Singapore. The pricing is competitive, the service offering is complete, and the integration with other AWS regions is as smooth as any. But before jumping in, I had to get some metrics. I wanted to be sure that Singapore would in-fact be the best hosting location, and not Japan or Europe or some other unexpected site.
Finding objective measurements for regional latency to various AWS regions is unfortunately not something that comes up in Google very easily. I did find some cool projects though.
The crew over at Turnkey Linux put together a couple of amazing projects to help them with their geographic load balancing strategy. The first part was done in 2010, and later revamped in 2011. The mashups they drew are really beautiful from both a visual and mathematical perspective. How often do you get to mix DevOps and navigational calculus? Anyway — it was not exactly what I was looking for, but gave me hope nonetheless.
A Hypothesis Emerges
A few days later I was doing some unrelated research when I found some measurements on the latency between California and Japan. The latency was surprisingly low despite the large physical distance. The implication is that adding a hosting site in Japan would not provide very much value because of my already strong presence in Oregon. Consequently, Singapore looked like an even better option for maximizing performance for users in APAC.
This got me back on the project for a bit, and I did some more searching to find a great tool at www.CloudPing.info. It's a simple tool for performing a client-side ping to various AWS regions, directly from a web-browser. So now armed with a hypothesis, some preliminary evidence, and an efficient tool I was ready to embark on further testing.
Testing Latency from China
I recruited 16 people from 8 different regions in China and asked them all to run the CloudPing.info test. While not entirely scientific (each respondent only ran the test once), the results are very clear with only a few outliers.
Latency from China to Various AWS Regions: Unfiltered
Target Region | Min | Max | Mean | Median | Standard Deviation |
|---|---|---|---|---|---|
US-East (Virginia) | 217 ms | 7,491 ms | 886 ms | 457 ms | 1,671 ms |
US-West (California) | 174 ms | 21,003 ms | 2,126 ms | 278 ms | 5,168 ms |
US-West (Oregon) | 173 ms | 7,354 ms | 753 ms | 294 ms | 1,671 ms |
Europe (Ireland) | 256 ms | 702 ms | 395 ms | 387 ms | 115 ms |
Europe (Frankfurt) | 97 ms | 614 ms | 322 ms | 288 ms | 140 ms |
Asia Pacific (Singapore) | 51 ms | 187 ms | 117 ms | 108 ms | 40 ms |
Asia Pacific (Sydney) | 151 ms | 615 ms | 246 ms | 207 ms | 107 ms |
Asia Pacific (japan) | 67 ms | 537 ms | 171 ms | 120 ms | 124 ms |
South America (Brazil) | 398 ms | 2,456 ms | 694 ms | 516 ms | 115 ms |
The results are pretty interesting. Of course there's an obvious outlier in the US-West (California) measurements. Removing that entry puts US-West (California) in-line with the other US regions:
Latency from China to Various AWS Regions: One outlier removed
Target Region | Min | Max | Mean | Median | Standard Deviation |
|---|---|---|---|---|---|
US-East (Virginia) | 217 ms | 7,491 ms | 886 ms | 457 ms | 1,671 ms |
US-West (California) | 174 ms | 8,930 ms | 1,015 ms | 270 ms | 2,189 ms |
US-West (Oregon) | 173 ms | 7,254 ms | 753 ms | 294 ms | 1,671 ms |
Europe (Ireland) | 256 ms | 702 ms | 395 ms | 387 ms | 115 ms |
Europe (Frankfurt) | 97 ms | 614 ms | 322 ms | 288 ms | 140 ms |
Asia Pacific (Singapore) | 51 ms | 187 ms | 117 ms | 108 ms | 40 ms |
Asia Pacific (Sydney) | 151 ms | 615 ms | 246 ms | 207 ms | 107 ms |
Asia Pacific (Japan) | 67 ms | 537 ms | 171 ms | 120 ms | 124 ms |
South America (Brazil) | 398 ms | 2,456 ms | 694 ms | 516 ms | 552 ms |
Considering the relatively small data set, I didn't bother doing any further outlier pruning. The results pass the sniff test and definitely confirm that Singapore is my best option for serving Chinese users. I was very surprised at how tight the grouping was for Singapore — a standard deviation of only 40 ms! Hard to infer much over only 16 samples, but pretty impressive nonetheless.
Here are graphs of the dataset:
Latency from China to Various AWS Regions: Unfiltered
Latency from China to Various AWS Regions: Filtered
So I went forward with the Singapore servers and all is well. It's less expensive than Japan and gives me more direct routes from India and South East Asia.
Full data set available here. Scanned clean with Metascan Online.
