西北互惠如何使用 Amazon Route 53 Profiles 优化和提高效率

对于网络管理员来说，管理多个 Amazon 虚拟私有云 (Amazon VPC) 和亚马逊云科技账户的 DNS 配置可能是一项艰巨的任务，特别是在具有大量私有托管区域 (PHZ) 和 Amazon Route 53 解析器规则的复杂环境中。传统上，他们依靠出站和入站 Route 53 解析器终端节点来跨账户传输 VPC 资源之间的 DNS 查询，这导致了运营开销和成本增加。进入 Route 53 Profiles，该功能通过为配置和管理多个 VPC 和账户的 DNS 设置提供集中化方法来简化 DNS 管理。

这篇文章展示了亚马逊云科技客户西北互惠如何通过迁移到 Route 53 Profiles 来改变其环境，从而降低流程中的成本和运营开销。

客户环境

在西北互惠银行，我们管理着数百个亚马逊云科技账户，并为 Amazon Route 53 PHZ 采用了分布式部署策略。这种方法涉及在每个亚马逊云科技账户中预置一个专用 PHZ。实施这种模式使开发团队可以访问自己的独立 PHZ，他们使用该 PHZ 来管理特定于其亚马逊云科技工作负载的 DNS 记录集。这种方法为团队赋予了专用 DNS 管理能力，并减轻了单个团队对 DNS 变更对整个组织中更广泛的 DNS 生态系统的潜在影响。图 1 显示了我们当前在亚马逊云科技和企业数据中心之间进行 DNS 解析的架构。

作为我们已建立和架构的账户配置流程和登录区的一部分，我们会自动在每个新的亚马逊云科技账户中预置 PHZ。我们将此 PHZ 与我们配置它的账户的本地 VPC 关联起来。为了保持一致性和便于识别，我们对这些 PHZ 遵循标准化命名规范：<account-identifier>.aws.example.com

在此命名结构中，"账户标识符" 代表特定亚马逊云科技账户的唯一标识符，而 "example.com" 是我们的内部公司域。例如，对于标识符为 "ABC" 的账户，生成的 PHZ 名称为 abc.aws.example.com。我们对整个生态系统中的所有账户都遵循这种模式。

如下图所示，我们的组织有一个专门的中央网络账户，名为 "网络服务账户"。在这个中央账户中，我们配置了一个名为 "DNS Hub" VPC 的专用 VPC。这个 "DNS 中心" VPC 是我们整个亚马逊云科技环境中 DNS 解析的集中协调中心。

图 1。Northwest Mutual 当前环境显示亚马逊云科技和企业数据中心之间的 DNS 解析

从本地到 Route 53 PHZ 的分辨率

为了促进从本地环境（台式机、服务器等）到 Route 53 PHZ 中托管的 DNS 记录集的 DNS 解析，我们使用了 Route 53 解析器入站终端节点功能。如图 1 所示，我们在专用 "DNS Hub" VPC 中部署了此入站终端节点，以使其全面了解我们的整个私有 DNS 生态系统。

这个 "DNS 中心" VPC 是我们组织内私有 DNS 的集中参考点。除了每个 PHZ 与其账户本地 VPC 关联外，我们还在所有 PHZ 和此 "DNS 中心" VPC 之间建立了跨账户关联。因此，"DNS 中心" VPC 提供了我们亚马逊云科技账户中所有 Route 53 PHZ 的全面视图。

在 "DNS 中心" VPC 中部署的解析器入站终端节点与我们组织中的每个 PHZ 相关联。该协会提供了全面的私有 DNS 视图，包括我们亚马逊云科技生态系统中的所有 PHZ。为了启用本地解析，我们将本地 DNS 服务器配置为将该 *.aws.example.com 域的所有 DNS 查询转发到该集中式解析器入站终端节点。

通过这种架构，我们建立了无缝的 DNS 解析机制，允许我们的本地资源（桌面、服务器等）跨多个亚马逊云科技账户解析托管在 Route 53 PHZ 中的 DNS 记录集。

从 VPC 解析到本地

为了支持从 VPC 中的资源解析本地环境中托管的应用程序的 DNS 记录，我们使用了以下亚马逊云科技服务和组件：Route 53 解析器出站终端节点、Route 53 解析器规则和亚马逊云科技资源访问管理器 (Amazon RAM) 资源共享。有关此架构的直观表示，请参阅图 1。

1. 解析器出站终端节点：我们在专用 "DNS Hub" VPC 中创建了解析器出站终端节点。此出站终端节点充当源自我们的本地 DNS 环境的 VPC 绑定资源的 DNS 查询的网关。
2. 新的解析器规则：我们专门为本地企业域创建了新的解析器规则，并将其 *.example.com 与出站终端节点相关联。此规则的目标 IP 是我们的本地 DNS 服务器 IP。该规则定义了发往我们本地域的 DNS 查询的路由行为。
3. 新的 Amazon RAM 资源共享：为了便于在整个亚马逊云科技组织中共享此解析器规则，我们使用了 Amazon RAM 服务。我们创建了资源共享，并将之前创建的解析器规则作为共享资源。然后，我们将我们的组织指定为与之共享此资源共享的负责人。
4. 规则关联：解析器规则 *.example.com 与我们环境中的所有 VPC 相关联。我们修改了 VPC 构建流程，以确保所有新创建的 VPC 自动与共享解析器规则关联。我们使用亚马逊默认 DHCP 选项，这规定所有绑定 VPC 的资源默认使用 "亚马逊提供的 DNS" 服务，实际上是使用 Route 53 解析器。将共享解析器规则与每个新 VPC 关联可让我们确保在这些 VPC 中启动的资源能够无缝解析我们本地 DNS 环境中托管的 DNS 记录。

亚马逊云科技内账户之间的解析（一个账户中 VPC 中的资源需要解析位于另一个账户 PHZ 中的记录）：

在一个亚马逊云科技账户的 VPC 中的资源和位于另一个账户的 PHZ 中托管的 DNS 记录之间启用 DNS 解析是一项挑战，需要一个独特的解决方案。为了解决这个问题，我们使用了额外的组件，并在现有架构的基础上进行了构建，如图 1 所示。

跨账户查询解析流程依赖于以下关键组件和配置：

1. 解析器规则：我们为该 *.aws.example.com 域创建了新的解析器规则，并将其与前面描述的相同出站终端节点相关联。此规则的目标 IP 地址是 "DNS 中心" VPC 中属于入站终端节点的 IP 地址。
2. Amazon RAM 资源共享：为了在所有账户之间共享 *.aws.example.com 解析器规则，我们创建了新的 Amazon RAM 资源共享，类似于共享本地解析 .example.com 规则的方式。
3. 规则关联：*.aws.example.com 解析器规则与我们环境中的所有 VPC 相关联，就像本地解析 *.example.com 规则一样。

有了这些附加组件后，跨账户查询解析流程的工作原理如下：

1. 当 "ABC" 账户内的 VPC 中的资源尝试解析位于 "XYZ" 账户（例如 "app1.xyz.aws.example.com"）的 PHZ 中托管的 DNS 记录时，将在源 VPC 中引用共享的解析器规则 *.aws.example.com。
2. 解析器规则 *.aws.example.com 规定，匹配的查询通过出站终端节点发出，发往入站终端节点。"xyz.aws.example.com" PHZ 与 "DNS 中心" VPC 相关联，因此入站终端节点会权威地回答查询并向原始资源提供响应。
3. "DNS Hub" VPC 的入站终端节点会回答查询并在 "ABC" 账户中返回对请求资源的响应。

此配置建立了跨账户 DNS 解析机制。它允许一个亚马逊云科技账户中的资源解析另一个账户的 PHZ 中的 DNS 记录。这在我们整个亚马逊云科技环境中创建了一个统一的 DNS 生态系统，涵盖多个账户和私有区域。

挑战

为了充分利用 Route 53 的灵活性，亚马逊云科技建议直接将每个 PHZ 与需要它的 VPC 关联起来，即使在跨账户场景中也是如此。这种方法创建了由 VPC 和托管区域组成的完整网格，在处理数百个 VPC 时，这变得难以管理。

因此，我们寻求了前面描述的替代解决方案，避免了托管区域需要完整的 VPC 网状结构。但是，这种设计带来了一些挑战。DNS 查询需要通过多个解析器终端节点转发才能获得响应，这会增加复杂性，并在可用区 (AZ) 出现性能下降时带来潜在的性能问题。此外，管理 VPC 和托管区域之间的跨账户关联是一个多步骤的过程，涉及托管区域账户和 "Hub" VPC 账户中的操作。尽管我们已经实现了这个过程的自动化，但这仍然是我们希望避免的步骤。

迁移到 Route 53 Profiles/权益

• 更简化的 DNS 查询路由可消除 "跳转" 多个解析器终端节点。借助 Route 53 Profiles，我们可以完全避免在多个终端节点之间跳转，从而实现 VPC 到 VPC 的解决方案。
• 简化了新账号中 Route 53 的设置。我们可以使用 Amazon RAM 共享配置文件，而不必在 PHZ 和 VPC 之间手动创建跨账户关联。我们引用共享的配置文件并将其与新账户的本地 VPC 和 PHZ 关联起来。其余工作由配置文件处理，简化了新账户的注册流程。
• 我们可以利用 Route 53 的内置弹性，有效地将 VPC 与托管区域关联建成 "全网状"，通过 Route 53 Profiles 进行管理。
• 我们使用 Route 53 DNS 防火墙，因为通过 Route 53 Profiles 实现是直接的。以前，我们之所以没有使用 DNS 防火墙，主要是因为将一个规则组分别关联到多个 VPC 会产生开销。

迁移步骤

图 2 代表了我们完成迁移后的环境。为了完成迁移，我们在不影响现有 DNS 解析工作流程的情况下按照以下步骤创建了基础设置：

1. 在网络服务账户中创建 Route 53 Profile。
2. 将网络服务账户下的 "DNS 中心" VPC 与 Route 53 Profile 关联起来。
3. 将 Route 53 解析器规则（设置为将 DNS 查询转发到本地 DNS 服务器 IP 和入站终端节点）与 Route 53 Profile 相关联。
4. 使用 Amazon RAM 与组织账户共享 Route 53 Profile。
5. 将我们组织中每个账户的 VPC 与共享的 Route 53 Profile 关联起来。
6. 将我们组织中每个账户的 PHZ 与共享的 Route 53 Profile 关联起来。

接下来，我们将讨论为迁移到 Route 53 Profiles 进行 DNS 解析而采取的步骤。我们在组织中使用单一账户开始迁移，并对其他账户重复了迁移流程。

• 删除了 Route 53 解析器规则 2 与亚马逊云科技托管应用程序的 App1 开发账户中的 VPC 与应用程序 DNS 解析的关联。
• 删除了 App1 开发账户中的 PHZ 与网络服务账户的 "DNS Hub" VPC 的跨账户关联。此 PHZ 以前用于通过入站终端节点将本地应用程序解析到亚马逊云科技托管的应用程序。
• 删除了 Route 53 解析器规则 1 与 App1 开发账户中 VPC 的关联，用于通过出站终端节点从亚马逊云科技为本地托管应用程序进行 DNS 解析。

我们对组织中的其他账户重复了这些步骤，删除了 PHZ 和 Route 53 Resolver 规则与其各自的 VPC 之间的关联。最后，我们删除了与组织共享解析器规则的内容。

图 2。Northwest Mutual 环境显示迁移到 Route 53 Profiles 后亚马逊云科技和企业数据中心之间的 DNS 解析

摘要

我们的组织很高兴将 Route 53 Profiles 纳入我们不断增长的基础亚马逊云科技服务组合。它通过消除对其他一些组件的需求来降低复杂性。此外，它通过有效创建通往我们环境中的 VPC 的 Route 53 私有区域的完整网状来增强弹性。采用该服务还简化了我们的新账户注册流程，我们不再需要向 VPC 协会提供跨账户托管区域。

作者简历