适用于非 AWS 实例的 AWS Route 53 基于延迟的服务

Question

我们需要将我们自己的一台专用服务器与 Route 53 服务与我们的 AWS 实例结合使用。

非 AWS IP 地址是否支持基于延迟的 DNS？

Answer 1

有趣的问题 - 似乎没有明确记录Amazon Route 53是否支持已发布的Amazon EC2 公共 IP 范围之外的 IP 地址，但我认为在某种程度上确实如此，以下是我的计算/测试：

文档

介绍性博客文章基于多区域延迟的路由现在可用于 AWS 提到，如果您在 Route 53 控制台中输入 EC2 实例公共 IP、弹性 IP 或弹性负载均衡器目标，它会为您建议正确的区域- 这确实是在这种情况下，输入非 EC2 IP 地址时，此选择由您决定，请参阅下面的测试。该帖子还指出以下内容：

在幕后，我们不断收集匿名互联网延迟测量结果 [...]。这些测量结果帮助我们构建了从每个 AWS 区域到几乎每个互联网网络的大型网络延迟比较表。它们还允许我们确定这些最终用户通常使用哪些 DNS 解析器。

此外，该帖子提到基于延迟的路由也可用于“A”、“AAAA”、“CNAME”、“TXT”DNS 记录类型[...]。

测试

根据上述背景信息，我使用 EC2 实例 us-east-1、us-west-2、ap-southeast-1、ap-southeast-2创建了一个基于延迟的资源记录集，并添加了一个非 AWS 路由器/网关我们在欧洲，相应地指定 eu-west-1 作为区域。

我使用了低 TTL，并包含/排除和交叉测试了这四个实例各自的 DNS 响应，Route 53 确实提供了所需的结果，即在适当的情况下使用 eu-west-1 中的非 AWS IP 地址进行响应，具体取决于哪些区域已包含在集合中。

• 请注意，我手动执行了这些测试，并没有获得 100% 的系统测试覆盖率 - 理想情况下，这当然应该是分别自动化和可配置的设置。

结论

基于延迟的到非 AWS IP 地址的路由似乎可以工作到您需要将自己的地址包含到可用 AWS 区域之一的程度 - 这确实有意义，因为 AWS 无论如何都需要对非 AWS 路由采用延迟测量来实现从最终用户的角度来看，需要进行最短路径分析，而这些系统大多在 AWS 之外运行。

• 一个突出的例子是Amazon CloudFront的最终用户，其中基于延迟的路由技术起源于该技术，并在全球拥有数十个边缘站点，其中许多位于 AWS 区域数据中心之外，请参阅全球基础设施地图/信息。