我如何确定哪个 AWS 位置最适合为特定区域的客户提供服务？

Posted 2023-03-04

【中文标题】我如何确定哪个 AWS 位置最适合为特定区域的客户提供服务？

【英文标题】：How could I determine which AWS location is best for serving customers from a particular region?

【发布时间】：2011-09-14 11:05:57

【问题描述】：

AWS 有多个存储位置和 EC2 实例，可在不同的定价上运行。我如何确定哪个位置最适合特定区域。它是直观的（靠近您的服务区域是最好的）还是有任何可靠性问题（特定的 AWS 位置比其他位置面临更多的中断）。是否有任何数据可用于做出此类决定？

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

【参考方案1】：

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

来自 TurnKey Linux 的聪明和创新的人最近开源了他们对您的问题的解决方案，请参阅 GitHub 上的 AWS Regional Data Centers mapping：

该项目用于生成索引（和visual map 参考）由TurnKey Hub 用于查找最近的 AWS 数据中心 为用户。 [强调我的]

使用的算法在Finding the closest data center using GeoIP and indexing以及后续帖子Finding the closest APT package archive using GeoIP and indexing中有进一步的详细说明。

虽然有点噱头，但visualization 非常酷，并确认了相应的。说明了 Josh mentioned 乍一看令人惊讶的事实的原因，即澳大利亚的用户目前倾向于通过美国西部（北加利福尼亚/us-west-1）而不是亚太地区（新加坡/美联社）获得更好的延迟-southeast-1) 地区。 （提示：检查右下角的 Future Cables 表明这可能会发生变化，Greg's Cable Map 中对此进行了进一步详细说明，这表明澳大利亚可能会在两个 AWS 之间跳跃未来几年的位置延迟明智;）

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

与此同时，AWS 提供了一张有用的地图，说明了他们的 Global Infrastructure 以进行快速评估，以及相应的详细信息，例如可用区的数量和 API 端点。

更重要的是，AWS 刚刚宣布了地理 DNS 支持 Jahufar mentioned，请参阅介绍性帖子 Multi-Region Latency Based Routing now Available for AWS，正在向以下用户提供与 Amazon CloudFront 相同的基于延迟的路由技术Amazon EC2、Elastic Load Balancing 等等。

因此，如果您的环境已经由 Auto Scaling EC2 实例架构组成，只需应用这种基于延迟的路由即可自动解决您的问题。

虽然该用例显然针对产生多个 AWS 区域的产品，但围绕基于延迟的路由和加权循环记录集的复杂功能也可能让您自己更轻松地确定所需的信息。

【讨论】：

不幸的是，TurnKey 解决方案对于非常长的较小位置非常不准确，因为它使用物理距离而不是网络距离。

【参考方案2】：

试试cloudping.info，它会从您的浏览器向每个 AWS 区域执行 HTTPS 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
      

【讨论】：

这很有用。由于东京的某些原因，北京是延迟最高的地区。

我可以在几秒钟内得到延迟。

【参考方案3】：

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

【参考方案4】：

这是一个显示最近的 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

区域按延迟排序。

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

【讨论】：

太棒了；比网站有用得多，因为我试图从服务器而不是客户端找到最低 ping。

【参考方案5】：

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

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

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

【参考方案6】：

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

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

【讨论】：

有没有办法为 AWS S3 使用相同的概念？

【参考方案7】：

编辑：看看 Mark Tsai 的回答。就是这样（我写这篇文章时 53 号公路并不存在）

这可能属于 ServerFault 但这里是：

您基本上要求的是 Geo DNS。

目前它在 AWS 中没有直接支持 - 尽管我已经看到一些关于它在一些 AWS forum posts 中实现的讨论 - 很可能是在他们的 Route 53 服务中。

在此之前，您可以研究 3rd 方解决方案，例如 Zerigo，它可以为您提供 Geo DNS 设施。

或者，如果你是铁杆，你可以通过配置BIND with IP2Location 来自己动手

编辑：有一个post on ServerFault that talks about Geo DNS providers

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

【讨论】：

更新：AWS 现在支持地理定位路由docs.aws.amazon.com/Route53/latest/DeveloperGuide/…

【参考方案8】：

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

http://www.cloudwatch.in/

【讨论】：

此解决方案不可靠。它报告的延迟与我使用 ping 从终端测量的延迟有很大不同。它也没有反映哪个区域最靠近和最远之间的正确顺序。

【参考方案9】：

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