我们需要将我们自己的一台专用服务器与 Route 53 服务以及我们的 AWS 实例结合使用。
非 AWS IP 地址是否支持基于延迟的 DNS？
答案1
有趣的问题——似乎没有明确的文件证明亚马逊 53 号公路支持已发布之外的 IP 地址Amazon EC2 公有 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 之外运行。
- 一个突出的例子是亚马逊 CloudFront，基于延迟的路由技术的起源以及其特点全球数十个边缘站点，其中许多位于 AWS 区域数据中心之外，请参阅全球基础设施地图/信息。