Amazon EC2 speed and latency from AU

Shaun Ewing 19 Comments

On November 13, 2012, Amazon launched a new region in Sydney.

I recently had a requirement to provision an application within Amazon EC2. The web based application was going to be accessed primarily by Australian users, and as a result I wanted to know which of Amazon’s 7 public regions would be likely to provide the lowest latency for users accessing the application.

To do this I provisioned a Micro instance (t1.micro) in each of the following regions:

  • Asia Pacific (Singapore)
  • Asia Pacific (Tokyo)
  • EU (Ireland)
  • South America (São Paulo)
  • US East (Northern Virginia)
  • US West (Oregon)
  • US West (Northern California)

Once the instances were online I then took the top six Australian ISPs according to Broadband Choice, which at the time of writing are (in alphabetical order):

  • Exetel
  • iiNet
  • Internode
  • Optus
  • Telstra
  • TPG

I also added Vocus Communications to the mix as a popular provider of IP transit services within Australia.

From each of these providers I ran a series of tests to test the latency and the number of network hops between their network and the Amazon EC2 instance. Tests for all providers were ran from the east coast (Sydney or Melbourne), for providers such as Internode with direct connectivity on cable systems such as SMW3 to Singapore, you might expect lower latency to the Singapore region from Perth.

The Results

With the tests run, here are the results:

Amazon EC2 Latency from Australia

You can instantly exclude EU and South America for Australian users, the average latency is just too high. US East (Virginia) is a possibility, but again the latency is quite high and users are likely to find applications are simply too slow.

Singapore has the lowest latency of all regions depending on the ISP. Users on Internode, Optus and with providers utilising Vocus bandwidth should find performance quite acceptable. Unfortunately for other providers such as Exetel and TPG the performance isn’t quite so good, most likely due to a path in one direction travelling via the USA.

US West (Northern California) has the most consistent latency, with all ISPs around the 150-180ms point. This means that users across all ISPs should have acceptable performance.

In this instance I decided to go with US West (Northern California) for my application due to its consistent latency across the board. Singapore was a close contender, however more testing might be required to ensure that there aren’t any other ISPs that experience latency beyond 200ms.

With Amazon recently establishing a presence in Sydney for CloudFront and Route 53, I’d also recommend offloading any static assets such as CSS, JavaScript and images to the CDN ensuring that users receive them as quickly as possible. With this in place there’s going to be a noticeable performance improvement for your Australian users regardless of the region that you have selected.

About the Author

Comments 19

  1. Hello All,

    I am facing the same issue. I have an instance is AU – Sydney and the database is in EU – Ireland. It is taking so much of time in connection from AU to EU.

    Can anybody help with this issue?
    Will this issue be resolved after shifting the AU instance to US?

    1. Post
      Author
      1. Thanks Shaun!

        Yes, We are using RDS, we do read & write both so read-replica will not be good option.

        Can you suggest something else..

        1. Post
          Author

          Unfortunately there’s not much you can do about latency, but a few suggestions without knowing anything about the application.

          1) You could implement a caching layer in AU to keep repeated reads local without having to go to EU all the time.

          2) If eventual consistency is acceptable you could queue the writes to the database and batch them.

  2. Unfortunately the following file is missing: sc_20120704_amazonec2graphCould you please send it? I think this is very very interesting…..

    Greetings from AustriaTom

  3. This was a very useful analysis at the time thanks Shaun. For people who now have say an EC2 instance in Sydney, and maybe are thinking of keeping snapshots in another region for disaster recovery, I’m wondering if you know whether the latencies have changed much since mid-2012 ?

    1. Hi mickeyoz,

      I do exactly that for a few projects.

      If you’re transferring from within AWS then you really only need to look at the inter-region latencies. From Sydney the fastest region to communicate with is Tokyo, which comes in around 130-135ms.

      I haven’t done any inter-region speed tests though, but traffic between ap-southeast-2 and ap-northeast-1 looks like it traverses the AJC (Australia Japan Cable) system so should be pretty quick.

      1. Thanks Shaun. I was really thinking of the scenario where one of the sydney data centres burnt to the ground, and there wasn’t capacity in the other availability centre for everyone to move over. My DR plan would be to create a new instance in Tokyo (or wherever) from the last snapshot stored there, change the DNS and re-start operations. So it would be latencies from all parts of australia that would be the issue. From the last analysis it looked like California would be the best option.

        1. Good point!

          I might re-run the analysis again when I get a spare moment. Probably won’t be for a week or two though as I’ll be in the US at re:Invent 🙂

          California I suspect will still be the best combination of price vs performance (although most of the applications I work with run DR out of Singapore).

  4. Matt/Daniel. EC2 /AWS in Sydney will reduce your latency over having it hosted in SG. That is a basic distance issue. Peering is a different issue though and is what causes the network to network congestion. I see Optus uses Akamai for their main sites using CDNplanet.com. Keep in mind that most CDN’s don’t do front end optimization. This is kind of the v. 2.0 of web experience.

    1. Hi Adam,A lot of ISPs provide looking glass utilities that will allow you to perform various tests (eg: ping, traceroute) from within the ISP’s network.

      I used these tools and then collated the results into what you see above.

Leave a Reply

Your email address will not be published. Required fields are marked *