<!-- AI_TASK_START: AI标题翻译 -->
[新产品/新功能] 引入 Amazon Route 53 在 AWS GovCloud (US) 区域的公共托管区权威 DNS 服务
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 产品功能分析
## 新功能/新产品概述
Amazon Route 53 权威DNS服务现已针对AWS GovCloud (US)区域的公共托管区实现全面可用。该功能允许用户在AWS GovCloud (US)中创建和管理公共托管区，用于处理互联网面向应用的DNS管理，并支持与**Amazon API Gateway**、**Amazon S3**、**VPC接口端点**、**AWS Elastic Beanstalk**和**Elastic Load Balancing**等AWS服务的别名记录。该服务的核心目标是简化操作复杂性，解决合规挑战，帮助美国政府机构和处理敏感数据或Controlled Unclassified Information (CUI)的客户满足监管要求。背景在于，传统上需要使用商业分区管理公共DNS，导致账户管理和凭证切换的负担过重。目标用户群包括政府机构和受监管行业，市场定位聚焦于安全合规和高可用性场景。
## 关键客户价值
- **简化操作和管理**：通过在单一AWS GovCloud (US)控制台管理DNS，减少了在商业分区和GovCloud分区之间切换的需求，降低了人为错误风险，并提升了开发效率，相比传统多分区管理方案显著减少了操作工作量。
- **提升合规性和安全性**：支持**DNSSEC**签名，确保数据完整性和来源认证，帮助客户处理敏感数据时符合监管要求，避免了先前分区隔离带来的合规挑战。
- **与竞品的差异化优势**：相较于其他DNS服务（如Google Cloud DNS），本功能在AWS GovCloud环境内原生集成，减少了跨平台兼容问题，但可能在功能完整性上受限，例如不支持IP-based routing，这在高精度路由场景中需额外规划。
- 在突发流量或多区域应用中，该优势体现为更无缝的AWS服务联动，提升了整体架构灵活性。
## 关键技术洞察
- **技术独特性**：基于**Route 53**的权威DNS架构，实现公共托管区的迁移和管理，支持**别名记录**和**DNSSEC**，工作原理是通过NS记录委托和健康检查监控，确保跨区域DNS解析的稳定性和安全性。
- **技术创新点**：引入了分区迁移策略（如先迁移子区再迁移父区），对性能和可用性影响显著，例如通过**CloudWatch**指标监控实时跟踪流量转移，优化了资源利用率；但在安全方面，**DNSSEC**启用需严格顺序操作，以避免SERVFAIL错误。
- **挑战和解决方式**：迁移过程中可能面临TTL过期等待期（通常2-3天），增加了潜在停机风险；解决方案包括使用测试域验证过程和低TTL值快速回滚，但AWS GovCloud不支持某些功能如Traffic Flow，这可能限制了复杂路由场景的应用。
## 其他信息
- **考虑事项**：在AWS GovCloud (US)中使用Route 53时，需注意不支持IP-based routing和Traffic Flow功能，确保托管区SLA符合组织需求；此外，查询日志和密钥管理需在特定区域（如US-West）配置，以维护最佳实践。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 引入 Amazon Route 53 在 AWS GovCloud (US) 区域的权威 DNS 服务，用于公共托管区
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-route-53-authoritative-dns-service-for-public-hosted-zones-in-aws-govcloud-us-regions/](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-route-53-authoritative-dns-service-for-public-hosted-zones-in-aws-govcloud-us-regions/)
**发布时间:** 2025-05-12
**厂商:** AWS
**类型:** BLOG
---
我们很高兴宣布 [Amazon Route 53](https://aws.amazon.com/route53/) 权威域名系统 (DNS) 服务的正式发布，用于 AWS GovCloud (US) 区域中的公共托管区 (public hosted zones)。现在，您可以在 AWS GovCloud (US) 中创建和管理公共托管区，以管理面向互联网的应用程序的 DNS，并创建别名记录 (alias records)，这些记录指向 AWS 服务，例如 [Amazon API Gateway](https://aws.amazon.com/api-gateway/)、[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)、[Amazon VPC 接口端点](https://aws.amazon.com/privatelink/)、[AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 和 [Amazon Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)。此功能简化了操作复杂性，并解决了合规性挑战，从而帮助客户满足监管要求，同时在同一个 AWS GovCloud (US) 管理控制台中提供无缝体验。
美国政府机构和客户在处理敏感数据和受控未分类信息 (Controlled Unclassified Information, CUI) 时，可能需要满足合规性和监管要求。为满足这些要求，客户使用 Amazon Route 53，该服务提供稳健、安全的 DNS 基础设施来管理面向互联网的关键任务应用程序的 DNS。在此之前，要在 AWS GovCloud (US) 中使用 Amazon Route 53 管理应用程序的公共 DNS，您必须在 AWS 商业分区中使用公共托管区的权威 DNS。这需要维护单独的 AWS 商业账户和 AWS GovCloud (US) 账户。默认情况下，[AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 凭证无法用于访问另一个分区中的资源。因此，您需要为每个分区创建和管理单独的 IAM 凭证（如用户、角色、访问密钥等）。这需要切换不同的控制台来管理每个分区的 Amazon Route 53 配置和资源，这可能很繁琐且容易出错。这也增加了跨两个分区管理 DNS 的操作工作，可能会带来挑战，从而减缓开发速度并在管理 DNS 变更时造成瓶颈。
在本文中，我们将讨论将 Amazon Route 53 公共托管区从 AWS 商业分区迁移到 AWS GovCloud (US) 分区。我们还将讨论迁移公共托管区和健康检查 (health checks) 的最佳实践和注意事项。
## 先决条件
我们假设您熟悉 Amazon Route 53 的公共托管区 (public hosted zones)、[DNS 记录类型](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)、[路由策略](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)、健康检查 (health checks)、[域名系统安全扩展 (DNSSEC) 签名](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html) 以及 [DNSSEC 用于域名注册](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html)。我们还假设您熟悉诸如 [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) (Amazon VPC)、[Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) (ALB) 和 [Network Load Balancer](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) (NLB) 等服务。
## 基线场景
在许多组织中，DNS 管理由中央网络团队和应用程序团队分担，以平衡治理和灵活性。如果每个应用程序团队管理自己的子公共托管区，例如 service1.example.com、service2.example.com，而父公共托管区 example.com 由中央团队管理，那么从商业分区迁移托管区到 AWS GovCloud (US) 需要进一步协调，以确保适当的 DNS 委托、最小停机时间和准确的 DNS 解析。您可以阅读博文 [Amazon Route 53 的 DNS 最佳实践](https://aws.amazon.com/blogs/networking-and-content-delivery/dns-best-practices-for-amazon-route-53/)，了解更多最佳实践。我们建议先迁移子区，然后再迁移父区到 AWS GovCloud (US) 中的 Amazon Route 53 公共托管区，以确保更平滑的过渡。在深入讨论迁移步骤之前，以下部分探讨准备阶段。
### 准备阶段
将公共托管区从商业账户迁移到 AWS GovCloud (US) 账户需要仔细准备。此准备阶段为迁移子区和父区创建蓝图。遵循这些步骤，您可以为整个 DNS 基础设施建立一个可重复的迁移过程。您可以使用商业分区中配置的现有健康检查来用于 AWS GovCloud (US)。如果您不计划使用相同的健康检查，则必须在 AWS GovCloud (US) 分区中重新创建现有健康检查。对于子区和父托管区共有的详细准备步骤，请参考 [AWS 文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-migrating.html#hosted-zones-migrating-prepare) 中的 Amazon Route 53 迁移部分。
在尝试任何 DNS 迁移之前，首先使用测试域名验证流程。DNS 变更可能影响应用程序可用性，因此使用非生产域名进行测试有助于确保生产工作负载的平滑过渡。
## 从商业分区迁移到 AWS GovCloud (US) 中的 Amazon Route 53 公共托管区
在本节中，我们将指导您迁移 example.com 父区（通过 Amazon Route 53 Domains 注册）和 commercial 账户中的 service.example.com 子区。父公共托管区 example.com 还包含指向子区的 NS 记录，以委托子域名 (delegate subdomains)。每个父区和子区都启用了 DNSSEC，以确保数据来源认证和数据完整性验证。
在我们的示例中，commercial 账户中的子区 service.example.com 包含三个记录：
1. **A 记录**，指向一台 Web 服务器。
2. 主 **CNAME 记录**，指向 AWS GovCloud West 中的 ALB，并配置了故障转移路由策略。该主记录与 commercial 账户中创建的健康检查相关联。
3. 次要 **CNAME 记录**，指向 AWS GovCloud East 中的 ALB。
图 1 显示了 service.example.com 子公共托管区中的记录列表。
*图 1: commercial 账户中 service.example.com 公共托管区中的记录*
commercial 账户中的父区 example.com 包含五个记录：
1. **NS 记录**，指向 service.example.com 子区，用于子域名委托。
2. service.example.com 区的 **DS 记录**。
3. **Alias A 记录**，指向 NLB。
4. **Alias AAAA 记录**，指向 NLB。
5. **SOA 记录**，标识域的基本 DNS 信息。
图 2 显示了 example.com 父公共托管区中的记录列表。
*图 2: commercial 账户中 example.com 父公共托管区中的记录*
根据现有公共托管区中记录变更的频率，有两种迁移策略。本文重点讨论记录变更不频繁的公共托管区。这种迁移是自愿的，您可以继续在商业分区中使用 Amazon Route 53 公共托管区来管理 AWS GovCloud (US) 分区中的资源。对于记录变更频繁的情况，我们建议在迁移期间暂停记录变更，并修改应用程序以在旧托管区和新托管区中发布记录变更，直至委托转移。如果您需要有关频繁记录变更托管区迁移的额外指导，请联系 [AWS 支持](https://aws.amazon.com/premiumsupport/) 以获取特定迁移协助。在将公共托管区从商业账户迁移到变更不频繁的 AWS GovCloud (US) 账户时，请遵循以下推荐步骤。
## 迁移 service.example.com 子公共托管区的演练
以下六个步骤将指导您迁移 service.example.com 子公共托管区。
### 步骤 1: 在 commercial 账户中为 service.example.com 子公共托管区禁用 DNSSEC
在迁移启用了 DNSSEC 的域（如 example.com 和 service.example.com）时，执行步骤的顺序至关重要。域注册中父区的委派签名器 (DS) 记录确保子区正确进行 DNSSEC 验证。
[禁用 DNSSEC 签名](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-disable.html) 对于 commercial AWS 分区中的 service.example.com 涉及两个操作：
1. [删除子区 service.example.com 的 DS 记录](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html) 从 commercial 账户中的父区 example.com 中。这一步可防止子区迁移到 AWS GovCloud (US) 账户时出现 DNSSEC 验证失败。您必须联系父区所有者以删除 DS 记录。
您必须等待 DNS 解析器更新其缓存。此等待期通常为两天，在此期间删除记录的生存时间 (Time-to-Live, TTL) 过期。您可以使用 dig 命令确定记录的 TTL，如 [此文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-disable.html) 中的示例所示。如果在 TTL 完全过期前继续，可能导致 service.example.com 在互联网上不可用。
2. TTL 过期后，通过导航到 commercial 分区的 [AWS Management Console](https://aws.amazon.com/console/)，为 service.example.com 子区禁用 DNSSEC 签名（见图 3）。
如果您在删除 DS 记录前禁用 DNSSEC 签名，则域可能在互联网上不可用。
*图 3: 为 service.example.com 子区禁用 DNSSEC 签名*
### 步骤 2: 在 AWS GovCloud (US) 账户中为子区创建公共托管区
在此步骤中，您[为子区 service.example.com 创建一个新公共托管区](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html) 在 AWS GovCloud (US) 账户中（见图 4）。创建托管区后，[记录 Amazon Route 53 与您的托管区关联的四个名称服务器](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/GetInfoAboutHostedZone.html)。在稍后步骤中，更新域注册以使用这些名称服务器。
*图 4: 在 AWS GovCloud (US) 账户中创建公共托管区*
此时，开始监控您新创建的子公共托管区，以通过[配置公共 DNS 查询](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html) 记录公共 DNS 查询的信息。要在控制台上获取 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指标，您必须选择 AWS GovCloud (US-West) 作为区域。
### 步骤 3: 迁移健康检查
Amazon Route 53 健康检查服务存在于商业分区和 AWS GovCloud (US) 分区中。两个健康检查分区都可以针对 AWS GovCloud (US) 中公开的端点进行健康检查。您可以使用任一分区创建健康检查，但这需要仔细规划，以确定您希望健康检查集成的 AWS 服务。Amazon Route 53 在 AWS GovCloud (US) 分区中支持所有[三种类型的健康检查](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html)。当您配置健康检查监控 AWS GovCloud (US) 中的端点时，Amazon Route 53 健康检查器默认使用 AWS GovCloud West 和 East 区域发送健康检查请求。您无法在 AWS GovCloud (US) 分区中选择健康检查器区域。要从 commercial 账户迁移健康检查到 AWS GovCloud (US) 账户，您可以遵循这些步骤：
1. 在 AWS GovCloud (US) 分区中创建新的健康检查
2. 确认端点可从 AWS [GovCloud (US) 检查器 IP](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) 访问，因为这些 IP 与商业分区不同
3. 验证健康检查行为符合预期
4. 将健康检查与记录关联
在我们的示例中，您为 ALB 端点创建健康检查。然后，在下一步中，将此健康检查与记录关联。
### 步骤 4: 在 AWS GovCloud (US) 账户中的新子区中创建记录
在新 AWS GovCloud (US) 托管区为子区创建后，您可以使用控制台或 AWS CLI 从 commercial 账户在 AWS GovCloud (US) 账户中为 service.example.com 区创建 DNS 记录。或者，您也可以使用 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-recordset.html) 或 [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_route53-readme.html) 创建这些记录。如果您在准备阶段之前通过编程方式导出了记录，则使用[导入说明](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-migrating.html#hosted-zones-migrating-old-to-new) 简化传输。在我们的示例中，您手动[创建](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html) service.example.com 区中的一个 A 记录和两个 CNAME 记录。创建所有这些记录时，必须使用 60 秒到 900 秒之间的低 TTL 值，因为这有助于在迁移过程中发现问题时快速回滚。然后，将步骤 3 中的健康检查 ID（AWS GovCloud (US) 账户中的健康检查 ID 不同）与主记录关联。图 5 显示了 AWS GovCloud (US) 账户中此新创建的子区中的记录列表。
*图 5: AWS GovCloud (US) 账户中 service.example.com 子公共托管区中的记录*
要确认您在新托管区中成功创建了所有记录，我们建议您列出新托管区中的记录，并将其输出与旧托管区中的记录列表进行比较。您可以使用 [此文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-migrating.html#hosted-zones-migrating-compare) 中的过程来列出并比较托管区中的记录。
### 步骤 5: 更新父区 example.com 以使用新子区的名称服务器
要为 service.example.com 路由互联网流量，请更新 example.com 父区中的 NS 记录，将其指定为子域 service.example.com 的委托。对于 NS 记录值，指定步骤 2 中 service.example.com 子区的名称服务器名称。图 6 显示了父区中子区的更新 NS 记录，该记录使用子区的名称服务器。
*图 6: 使用子区名称服务器更新父区中子区的 NS 记录以进行子域名委托*
您可以使用 CloudWatch 监控通过新 AWS GovCloud (US) 名称服务器的 service.example.com 区 DNS 解析服务，使用 [CloudWatch 指标](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-hosted-zones-with-cloudwatch.html) 和 [查询日志](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html) 跟踪性能指标、识别潜在问题，并验证所有服务的稳定 DNS 操作。您可以通过验证查询被新基础设施正确响应并确保所有记录类型的正确解析来实时跟踪流量转移。观察 DNS 查询指标开始在新托管区上为 AWS GovCloud (US) 账户中的 service.example.com 发布，而 commercial 账户中旧托管区的指标逐渐减少。此外，您可以查看查询日志以确认未观察到针对 AWS GovCloud (US) 账户中子区的 SERVFAIL 或其他错误。
### **回滚**
如果检测到任何 DNS 解析或应用程序连接问题，请保留快速 revert 到 commercial 账户中 service.example.com 的原始名称服务器的能力。保持 commercial 账户中的先前公共托管区处于活动状态，直至确认通过新 AWS GovCloud (US) 基础设施的稳定操作。
### 步骤 6: 迁移后任务
在确认子区 service.example.com 已迁移且流量正常流动后，请执行以下操作：
1. 将子区中 AWS GovCloud (US) 账户中的 DNS 记录的 TTL 值更改为更典型的数值，例如 172800 秒（两天）。
2. 在确认扩展的 DNS 稳定性且确信不再需要旧托管区后，可选择从 commercial 账户中删除它。有关说明，请参阅 [删除公共托管区](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DeleteHostedZone.html)。
如果您未在 commercial 账户中使用子区记录的健康检查，则可以删除这些健康检查。
## 迁移 commercial 账户中父区 example.com 的演练
迁移 example.com 是一个关键操作，会影响其所有子域。在开始之前，必须确保所有子区（如 service.example.com）在 AWS GovCloud (US) 账户中正常运行。遵循准备步骤，然后继续 example.com 迁移。
### 步骤 1: 在 commercial 账户中为父区禁用 DNSSEC
当您为 commercial 账户中的 example.com 禁用 DNSSEC 时，必须遵循两个步骤：
1. [删除公共密钥](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html#domain-configure-dnssec-deleting-keys) 然后禁用 example.com 公共托管区的 DNSSEC（见图 7）。我们建议您等待长达三天后再禁用 DNSSEC 父域。这很重要，因为如果 example.com 域启用了 DNSSEC，并且您通过 Amazon Route 53 域名注册商禁用 DNSSEC，则支持 DNSSEC 的 DNS 解析器会向客户端返回 SERVFAIL 错误，从而客户端无法访问与 example.com 关联的端点。
当 Amazon Route 53 从注册中心收到响应时，我们会向域的注册人联系人发送电子邮件。该电子邮件要么确认已从注册中心的域中删除公共密钥，要么解释为什么无法删除密钥。
如果您使用第三方域名注册商而不是 Amazon Route 53 注册父域，则根据注册商提供的文档删除 DS 记录。
*图 7: 为 example.com 禁用 DNSSEC 签名*
2. 等待两天后，继续[禁用 DNSSEC 签名并停用密钥签名密钥 (KSK)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-disable.html)，通过编辑 KSK 并将其状态更改为非活动（见图 8）。您可以使用 dig 命令确定记录的 TTL，如 [此文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-disable.html) 中的示例所示。
*图 8: 将 KSK 状态更改为非活动*
### 步骤 2: 在 AWS GovCloud (US) 账户中为父区创建公共托管区
按照子区大纲中 **步骤 2: 在 AWS GovCloud (US) 账户中为子区创建公共托管区** 的相同迁移，但针对 commercial 账户中的 example.com 托管区。
### 步骤 3: 在 AWS GovCloud (US) 账户中的新父区中创建记录
按照子区大纲中 **步骤 4: 在 AWS GovCloud (US) 账户中的新子区中创建记录** 的相同步骤，但针对 commercial 账户中的 example.com 托管区。在我们的示例中，您创建指向 AWS GovCloud (US) 区域中 NLB 目标的 Alias A 和 Alias AAAA 记录，但无法选择商业区域中的别名目标。图 9 显示了 AWS GovCloud (US) 账户中新创建的 example.com 公共托管区中的记录列表。
*图 9: AWS GovCloud (US) 账户中 example.com 父公共托管区中的记录*
### 步骤 4: 在您的 Amazon Route 53 注册商中更新 AWS GovCloud (US) 名称服务器
接下来，我们在域注册商中更新 AWS GovCloud (US) 名称服务器，在我们的示例中为 Amazon Route 53。如果您的域由其他提供商注册，则访问其域管理界面。在我们的示例中，导航到 commercial 账户中 Amazon Route 53 下的 **Registered domains**，选择 example.com。导航到名称服务器部分，并用来自父区迁移演练部分步骤 2 的新四个 AWS GovCloud (US) 名称服务器替换当前 NS 记录。
如果检测到任何 DNS 解析或应用程序连接问题，请保留快速 revert 到 commercial 账户中 example.com 的原始名称服务器的能力。保持 commercial 账户中的先前公共托管区处于活动状态，直至确认通过新 AWS GovCloud (US) 基础设施的稳定操作。
### 步骤 5: 重新启用 DNSSEC 签名并建立信任链
在将父区 example.com 从 commercial 账户迁移到 AWS GovCloud (US) 账户后，您可以重新启用 DNSSEC 签名。
1. 为 AWS GovCloud (US) 托管区中的 example.com 启用 [DNSSEC 签名](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)，通过创建新的 [KSK](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html#dns-configuring-dnssec-enable) 并[更新公共密钥](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html#domain-configure-dnssec-adding-keys) 在 Amazon Route 53 Domains 中。
2. 当父域配置完成后，为 service.example.com 配置 DNSSEC，通过启用 DNSSEC 签名并建立父子信任链，以确保完整域层次安全性。
我们建议您遵循初始 DNSSEC 实施期间使用的相同流程。有关详细的分步说明，请参考博文 [Amazon Route 53 DNSSEC 文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html) 和 [使用 Amazon Route 53 配置 DNSSEC 签名和验证](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/)。
### 步骤 6: 测试和验证
最后，此阶段确保 example.com 及其子域成功迁移到 AWS GovCloud (US)，以维护服务的连续性和安全性：
1. 使用各种 DNS 解析器并从不同地理位置执行 example.com 和 service.example.com 的 DNS 解析测试。这验证了全局可访问性和正确委托。
2. 当 AWS GovCloud (US) 中的新公共父区完全运行时，您可以从 commercial 账户中删除父区。如果您已迁移到 AWS GovCloud (US) 账户，则还可以删除健康检查配置。
*图 10: 显示父区和子区 DNS 性能指标的 CloudWatch 仪表板*
## 注意事项
在使用 AWS GovCloud (US) 区域中的 Amazon Route 53 时，与 AWS 商业区域相比，有一些重要差异需要注意：
1. 查看 Amazon Route 53 [服务级别协议](https://aws.amazon.com/route53/sla/) (SLA) 对于 AWS GovCloud (US)，以确保托管区的预期每月正常运行时间百分比符合您组织的规定。
2. 不支持基于 IP 的路由。
3. 流量流 (Traffic Flow) 功能不可用。
4. 与 DNSSEC 签名一起使用的客户管理密钥必须位于 AWS GovCloud (US-West)。
5. 用于查询日志的 CloudWatch Logs 日志组必须位于 AWS GovCloud (US-West)。
6. 当前，我们支持 API Gateway、Elastic Beanstalk、Application Load Balancer、Classic Load Balancer、Network Load Balancer、Amazon S3 网站端点和 VPC 端点的别名目标。其他别名目标不受支持。
## 结论
在本博文中，我们指导您将 Amazon Route 53 公共托管区从商业账户迁移到 AWS GovCloud (US) 账户。此 Amazon Route 53 权威 DNS 的发布，用于 AWS GovCloud (US) 区域中的公共托管区，使我们的政府和受监管行业客户能够从 AWS GovCloud (US) 区域内的位置为公共托管区提供 DNS 查询服务。此功能简化了操作复杂性并解决了合规性挑战，从而帮助客户满足监管要求，同时在同一个 AWS GovCloud (US) 控制台中提供无缝体验。要立即开始，请了解更多关于[从商业分区将您的 Amazon Route 53 公共托管区迁移到 AWS GovCloud (US)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-migrating.html)。
## 关于作者
### Rohit Aswani
Rohit Aswani 是 AWS 的网络领域首席专家解决方案架构师，他帮助客户构建和设计可扩展、高可用、安全、弹性和成本效益高的网络。他拥有东北大学的电信系统管理硕士学位，主修计算机网络。Rohit 还是 AWS 的公共演讲者，并帮助政府机构和合作伙伴采用 IPv6。在业余时间，Rohit 喜欢远足、探索新咖啡店和旅行。
### Rakesh Raghu
Rakesh Raghu 是 AWS 的资深合作伙伴解决方案架构师，专攻网络领域。他与公共部门合作伙伴合作，构建解决方案并提供技术指导，以帮助客户实现业务目标。
<!-- AI_TASK_END: AI全文翻译 -->