如何确定哪个AWS位置最适合特定区域的客户？

Question 1

AWS有多个存储位置和EC2实例，它们可以以不同的价格运行。如何确定特定地区的最佳位置。它是直观的（最好是靠近您的服务区域）还是存在可靠性方面的顾虑（特定的AWS位置比其他位置面临更多的停机）。是否有任何数据可用于做出这样的决定？

我正在开发一个主要针对印度客户的应用程序。因此，我正在考虑选择新加坡或东京。

Question 2

确定最低延迟的AWS位置以进行自定义使用

TurnKey Linux的聪明和创新人士最近开放了他们针对您的问题的解决方案，请参阅GitHub上的AWS区域数据中心映射：

该项目用于生成TurnKey Hub用来为用户找到最接近的AWS数据中心的索引（和可视地图以供参考）。[强调我的]

正在使用的算法在使用GeoIP和索引查找最接近的数据中心以及后续文章使用GeoIP和索引查找最接近的APT软件包存档中进一步详细介绍。

虽然有点花招，但可视化效果非常酷，可以确认得到响应。说明了乔希已经提到的乍看之下令人惊讶的事实的原因，即澳大利亚的用户目前倾向于通过美国西部（北加利福尼亚州/ us-west-1）而不是亚太地区（新加坡/ ap-southeast）获得更好的延迟-1）地区。（提示：检查右下角的Future Cables可能会改变这种情况，这在Greg的Cable Map中有更详细的说明，这表明澳大利亚可能会在未来几年内在两个AWS位置之间延误；）

通过Amazon Route 53自动使用最低延迟的AWS位置

同时，AWS提供了一个有用的地图，用于快速评估其全球基础架构，以及相应的详细信息，例如可用性区域数和API端点。

不过，更重要的是，AWS刚刚已经宣布了Jahufar提到的地理DNS支持，请参阅介绍性文章《 AWS现已提供基于多区域延迟的路由》，该文章向Amazon EC2的用户提供了相同的基于延迟的路由技术，该技术可为Amazon CloudFront提供支持，弹性负载平衡等。

因此，如果您的环境已经由Auto Scaling EC2实例架构组成，则仅应用基于延迟的路由将自动解决您的问题。

尽管用例显然针对产生多个AWS区域的产品，但基于延迟的路由和加权轮循记录集的复杂功能可能使您自己也可以轻松确定所需的信息。

Question 3

尝试cloudping.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

SO管理员的注意事项：我与该服务无关。我在准备AWS认证时找到了它。

Question 4

还有一个用于速度测试的网站：https : //cloudharmony.com/speedtest（如果您想轻松地检查哪个区域最适合您）。

Question 5

这是一个显示最近的aws区域的控制台工具：

https://github.com/ekalinin/awsping

它是用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

区域按延迟排序。

您可以在任何服务器上运行它，并为您确定最近的区域。

Question 6

建议测试到不同区域的延迟！我位于澳大利亚，这里的许多用户到美国西部的延迟要比到新加坡的延迟好-部分原因在于本地ISP对等和国际连接。测试您是否在目标区域内有用户相对简单。

AWS方面的可靠性（即不是用户网络问题）主要是跨多个可用区进行部署的结果。美国地区比亚太地区有更多选择，这仅仅是因为它们为这些市场提供服务的时间更长。这样做的副作用是功能部署到新加坡/东京的时间相对较晚-通常，新功能会在美国东部开始推出。

由于您已经想将S3和EC2作为服务使用，并且它们都可以在较近的地区使用，因此请评估来自AWS的较新Web服务是否立即重要-如果不是，请在附近寻找一些东西（延迟）。

Question 7

亚马逊现在提供了基于最低最终用户延迟来路由到数据中心的功能。这是Route53的新“基于延迟的路由”！

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

Question 8

从我们的位置检查延迟的好工具/站点

http://www.cloudwatch.in/

Question 9

编辑：看看马克·蔡的答案。这就是要走的路（我写这篇文章时，Route 53不存在）

这可能属于ServerFault，但这里有：

您基本上想要的是Geo DNS。

目前，AWS尚不直接支持该功能-尽管我已经在某些AWS论坛帖子中看到了对其实施的讨论-很可能是在其Route 53服务中实现的。

在此之前，您可以研究可以为您提供Geo DNS功能的第三方解决方案，例如Zerigo。

或者，如果您是铁杆，则可以通过使用IP2Location配置BIND来自己动手

编辑：ServerFault上有一篇文章讨论了Geo DNS提供程序

至于有关性能和AWS可靠性的问题：您应该考虑从最近的可用区为用户提供站点服务-从速度上讲是很有意义的，并且不能将所有实例都放在一个可用区中。您可以查看AWS Service Health Dashboard，以大致了解Amazon服务在不同可用区中的可靠性。请注意，这些数据直接来自亚马逊-我在其他任何地方都没有看到任何独立的统计数据。

Question 10

http://blog.datapath.io/aws-network-latency-map讨论了获取此信息的商业产品。它在地图上显示从您指定的位置到您指定的AWS服务的延迟时间。