Question

我正在开发一个项目，我需要从浏览器中选择最近的S3区域。在法兰克福地区只有一个API可以为所有S3区域分发令牌。我不能再使用基于延迟的路由（Route53），因为它总是会在同一个EC2实例中结束。

我想到了以下几个选项：

Ping所有适用的区域（ping DynamoDB端点非常快）并选择最快的响应。为了避免hick-up，我可以ping端点3次。问题是暂时的选择可能会选择一个可能很远的S3点。
安装t1.micro服务器，该服务器在所有适用的区域中以自己的区域进行响应。基于延迟的路由用于访问最快的EC2实例。虽然这应该可行（它在过去有效），但我需要一个仅提供最快区域的24/7 EC2实例。这个目标太贵了。
与选项2相同，但我将使用一个返回其自己区域的模拟API网关，而不是专用的EC2实例。问题是所有地区（即圣保罗）都没有API网关。
使用单个t1.micro实例并为每个区域添加弹性IP。可以将NGINX配置为侦听IP地址并为每个地址返回另一个区域。应配置Route53，使其具有解析为每个IP地址的基于延迟的路由。这样我只能使用一个实例，但使用一些弹性IP来获得我需要的结果。
不幸的是，我无法从浏览器中将DNS解析为IP地址。否则，我可以创建多个基于延迟的路由，路由到虚构的IP地址。简单地解析主机名会给我一个IP地址，并告诉我它所代表的区域。

如果AWS提供可以由客户端用来确定最快区域的端点，那将是很好的。任何人都有另一种智能解决方案，可以按比例工作并且成本不高吗？

Answer 1

其他一些选择：

使用单个Amazon S3区域，但使用Amazon CloudFront - 它会将内容缓存到您的用户附近
使用路由53基于延迟的路由来解析因位置而异的DNS名称。让它解析为不同的CNAME记录，所有记录都指向法兰克福，但是当您收到请求时，您可以通过用于到达那里的域名来确定最近的区域（令人困惑，呃！）
订阅MaxMind等服务，以确定用户的地理位置。

Answer 2

此解决方案仅适用于非https网站

我已经设置了另一种解决方案，该解决方案使用基于延迟的路由到各种 DynamoDB端点。所有DynamoDB端点都响应以下响应

healthy: dynamodb.<region>.amazonaws.com

假设该网站位于 example.com 上，我希望能够找到距离我们最近的地区 - 东部，eu-central-1，ap-southeast-1和sa- east-1，然后我创建了四条基于延迟的路线：

region.example.com CNAME dynamodb.us-east-1.amazonaws.com
region.example.com CNAME dynamodb.eu-central-1.amazonaws.com
region.example.com CNAME dynamodb.ap-southeast-1.amazonaws.com
region.example.com CNAME dynamodb.sa-east-1.amazonaws.com

当客户端向http://region.example.com调用HTTP GET请求时，它会返回最近区域的健康响应。从这一行获取区域非常简单。

虽然不是最优雅的解决方案，但它可以在没有额外成本的情况下工作，只需要一点点设置。

更主要的缺点是您无法将此方法与https一起使用，因为DynamoDB会使用Amazon AWS证书进行响应。不允许从加载https的页面发出http请求（混合内容）。

从客户端脚本中查找最近的AWS区域

2 个答案: