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

时间:2011-06-14 06:46:16

标签: amazon-s3 amazon-ec2 amazon-web-services

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

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

9 个答案:

答案 0 :(得分:76)

确定自定义使用的最低延迟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已经出现令人惊讶的事实的原因,即澳大利亚用户目前通过美国西部(北加州/美国西部1)而不是亚太地区(新加坡)获得更好的延迟/ ap-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 3}}给Amazon EC2Elastic Load Balancing等用户。

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

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

答案 1 :(得分:24)

还有一个速度测试网站:https://cloudharmony.com/speedtest如果您想轻松查看最适合您的地区。

答案 2 :(得分:21)

尝试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认证时发现了它。

答案 3 :(得分:5)

显然,测试不同地区的延迟是可取的!我位于澳大利亚,这里的许多用户对美国西部的延迟比对新加坡更好 - 部分归结为本地ISP的对等和国际连接。如果您在目标地区拥有用户,则测试相对简单。

AWS端的可靠性(即非用户网络问题)主要是跨多个可用区部署的结果。美国地区的选择比亚太地区更多,仅仅是因为他们一直在为这些市场服务的时间更长。这样做的副作用是在新加坡/东京相对较晚部署了功能 - 通常新功能将在美国东部推出。

由于您已经考虑使用S3和EC2作为您想要使用的服务,并且它们都可以在更近的地区使用,因此请评估来自AWS的新Web服务是否立即重要 - 如果不是,请拍摄某些内容(延迟)靠近。

答案 4 :(得分:5)

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

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

答案 5 :(得分:5)

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

区域按延迟排序。

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

答案 6 :(得分:3)

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

http://www.cloudwatch.in/

enter image description here

答案 7 :(得分:2)

编辑:看看Mark Tsai的回答。这是要走的路(当我写这篇文章时,53号路线不存在)

这可能属于ServerFault,但这里是:

你基本上要求的是Geo DNS。

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

在此之前,您可以查看第三方解决方案,例如Zerigo,它将为您提供地理DNS设施。

或者,如果你是硬核,你可以通过配置BIND with IP2Location

来自己动手

编辑:有post on ServerFault that talks about Geo DNS providers

关于性能和AWS可靠性的问题:您应该考虑从最近的AZ向您的用户提供您的站点 - 它在速度方面非常有意义,并且没有将您的所有实例都放在单个AZ中。您可以查看AWS Service Health Dashboard以全面了解亚马逊的服务在不同的AZ中的可靠性。请注意,此数据直接来自亚马逊 - 我在其他任何地方都没有看到任何独立的统计数据。

答案 8 :(得分:0)

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