How could I determine which AWS location is best for serving customers from a particular region?

AWS has several locations for storage and EC2 instances to run upon with different pricing. How could I determine which location is best for a particular region. Is it intuitive (closer to your serving region is the best) or are there any reliability concerns (particular AWS location facing more outages than others). Is there any data available for making such decision?

I am developing an application that is mainly targeted towards Indian customers. So, I am considering Singapore or Tokyo as an option.

Determining lowest latency AWS location for custom usage

The smart and innovative folks from TurnKey Linux recently open sourced their solution to your problem, see AWS Regional Data Centers mapping on GitHub:

> This project is used to generate the indexes (and visual map for > reference) used by the TurnKey Hub to find the closest AWS data center > for a user. [emphasis mine]

The algorithm in use is further detailed in Finding the closest data center using GeoIP and indexing as well as the follow up post Finding the closest APT package archive using GeoIP and indexing.

While a bit of a gimmick, the visualization is seriously cool and confirms resp. illustrates the reason for the at first sight surprising fact Josh mentioned already, namely that users in Australia currently tend to get better latency via the US West (Northern California / us-west-1) rather than the Asia Pacific (Singapore / ap-southeast-1) region. (Tip: checking Future Cables at the bottom right corner reveals this is likely going to change, which is further detailed in Greg's Cable Map, which indicates Australia might jump between both AWS locations latency wise in the years to come ;)

Using lowest latency AWS location automatically via Amazon Route 53

Meanwhile AWS is providing a helpful map illustrating their Global Infrastructure for a quick assessment, alongside respective details like e.g. number of availability zones and the API endpoint.

More importantly though, AWS has just announced the geographic DNS support Jahufar mentioned already, see the introductory post Multi-Region Latency Based Routing now Available for AWS, which is making available the same latency based routing technology that powers Amazon CloudFront to users of Amazon EC2, Elastic Load Balancing, and more.

So in case your environment is comprised of an Auto Scaling EC2 Instances architecture already, simply applying this latency based routing should solve your problem automatically.

While the use case obviously targets offerings spawning multiple AWS regions, the sophisticated features around Latency Based Routing and Weighted Round Robin Record Sets might allow you to determine the desired information more easily yourself as well.

Try cloudping.info, it will do HTTPS ping from your browser to each AWS region.

Region	Latency
US-East (Virginia)	28 ms
US-West (California)	100 ms
US-West (Oregon)	110 ms
Europe (Ireland)	100 ms
Europe (Frankfurt)	119 ms
Asia Pacific (Singapore)	269 ms
Asia Pacific (Sydney)	239 ms
Asia Pacific (Japan)	209 ms
South America (Brazil)	147 ms
      

There is also a website for speed test: https://cloudharmony.com/speedtest if you easily want to check which region is best for you.

Here's a console tool that shows the nearest aws region:

• https://github.com/ekalinin/awsping

It's written in golang and very easy to use:

➥ ./awsping --verbose 1
      Code            Region                                      Latency
    0 eu-central-1    Europe (Frankfurt)                         36.97 ms
    1 eu-west-1       Europe (Ireland)                           63.18 ms
    2 us-east-1       US-East (Virginia)                        126.52 ms
    3 ap-south-1      Asia Pacific (Mumbai)                     156.98 ms
    4 us-west-1       US-West (California)                      192.92 ms
    5 us-west-2       US-West (Oregon)                          226.23 ms
    6 sa-east-1       South America (São Paulo)                 247.74 ms
    7 ap-northeast-1  Asia Pacific (Tokyo)                      312.22 ms
    8 ap-northeast-2  Asia Pacific (Seoul)                      329.54 ms
    9 ap-southeast-2  Asia Pacific (Sydney)                     337.84 ms
   10 ap-southeast-1  Asia Pacific (Singapore)                  395.73 ms

Regions are ordered by the latency.

You can run it on any server and determine the nearest region for you.

Testing latency to different regions is obviously advisable! I'm located in Australia and many users here get better latency to US West than to Singapore - in part it comes down to local ISPs peering and international connectivity. It's relatively straightforward to test if you have users in the region you're targeting.

Reliability on the AWS side (i.e. not user network issues) is mostly a consequence of deployment across multiple Availability Zones. There are more choices in US regions than in APAC ones simply because they've been serving those markets longer. A side effect of this is that features are deployed relatively late to Singapore/Tokyo - normally new features start rollout in US East.

As you already have S3 and EC2 in mind as services you'd like to use and they're both available in closer regions, evaluate whether newer web services from AWS are immediately important - if not, shoot for something (latency) close by.

Amazon is now offering the ability to route to a datacenter based on lowest end-user latency. It's Route53's new "Latency Based Routing"!

http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html

EDIT: Look at Mark Tsai's answer. That's the way to go (Route 53 didn't exist when I wrote this one)

This probably belongs in ServerFault but here goes:

What you are basically asking for is Geo DNS.

Right now it's not directly supported in AWS - although I've seen some talk of it being implemented in some AWS forum posts - most probably in their Route 53 service.

Until then, you could look into 3rd party solutions such as Zerigo that would provide you with Geo DNS facility.

Or if you are hardcore you could roll your own by configuring BIND with IP2Location

EDIT: There is a post on ServerFault that talks about Geo DNS providers

As for your question regarding performance and AWS reliability: You should consider serving up your site from the nearest AZ to your user - it makes perfect sense in terms of speed and not having all your instances in a single AZ. You could check AWS Service Health Dashboard to get an general idea how reliable Amazon's services are in different AZs. Note that this data is directly from Amazon - I've not seen any independent stats anywhere else.

Good tool/site to Check Latency from our location

http://www.cloudwatch.in/

http://blog.datapath.io/aws-network-latency-map discusses a commercial offering to get this information. It shows latency time from the location you specify, to the AWS service you specify, on a map.