我怎样才能确定哪个AWS位置最适合为特定地区的客户提供服务？
AWS有多个存储位置和EC2实例以不同的价格运行。 我怎么能确定哪个位置是最适合特定地区的。 是否直观（接近您的服务区域是最好的），还是有任何可靠性问题（特别是面临更多中断的AWS位置）。 有没有数据可以做出这样的决定？
我正在开发一个主要针对印度客户的应用程序。 所以，我正在考虑新加坡或东京作为一个select。
确定自定义使用的最低延迟AWS位置
TurnKey Linux公司的聪明创新人士最近开放了他们的解决scheme来解决您的问题，请参阅GitHub上的AWS Regional Data Centers映射 ：
该项目用于生成TurnKey Hub使用的索引（和可视化地图以供参考）， 以便为用户查找最近的AWS数据中心。 [强调我的]
正在使用的algorithm在使用GeoIP和索引以及后续发现查找最近的数据中心中进一步详细了解使用GeoIP和索引 查找最接近的APT包归档 。
虽然有点噱头， 可视化是非常酷，并确认resp。 说明了Josh 提到的初看起来令人惊讶的事实，即澳大利亚的用户目前倾向于通过美国西部（北加州/美西1）而不是亚太（新加坡/东南部-1）区域。 （ 提示 ：检查右下angular的未来电缆可能会发生变化，这在Greg的有线电视地图中有更详细的说明，这表明澳大利亚可能会在未来几年潜伏在两个AWS地点之间;
通过Amazon Route 53自动使用最低延迟的AWS位置
与此同时，AWS提供了一个有用的地图，说明了他们的全球基础设施的快速评估，以及相应的详细信息，例如可用区域的数量和API端点。
更重要的是，AWS刚刚宣布了Jahufar已经提到的地理DNS支持，请参阅介绍性文章现在可用于AWS的基于多区域延迟的路由 ，该版本提供了相同的基于延迟的路由技术，为亚马逊EC2的用户提供Amazon CloudFront ， 弹性负载平衡等等。
因此，如果您的环境已经包含Auto Scaling EC2实例体系结构，则只需应用此基于延迟的路由即可自动解决您的问题。
尽pipe用例显然针对的是产生多个AWS区域的产品，但是基于延迟的路由和加权循环logging集合的复杂function也可以让您更轻松地确定所需的信息。
还有一个网站的速度testing： https ： //cloudharmony.com/speedtest，如果你很容易想检查哪个地区最适合你。
testing不同地区的延迟显然是可取的！ 我位于澳大利亚，这里的许多用户对美国西部的延迟要比对新加坡更好 – 部分原因归结为本地ISP对等和国际连接。 testing您所在区域的用户是否相对简单。
AWS方面的可靠性（即非用户networking问题）主要是跨多个可用区域部署的结果。 美国地区的select比亚太地区有更多的select，因为它们一直在为这些市场服务。 这样做的副作用是新加坡/东京的function部署时间相对较晚 – 通常在美国东部开始推出新function。
由于您已经将S3和EC2作为您想要使用的服务，并且它们都可以在更近的地区使用，因此可以评估来自AWS的新Web服务是否立即变得重要 – 如果不是，请在附近拍摄（延迟）。
试试coundping.info
它将执行从您的浏览器到每个AWS区域的HTTP ping。
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 SOpipe理员注意 ：我不隶属于此服务。 我在准备AWSauthentication时发现它。
亚马逊现在可以根据最低的最终用户延迟提供路由到数据中心的能力。 这是Route53的新的“基于延迟的路由”！
http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html
这是一个控制台工具，显示最近的aws区域：
这是用golang写的，很容易使用：
➥ ./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
区域按延迟sorting。
你可以在任何服务器上运行它并为你确定最近的区域。
编辑：看Mark Tsai的回答。 这是要走的路（当我写这个的时候，路线53不存在）
这可能属于ServerFault，但在这里：
你基本上要求的是地理DNS。
现在它不是直接支持在AWS中 – 虽然我已经看到了一些在某些AWS论坛post中实现的谈话 – 很可能是在他们的Route 53服务中。
在此之前，您可以查看第三方解决scheme，例如Zerigo ，它将为您提供Geo DNSfunction。
或者，如果你是硬核，你可以通过configurationBIND IP2Location来自己动手
编辑： 在ServerFault上有一个post，谈论地理DNS提供商
至于关于性能和AWS可靠性的问题：您应该考虑从最近的AZ向您的用户提供您的站点 – 它在速度方面非常合理，并且不会将所有实例都放在一个AZ中。 您可以查看AWS Service Health Dashboard来了解亚马逊服务在不同AZ中的可靠性。 请注意，这个数据直接来自亚马逊 – 我没有看到任何其他地方的任何独立统计。
http://blog.datapath.io/aws-network-latency-map讨论了获取这些信息的商业产品。; 它显示了从您指定的位置到您在地图上指定的AWS服务的延迟时间。
