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

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

| AWS有多个存储位置和EC2实例，它们可以以不同的价格运行。如何确定特定地区的最佳位置。是直观的（最好是靠近您的服务区域）还是有任何可靠性方面的顾虑（特定的AWS位置比其他位置面临更多的停机）。是否有任何数据可用于做出这样的决定？我正在开发一个主要针对印度客户的应用程序。因此，我正在考虑选择新加坡或东京。

解决方法

确定最低延迟的AWS位置以进行自定义使用 TurnKey Linux的聪明和创新人士最近开放了他们对问题的解决方案，请参阅GitHub上的AWS区域数据中心映射：该项目用于生成索引（以及参考）由TurnKey Hub用来查找最近的AWS数据中心对于用户。 [强调我的] 正在使用的算法在使用GeoIP和索引查找最接近的数据中心，以及后续文章使用GeoIP和索引查找最接近的APT软件包存档中有更详细的说明。虽然有点a头，但可视化效果非常酷，可以确认得到响应。说明了乔希已经提到的乍看之下令人惊讶的事实的原因，即澳大利亚的用户目前倾向于通过美国西部（北加利福尼亚州/ 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区域的产品，但基于延迟的路由和加权循环记录集的复杂功能可能使您自己也可以轻松确定所需的信息。 , 尝试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认证时找到了它。 , 还有一个用于速度测试的网站：https://cloudharmony.com/speedtest（如果您想轻松地检查哪个区域最适合您）。 , 这是一个显示最近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

区域按延迟排序。您可以在任何服务器上运行它，并为您确定最近的区域。 , 建议测试不同地区的延迟时间！我位于澳大利亚，这里的许多用户到美国西部的延迟要比到新加坡的延迟好-部分原因在于本地ISP对等和国际连接。如果您要定位的区域中有用户，则测试相对简单。 AWS方面的可靠性（即不是用户网络问题）主要是跨多个可用区进行部署的结果。美国地区比亚太地区有更多选择，这仅仅是因为它们为这些市场提供服务的时间更长。这样做的副作用是功能部署到新加坡/东京的时间相对较晚-通常，新功能会在美国东部地区开始推广。由于您已经想将S3和EC2作为服务使用，并且它们都可以在较近的地区使用，因此请评估来自AWS的较新Web服务是否立即很重要-如果不行，请争取一些东西（延迟）通过。 ,亚马逊现在提供了基于最低最终用户延迟来路由到数据中心的功能。这是Route53的新“基于延迟的路由”！ http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html , 从我们的位置检查延迟的好工具/站点 http://www.cloudwatch.in/ , 编辑：看看马克·蔡的答案。这就是要走的路（我写这篇文章时，Route 53不存在）这可能属于ServerFault，但这里有：您基本上要的是Geo DNS。目前，AWS尚不直接支持该功能-尽管我已经在某些AWS论坛帖子中看到了对其实施的讨论-很有可能是在其Route 53服务中实现的。在此之前，您可以研究能够为您提供Geo DNS功能的第三方解决方案，例如Zerigo。或者，如果您是铁杆，则可以通过使用IP2Location配置BIND来自己动手编辑：ServerFault上有一篇文章讨论了Geo DNS提供程序至于有关性能和AWS可靠性的问题：您应该考虑从最近的可用区为用户服务您的站点-从速度上讲是非常合理的选择，而不是将所有实例都放在一个可用区中。您可以查看AWS Service Health Dashboard，以大致了解Amazon服务在不同可用区中的可靠性。请注意，这些数据直接来自亚马逊-在其他任何地方都没有看到任何独立的统计信息。 , http://blog.datapath.io/aws-network-latency-map讨论了获取此信息的商业产品。它在地图上显示从您指定的位置到您指定的AWS服务的延迟时间。