<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 利用Amazon Route 53 Resolver端点指标扩展混合DNS设置
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
本文档详细介绍了使用 Amazon Route 53 Resolver 端点指标来扩展混合 DNS 设置的核心内容和目标。该解决方案针对企业在混合云环境中管理 DNS 解析时面临的规模挑战，**核心内容** 包括监控 Resolver 网络接口 (RNI) 容量并实现可扩展架构，以确保跨混合基础设施的可靠 DNS 解析。
背景和上下文：随着组织扩展混合云环境，处理多个 Amazon VPC 和 DNS 流量变得必要。传统上，用户依赖 Route 53 Resolver 端点进行无缝 DNS 集成，但流量增长时需增加 RNI。该方案解决的问题是现有 CloudWatch 指标（如 InboundQueryVolume）无法精确反映容量极限，适用于大型多 VPC 环境中的集中式 DNS 中心。技术原理基于新指标 **ResolverEndpointCapacityStatus**，通过 CloudWatch 监控端点使用情况，考虑因素如 DNS 协议、延迟和查询量，提供三状态指示（0：正常；1：警告；2：关键）。
## 实施步骤
1. **设置测试环境**
使用 CloudFormation 部署模板（例如 capacity-usage-test.yaml），创建必要的 VPC、子网和 Resolver 端点。理由：模拟企业条件下的 DNS 流量，确保环境与实际混合架构一致。技术原理：通过 CloudFormation 自动化资源 provisioning，避免手动配置错误。
2. **配置流量生成器**
- 下载并构建 Docker 镜像（mock_dns_traffic.sh 和 Dockerfile），上传至 Amazon ECR。
- 在 Amazon ECS 中创建任务定义，选择 2 vCPU 和 4 GB 资源，指定容器镜像 URI。
理由：使用 ECS 容器化流量生成，便于扩展和隔离。逻辑衔接：镜像准备后，直接部署到 ECS 集群，实现流量模拟。
3. **生成和监控 DNS 流量**
- 在 ECS 集群中运行任务，从 4 个节点开始，每 10 分钟增加 2 个节点，每节点 550 QPS。
- 添加延迟（例如使用 tc qdisc 命令添加 50 ms 延迟到 nameserver）。
理由：模拟真实网络延迟，测试端点容量极限。技术原理：通过 CloudWatch 监控 ResolverEndpointCapacityStatus 指标，捕获状态变化（从正常到警告再到关键）。
4. **分析 CloudWatch 指标**
- 在 CloudWatch 控制台选择 Route53Resolver 指标，监控 ResolverEndpointCapacityStatus 和 InboundQueryVolume。
理由：提供数据驱动的缩放决策，确保负载均衡。逻辑衔接：指标分析后，可设置警报触发自动化缩放。
## 方案客户价值
- **简化容量管理**：该方案使用 ResolverEndpointCapacityStatus 指标消除传统方法的多指标分析复杂性，提供清晰的三状态信号，帮助企业提前识别容量问题，实现可靠 DNS 解析。量化收益：如实验所示，当查询量达约 57,175 时进入警告状态，实现更精确的缩放决策，与传统方案相比减少手动干预。
- **提升混合环境性能**：在多 VPC 和 on-premises 集成中，确保 DNS 查询负载均衡，减少延迟影响。量化收益：实验显示，适当缩放可处理高达 71,485 QPS，避免服务中断，与传统 CloudWatch 指标相比，更全面考虑协议和延迟因素。
- **成本优化**：通过自动化警报和缩放，避免过度配置 RNI，潜在降低资源浪费，与传统方案的经验性决策相比，提供更高效的资源利用机制。
## 涉及的相关产品
- **Amazon Route 53 Resolver**：用于集中式 DNS 管理，在解决方案中作为端点提供 DNS 解析和流量路由。
- **Amazon CloudWatch**：监控指标如 ResolverEndpointCapacityStatus，提供警报和可视化，支持容量决策。
- **AWS Transit Gateway**：连接多个 VPC 和 on-premises 环境，确保 DNS 查询流量的安全传输。
- **Amazon VPC**：作为基础网络结构，支持混合设置中的子网和 peering 连接。
- **Amazon ECS 和 ECR**：用于部署和运行流量生成容器，模拟测试环境。
## 技术评估
- **先进性**：该方案通过 ResolverEndpointCapacityStatus 指标整合多因素（如查询量、延迟和协议），超越传统 CloudWatch 指标，提供更准确的容量信号，符合混合云趋势，支持自动化缩放。优势：简化决策，减少管理员工作量；可行性高，仅需 CloudWatch 配置即可实施。
- **可行性**：适用于大规模企业环境，但需注意 RNI 负载均衡问题，如实验所示，不均衡可能导致部分接口超载。适用范围：理想于混合 DNS 架构，但可能在高延迟网络中受限。
- **优势和限制**：优势在于全面指标计算和易集成；限制包括偶发指标数据缺失（维护期）和对 inbound 端点的负载分布依赖，如果环境复杂，可能需额外监控工具辅助。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 使用 Amazon Route 53 Resolver 端点指标扩展混合 DNS 设置
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-your-hybrid-dns-setup-with-amazon-route-53-resolver-endpoint-metrics/](https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-your-hybrid-dns-setup-with-amazon-route-53-resolver-endpoint-metrics/)
**发布时间:** 2025-07-02
**厂商:** AWS
**类型:** BLOG
---
本文演示如何使用新的 [Amazon CloudWatch (Amazon CloudWatch)](https://aws.amazon.com/cloudwatch/) 指标针对 [Amazon Route 53 (Amazon Route 53)](https://aws.amazon.com/route53/) Resolver 端点进行监控，从而做出明智的扩展决策。我们将展示如何监控 Resolver 网络接口 (RNI) 容量，并实现一个可扩展架构，以确保混合基础设施中的 DNS 解析可靠。
随着组织扩展混合云环境，在本地和 Amazon Web Services (AWS) 网络之间管理 DNS 解析需要考虑处理多个 [Amazon Virtual Private Clouds (Amazon VPCs) (Amazon Virtual Private Clouds (Amazon VPCs))](https://aws.amazon.com/vpc/) 和相应 DNS 流量的规模。AWS 用户依赖 Route 53 Resolver 端点来实现无缝 DNS 集成。然而，随着流量增长，需要向端点添加更多 RNI 来处理增加的负载。这种问题常见于大型多 VPC 环境，其中所有 DNS 流量都通过位于集中式 DNS 中心 VPC 中的 Route 53 Resolver 端点发送。传统上，用户使用 CloudWatch 指标如 `InboundQueryVolume` 和 `OutboundQueryAggregateVolume` 来预测容量挑战，但这些指标可能无法精确指示 Route 53 Resolver 端点何时达到容量极限。
## 客户混合设置的架构
大型企业组织通常为可扩展性和减少管理开销而实施集中式 DNS 架构。图 1 显示了一个示例用户架构，由多个通过 [AWS Transit Gateway (AWS Transit Gateway)](https://aws.amazon.com/transit-gateway/) 连接的 VPC 组成。
图 1: 具有混合 DNS 设置的多 VPC AWS 环境
这通过 [AWS Direct Connect (AWS Direct Connect)](https://aws.amazon.com/directconnect/) 或 [AWS Site-to-Site VPN (AWS Site-to-Site VPN)](https://aws.amazon.com/vpn/site-to-site-vpn/) 连接与本地集成。Route 53 Resolver 端点在指定的中心 VPC 中使用，以集中和简化 DNS 管理。这种集中式方法允许组织在其整个基础设施中保持一致的 DNS 策略、安全控制和监控。随着企业继续推进云迁移计划并将更多关键任务工作负载部署到 AWS，通过这些端点的 DNS 查询量和延迟会显著增加。最初的一对 Route 53 RNI 很快可能无法支持组织扩展的混合生态系统。每个 RNI 可以处理高达 10,000 个每秒查询 (QPS) 的 UDP 查询，但对于 DNS over HTTPS (DoH)，每个网络接口的 QPS 显著降低。查询类型、响应大小、查询响应时间和往返延迟等因素会影响实际 QPS 速率。当达到该限制时，您可能需要增加 RNI 数量来处理查询负载。此扩展方法已在 [AWS 博客文章](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/#:~:text=Resolver%20endpoint%20performance%20and%20adding%20additional%20ENIs) 中介绍，并使用几个 CloudWatch 指标，如 `InboundQueryVolume`、`OutboundQueryVolume` 和 `OutboundQueryAggregateVolume`。
然而，这些指标单独无法准确捕获 Route 53 Resolver 端点的容量使用情况，因为它们不包括延迟和协议等其他影响 RNI 使用因素。Route 53 已推出一个新指标 `ResolverEndpointCapacityStatus`，用于提供信号以指导扩展决策。
## 通过 Route 53 Resolver 端点指标扩展架构
`ResolverEndpointCapacityStatus` 指标旨在提供端点使用情况的整体测量。它是每个端点的指标，并基于端点 RNI 池中所有 [可用区 (AZs) (Availability Zones (AZs))](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 中使用率最高的 RNI 显示结果。在后台，使用计算会纳入影响 RNI 性能的多个因素，如 DNS 协议、延迟和其他相关参数。这种综合方法确保了端点真实容量状态的更准确表示。容量状态通过 CloudWatch 作为 `ResolverEndpointCapacityStatus` 指标公开，每分钟为每个端点报告一次。该指标使用三个级别状态指示器：
* 0 (OK): 端点在正常容量限制内运行
* 1 (Warning): 端点接近容量阈值
* 2 (Critical): 端点已超过推荐容量限制
在 CloudWatch 指标中，您可能偶尔会注意到 RNI 维护期间的缺失数据点。这是预期的行为，可以安全忽略。
此指标的更多细节在 [AWS 文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html#cloudwatch-metrics-resolver-endpoint) 中介绍。
## ResolverEndpointCapacityStatus 指标实战
在本节中，我们展示如何使用新的 ResolverEndpointCapacityStatus 指标来触发扩展操作，并针对入站 Route 53 Resolver 端点进行特殊考虑。
### 实验设置
以下是实验概述，也显示在图 2 中：
* 向名称服务器添加 50 ms 延迟（模拟企业条件）
* 起点: 4 个负载生成节点使用 dnsperf，每个节点 550 QPS
* 每 10 分钟: 添加两个节点
* 总持续时间: 40 分钟
图 2: 用于模拟入站 Resolver 的高容量 DNS 流量和延迟的测试设置
为澄清，我们通过入站 Resolver 发送流量，而不是 Route 53 Resolver，从而模拟针对单个 RNI 的 DNS 查询流量。流量会自动在出站 Route 53 Resolver 的最小两个 RNI 之间负载均衡。然后，我们将流量发送到出站 Route 53 Resolver，以便使用添加延迟的自定义名称服务器。前述设置用于负载测试 Route 53 Resolver 端点上的 DNS 查询流量，并不代表真实场景的架构。
### 设置测试环境
1. 从 [此处](https://github.com/aws-samples/sample-scaling-route53-resolver-endpoints-with-capacity-metrics/blob/main/capacity-usage-test.yaml) 下载 **capacity-usage-test.yaml**。
2. 打开 [AWS CloudFormation (AWS CloudFormation)](https://aws.amazon.com/cloudformation/) 控制台，并使用前述模板部署 **capacity-usage-test.yaml**，按照 [创建 CloudFormation 堆栈](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) 的步骤进行。
3. 堆栈部署后，选择 **Outputs** 选项卡并记下 **InboundEndpointId**。
### 设置流量生成容器
1. 从 [此处](https://github.com/aws-samples/sample-scaling-route53-resolver-endpoints-with-capacity-metrics) 下载 **mock_dns_traffic.sh** 和 **Dockerfile**。
2. 打开 [Amazon Elastic Container Registry (Amazon ECR) (Amazon Elastic Container Registry (Amazon ECR))](https://console.aws.amazon.com/ecr) 控制台。
3. 在 **Repositories** 页面，选择 **Create repository**。
1. 将仓库命名为 **capacity-usage-blog/mock-traffic**。
2. 选择右下角的 **Create**。
4. 选择创建的仓库。
5. 选择右上角的 **View push commands**。
6. 按照屏幕上的步骤上传 **mock_dns_traffic.sh** 的容器到 Amazon ECR。
7. 图像上传后，复制图像 URI。
8. 打开 [Amazon Elastic Container Service (Amazon ECS) (Amazon Elastic Container Service (Amazon ECS))](https://console.aws.amazon.com/ecs) 控制台。
9. 在左侧面板中，选择 **Task Definitions** 页面，然后选择 **Create new task definition**，并选择 **Create new task definition**。
1. 输入 **mock_dns_traffic** 作为任务定义系列。
2. 在 **Task size** 下，选择 **2 vCPU** 和 **4 GB**。
3. 在 **Container – 1** 下，输入名称 **mocker** 和来自步骤 8 的图像 URI。
4. 滚动到底部并选择 **Create**。
### 生成 DNS 流量
1. 打开 [Amazon ECS 控制台](https://console.aws.amazon.com/ecs)。
2. 在左侧面板中，选择 **Clusters** 页面，并选择 **test-capacity-usage-cluster**。
3. 选择 **Tasks**，然后在右侧选择 **Run new task**。
1. 从 **Task family definition** 下拉菜单中选择 **mock_dns_traffic**。
2. 在 **Desired tasks** 下选择四个。
3. 展开 **Networking** 选项卡。
1. 在 **VPC** 下，选择 **on-prem VPC**。
2. 在 **Subnets** 下，选择 **X** 上的 **on-prem-public-subnet** 以删除公共子网。
3. 在 **Security group** 下，选择 **Use an existing security group** 和 **vpc-a-security-group**。
4. 滚动到底部并选择 **Create**。
4. 每 10 分钟重复步骤 1–4，将 **Desired tasks** 设置为 **2**。
### 添加延迟
1. 打开 [Amazon Elastic Compute Cloud (Amazon EC2) (Amazon Elastic Compute Cloud (Amazon EC2))](https://console.aws.amazon.com/ec2) 控制台。
2. 在左侧面板中，选择 **Instances**，然后选择名称为 **nameserver** 的实例。
3. 选择右上角的 **Connect**，选择 **Session Manager**，然后选择 **Connect**。
4. 使用以下命令修改延迟，然后重复 **生成 DNS 流量** 下的步骤：
```
// 添加 50 ms 延迟
sudo tc qdisc add dev ens5 root netem delay 50ms 0ms
// 将延迟恢复为 0
sudo tc qdisc change dev ens5 root netem delay 0ms 0ms
```
### 分析 CloudWatch 指标
1\. 打开 [Amazon CloudWatch 控制台](https://console.aws.amazon.com/cloudwatch)。
2\. 在左侧面板中，展开 **Metrics**，然后选择 **All metrics**。
图 3: Route 53 Resolver 的 CloudWatch 指标
3\. 选择 **Route53Resolver**，然后选择 **By Endpoint**。
图 4: Route 53 Resolver—By Endpoint 的 CloudWatch 指标
4\. 为 **rslvr-in-xxxx** 端点选择 `ResolverEndpointCapacityStatus` 指标。
5\. 在 **Metrics** 下，选择名为 **By Endpoint** 的下拉菜单，然后选择 **Route53Resolver**。
图 5: Route 53 Resolver—ResolverEndpointCapacityStatus 的 CloudWatch 指标
6\. 选择 **Rnild**，然后为两个 RNI 选择 `InboundQueryVolume` 指标。
7\. 选择 **Graphed metrics** 选项卡。在右上角，将 **Line** 更改为 **Number**。
图 6: Route 53 Resolver—graphed metrics 的 CloudWatch 指标
图 7: 入站 Route 53 Resolver 端点随 DNS 查询增加的 CloudWatch 指标 ResolverEndpointCapacityStatus 图
随着您逐步增加查询量，容量状态指标会通过其三个状态进行演进: 从 0 (正常) 到 1 (警告)，最终到 2 (关键)。当一个 RNI 处理平均约 57,175 个查询量时，指标达到警告阈值; 当一个 RNI 处理平均约 71,485 个查询量时，达到关键阈值。您可以设置 CloudWatch 警报，在 `ResolverEndpointCapacityStatus` 指标超出这些阈值时触发。这可用于通知网络管理员或启动自动化工作流以向端点添加更多 RNI。
实验还突出了入站 Route 53 Resolver 端点的关键考虑: 负载均衡。结果显示查询分布存在显著不平衡，一个 RNI 处理平均 71,485 个查询量，而另一个未使用。`ResolverEndpointCapacityStatus` 基于端点下所有 RNI 中使用率最高的 RNI 显示状态。因此，您必须监控 `InboundQueryVolume` 指标，以确保 DNS 查询在所有 RNI 之间有效负载均衡。
`ResolverEndpointCapacityStatus` 指标显著简化了 Route 53 Resolver 端点的容量管理，通过提供清晰、可操作的扩展决策信号。与查询量指标不同，后者需要管理员理解查询量、延迟、服务限制等之间的复杂关系，这种新方法消除了确定适当查询量阈值的猜测。这种简化特别有价值，因为这些因素在不同环境、使用场景和时间中会显著波动。管理员不再需要分析多个指标或理解不同性能指标之间的细微相互作用。相反，他们可以基于这个单一、综合指标自信地启动扩展操作。AWS 已设计此指标以考虑影响端点性能的所有相关因素，从而提供容量管理的简化解决方案。
尽管 `ResolverEndpointCapacityStatus` 指标显著简化了容量管理，但它只是全面 DNS 基础设施策略的一部分。对于希望进一步优化高可用性和性能的组织，还有更多考虑因素。要深入了解设计高可用性的进一步考虑，请转到 [AWS Networking 帖子](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/#:~:text=Resolver%20endpoint%20performance%20and%20adding%20additional%20ENIs)。
### 清理
1. 打开 [CloudFormation 控制台](https://console.aws.amazon.com/cloudformation)。
2. 在左侧面板中，选择 **Stacks**，然后选择 **test-capacity-usage**。
3. 选择 **delete**，然后选择 **delete**。
4. 打开 [Amazon ECR 控制台](https://console.aws.amazon.com/ecr)。
5. 在左侧面板中，选择 **Repositories**，然后选择 **capacity-usage-blog/mock-traffic** 仓库。
6. 选择右上角的 **Delete**，然后选择 **Delete**。
## 结论
本文演示了 CloudWatch 上新指标 `ResolverEndpointCapacityStatus` 如何简化混合云环境中 Amazon Route 53 Resolver 端点的容量管理。我们探讨了实施中心辐射式 DNS 架构的企业如何依赖一个清晰的三状态指示器 (0 – 正常、1 – 警告、2 – 关键) 来监控其 Route 53 Resolver 端点容量。通过我们的实际实验，我们展示了此指标如何在端点接近容量限制时提供早期警告，考虑多个因素，如查询量、网络延迟和协议开销。这种简化方法消除了分析多个指标及其相互依赖性的复杂性。使用 `ResolverEndpointCapacityStatus` 指标，企业可以做出自信的、基于数据的决策，决定何时扩展 Route 53 Resolver 端点，从而确保其扩展的混合环境中 DNS 解析可靠。我们还强调了在 RNI 之间实现适当负载均衡以最大化端点容量和保持最佳性能的重要性。更多信息，请参阅 [使用 Amazon CloudWatch 监控 Route 53 Resolver 端点](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html) 文档。如果您对本文有疑问，请在 [AWS re:Post](https://repost.aws/) 上启动新线程或联系 [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)。
## 作者介绍
### Keith Lee
Keith Lee 是 Amazon Web Services (AWS) 的合作伙伴解决方案架构师。他专注于发展合作伙伴关系并推动新技术采用。他致力于扩展战略关系、识别合作伙伴利用 AWS 解决方案的机会，并促进各种行业中尖端云技术的实施。
### Anandprasanna Gaitonde
作为 AWS 首席解决方案架构师，Anandprasanna Gaitonde 负责帮助客户设计和操作架构良好的解决方案，以成功采用 AWS 云。他专注于 AWS 网络和无服务器技术，在行业垂直领域设计和开发云解决方案。他拥有解决方案架构师专业和高级网络认证，并持有计算机科学工程硕士学位和软件企业管理研究生学位。
<!-- AI_TASK_END: AI全文翻译 -->