将多账户 DNS 环境迁移到 Amazon Route 53 配置文件

作者：Amit Narang, Anandprasanna Gaitonde 和 Ankush Goyal 2024年8月19日发表于 ，， 分享

关键要点

在多账户环境中，Amazon Route 53 Profiles 使 DNS 配置管理变得更加简单和高效。本文介绍了如何将 DNS 环境迁移到 Route53 Profiles，并将两种常见的 DNS 设置迁移场景进行了详细探讨。

引言

大型企业通常会有一个集中式网络团队，负责在多账户、多 VPC 环境中配置和管理基本的 DNS 设置。 提供了简化 DNS 配置管理的能力，使得多个 VPC 及 AWS 账户的管理变得更加高效。在此功能推出之前，用户需要进行关联 (PHZ) 和 Route 53

与 VPC，尤其是在跨账户的情况下。因此，客户需要使用 API 自动化构建复杂的过程，以便在组织内部对新创建的账户和 VPC 自动执行 PHZ 和 Route 53 解析器规则的关联。借助 Route 53 Profiles，客户只需管理一个对象，即可将其 DNS 配置分组，并共享至其他账户以及与 VPC 关联。

本文将介绍迁移到 Route 53 Profiles 的方案，以应对不同客户的 DNS 设置场景。

客户环境中的 DNS 设置

拥有多账户和多 VPC 环境的客户通常会采用两种方式来设置他们的环境。第一种方式是将所有 PHZ保持在一个集中式的网络账户中，第二种方式是每个应用程序所有者在各自的账户中管理其自己的 PHZ。这两种架构均支持在 AWS 环境内以及 AWS和本地资源之间进行 DNS 解析。接下来的部分，我们将详述这两种方法及客户如何迁移到 Route 53 Profiles。

我们从三个应用账户（App1 Dev Account、App2 Dev Account 和 App1 ProdAccount）以及一个网络账户开始，如下图所示。

• App1 Dev Account 运行的开发应用程序使用 PHZ dev.app1.example.private
• App2 Dev Account 运行的开发应用程序使用 PHZ dev.app2.example.private
• App1 Prod Account 运行的生产应用程序使用 PHZ prod.app1.example.private

这两个开发应用程序需要相互交互，以向用户提供功能。在这两种场景中，本地环境通过 AWS 或 AWS 连接到 AWS。一个域为 dc1.onprem.private 的应用程序运行在本地。本地 DNS 服务器更新为将任何针对 *.example.private 的 DNS 查询转发至 Route 53 解析器上传入端点。

网络账户中的 PHZ

![图 1：网络账户中的多账户 AWS删除)

在此设置中，网络管理员为不同的应用程序创建了 PHZ，诸如 dev.app1.example.private (PHZ-1) 和 dev.app2.example.private (PHZ-2) 用于开发应用程序，以及 prod.app1.example.private (PHZ-3) 用于生产应用程序，均位于网络账户中。PHZ-1 和 PHZ-2 分别与 App1 和 App2 Dev Account VPCs 关联，PHZ-3 则与 App1 Prod Account VPC 关联。Route 53 解析器的入站和出站端点被设置在网络账户中的 VPC 中。Route 53解析器规则同样在网络账户中设置，并通过 (AWS RAM) 共享给其他账户。成员账户的 Route 53 解析器规则与各自应用 VPC关联，以便将针对本地的查询通过出站端点发送至外部。这种方法在文章中也有提到。

成员账户中的 PHZ

![图 2：成员账户中的多账户 AWS删除)

在此设置中，网络管理员在网络账户中管理转发规则，并在网络账户的 VPC 中创建 Route 53 解析器端点。然而，每个应用团队在他们的账户中创建自己的 PHZ，并与他们自己的 VPC 及中央账户的 VPC 关联。PHZ dev.app1.example.private (PHZ-1) 在 App1 DevAccount 中创建，dev.app2.example.private (PHZ-2) 在 App2 Dev Account 中创建，而 prod.app1.example.private (PHZ-3) 则在 App1 Prod Account 中创建。为了确保 AWS账户中的应用可以解析本地应用 DNS，设置了 Route 53 解析器规则，以将与 *.dc1.onprem.private 相关的 DNS 查询转发至本地 DNS 服务器。这些规则通过 AWS RAM 与成员账户共享。

这种方法在文章中描述为。

前述设置的扩展性考虑

随着新账户和 VPC 的增加，环境不断扩大，管理员需要考虑以下几点：

1. 集成新账户和 VPC 需要多个步骤，这涉及与各个账户所有者和应用团队的协调。这些步骤包括将相关 PHZ 与新 VPC 关联、通过 AWS RAM 共享 Route 53 解析器规则，以及根据环境（如生产或非生产）选择性应用 PHZ。对于大环境而言，该过程可能繁琐且容易出错。
2. 在“成员账户中的 PHZ”场景下，依赖于出站和入站 Route 53 解析器端点将 DNS 查询从 VPC 资源传输到 AWS 内部的其他资源，随着 DNS 查询数量的增加，可能导致可扩展性问题和成本增加。

移动到 Route 53 Profiles

Route 53 Profiles 旨在简化上述架构中的复杂性。此功能为网络管理员提供了一种方法，以统一管理所有账户和 VPC 的 DNS，如文章中所描述的。Route53 Profiles 可以将 DNS 配置（例如 Route 53 PHZ 关联、Route 53 解析器转发规则和 DNS防火墙规则）分组成一个容器。管理员可以将该配置容器应用于同一 中的多个 VPC。可以通过 AWS RAM 在账户之间共享 Route 53Profiles。一旦 Profile 与 VPC 关联，它将根据 Profile 的设置响应 VPC 的 DNS 查询。如果 PHZ 与 VPC关联，并且包含该 PHZ 的 Profile 也与同一 VPC 关联，则 DNS 查询通过 PHZ的直接关联进行解析。解析器规则也适用同样的逻辑。当针对冲突的域名发起 DNS 查询时，最具体的规则优先。这在文档中有详细描述。在接下来的部分，我们将考察之前讨论的两种架构场景，并展示使用 Route 53 Profiles 的好处及迁移过程。

迁移场景 1：网络账户中的 PHZ

让我们讨论 PHZ 由网络账户而非成员账户管理的场景。PHZ 在网络账户中创建，并与每个应用账户的 VPC 关联。我们将在图 1中讨论的架构基础上进行迁移步骤。请参考 Route 53 以了解如何创建 Route 53 Profiles 并将其与 PHZ 和 VPC 关联至多账户设置中。

迁移的步骤

要开始，请按照以下步骤创建基础设置，而无需影响现有的 DNS 解析工作流：

1. 网络账户中的 Route 53 Profiles。在我们的示例中，我们创建了两个 Route 53 Profiles，DevApp 和 ProdApp，每个环境一个。
2. PHZ-1 和 PHZ-2 与 Route 53 Profiles：DevApp，PHZ-3 与 Route 53 Profiles：ProdApp。
3. ：与 App1 Dev 和 App2 Dev Account 共享 DevApp，并使用 AWS RAM 与 App1 Prod Account 共享 Route 53 Profiles：ProdApp。
4. 应用账户中的 VPC 与每个账户中共享的 Route 53 Profiles。
5. 在网络账户中的 Route 53 解析器规则与两个 Route 53 Profiles 关联。

确保 VPC 关联、PHZ 和规则与 Profile 的关联显示为完成状态，再进行下一部分。

![图 3：从网络账户迁移到 Route 53删除)

现在，让我们讨论如何迁移到 Route 53 Profiles 进行 DNS 解析。建议从一个账户开始，然后重复该过程以适应其他账户。

• 从 App1 Dev Account 中移除 PHZ 与应用 DNS 解析的 VPC 关联。
• 移除与 App1 Dev Account VPC 的 Route 53 解析器规则的关联，以实现通过出站端点进行 AWS 提供的应用程序的 DNS 解析。一旦完成，可以选择删除 Route 53 解析器规则-1 的共享。

重复这些步骤，移除 App2 Dev Account 和 App1 Prod Account 的 VPC 中的 PHZ 和 Route 53解析器规则关联。

完成创建基础设置并实施使用案例的步骤后，架构应类似于以下图所示。

![图 4：使用 Route 53 Profiles 的多账户 DNS删除)

迁移场景 2：成员账户中的 PHZ

接下来，让我们讨论 PHZ 由每个应用账户自己管理的场景。在此，PHZ 在每个应用账户中创建，并与中央网络账户的 VPC 关联。我们从图 1中开始并进入以下部分的迁移步骤。请参考 Route 53 以了解如何创建 Route 53 Profiles 并将其与 PHZ 和 VPC 关联至多账户设置中。

迁移的步骤

要开始，请执行以下步骤以创建基础设置，而无需影响现有的 DNS 解析工作流：

1. 网络账户中的 Route 53 Profiles。在我们的示例中，我们创建了三个 Route 53 Profiles，DevApp 和 ProdApp 各一个应用环境，以及一个用于本地连接的 Networking Profile。
2. 网络账户的 VPC 与 Networking Profile。
3. 两个 Route 53 解析器规则，这些规则用于将 DNS 查询转发至本地 DNS 服务器和入站端点，与 DevApp 和 ProdApp Profiles。
4. 给其他应用账户使用 AWS RAM。
5. 应用账户中的 VPC 与共享的 Route 53 Profiles，DevApp Profile 将与 App1 和 App2 Dev 账户的 VPC 关联，ProdApp Profile 将与 App1 Prod 账户的 VPC 关联。
6. 应用账户中的 PHZ 与共享的 Route 53 Profiles。

确保 VPC 关联、PHZ 和与 Profile 的规则关联显示为完成状态，再进行下一部分。

![图 5：从成员账户迁移到 Route 53删除)

接下来，让我们讨论如何迁移到 Route 53 Profiles 进行 DNS 解析。建议从一个账户开始，然后重复该过程以适应其他账户。

• 从 App1 Dev Account 中移除与 AWS 提供的应用程序的 VPC 关联的 Route 53 解析器规则-2。
• 移除 PHZ-1 与网络账户 VPC 的关联，以实现本地通过入站端点的 AWS 提供的应用程序的 DNS 解析。
• 移除与 App1 Dev Account VPC 的 Route 53 解析器规则-1 的关联，以实现从 AWS 通过出站端点进行的本地托管应用程序的 DNS 解析。一旦完成，可以选择删除 Route 53 解析器规则-1 的共享。

重复这些步骤，移除 App2 Dev Account 和 App1 Prod Account 的 VPC 中的 PHZ 和 Route 53解析器规则关联。

完成创建基础设置并实施使用案例的步骤后，架构应类似于以下图所示。

![图 6：使用 Route 53 Profiles 的多账户 DNS删除)

迁移后的好处

一旦完成对 Route 53 Profiles 的迁移，DNS 配置的持续管理将更加简化。

• 管理员可以根据需要的结构来创建 Route 53 Profiles，在网络账户中创建 ProdApp Profile 和 DevApp Profile，并与适当的账户共享。每个账户的所有者/应用团队可以创建他们的 PHZ，并与正确的 Profile 关联，以确保跨账户和跨 VPC 的 DNS 解析。这种关注点的分离减少了协调开销，提高了团队的敏捷性。
• 消除来自 Route 53 解析器端点的内部 AWS 资源的 DNS 流量，从而消除了由 Route 53 解析器端点产生的不必要。

注意事项

1. 尽管迁移到 Route 53 Profiles 是无缝的且不需要停机，但建议首先在测试环境中测试此迁移设置，然后再对生产环境进行更改。
2. 在实施此迁移路径并为您的需求创建多个 Route 53 Profiles 时，请注意，一个 VPC 一次只能与一个 Route 53 Profile 关联。因此，如果在单个 VPC 中有多个工作负载组件，您需要考虑将它们的 DNS 需求封装到单个 Route 53 Profile 中。
3. 如 Route 53 所述，VPC Profiles 按每个 Profile-VPC 关联的小时费率收费。因此，在选择所需的 Profile 数量时，请确保不要太细分，以免导致大量 Profile-VPC 关联的情况。
4. 在任何时候，如果 VPC 同时与 PHZ 和 Route