Amazon ANS-C01: DNS 与 Route 53 — 学习指南
属于 AWS Advanced Networking Specialty ANS-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
核心概念
DNS 是连接人类友好名称和分布式端点的粘合剂，但在 AWS 中，它成为了一个用于延迟路由、健康感知故障转移和多账户私有名称解析的主动控制平面。Amazon Route 53 通过公有托管区支持权威公有 DNS，并通过私有托管区支持 VPC 范围内的私有 DNS 解析。私有托管区与一个或多个 VPC 相关联，并且仅对源自这些 VPC 或通过 Route 53 Resolver 入站端点的查询返回应答。这种分离式（split-horizon）行为——根据来源为同一名称提供不同应答——允许您为互联网客户端暴露一个公有端点，同时在您的 VPC 内部将同一名称解析为私有 IP。
Route 53 还将路由决策逻辑和主动健康检查集成到 DNS 中。路由策略包括简单（Simple）、加权（Weighted）、延迟（Latency）、故障转移（Failover，主/备）、地理位置（Geolocation）、多值应答（Multi-Value Answer）以及流量流（Traffic Flow，地理邻近和复杂流）。使用 CreateHealthCheck 创建的健康检查允许 Route 53 从 DNS 应答中移除不健康的端点或驱动故障转移记录集；健康检查可通过 HealthCheckConfig 字段进行配置，例如 Type、FullyQualifiedDomainName、IPAddress、Port、ResourcePath、RequestInterval 和 FailureThreshold。由于 DNS 会被解析器和客户端缓存，因此 Route 53 的 TTL 和频繁的健康检查轮询（在特定设置下最低 10 秒）必须与故障转移和加权路由变更的 DNS 传播行为相平衡。
关键服务与配置
在暴露 AWS 资源时，应使用别名（Alias）记录将 DNS 直接指向支持的 AWS 资源，以避免额外的跳数或 CNAME。别名记录使用一个 AliasTarget，它引用 AWS 资源的托管区 ID 和 DNS 名称（例如，一个 Elastic Load Balancer、API Gateway 自定义域、CloudFront 分配或 S3 网站端点）。创建或更改记录是通过 ChangeResourceRecordSets API 完成的；对于编程工作流，请使用带有 UPSERT/DELETE 操作的 ChangeBatch 和用于路由策略标识的 SetIdentifier。对于故障转移，您需要创建两条同名记录，并将 Failover 分别设置为 PRIMARY 和 SECONDARY，每条记录都通过 HealthCheckId 引用一个您用 CreateHealthCheck 创建的健康检查。
对于跨账户和混合 DNS 解析，Route 53 Resolver 提供通过 CreateResolverEndpoint 创建的入站和出站端点。入站端点允许本地解析器将查询转发到 VPC 中（这对于解析私有托管区很有用），而出站端点则让 VPC 资源可以将查询转发到本地 DNS 服务器或其他解析器。解析器规则（CreateResolverRule）允许您将特定域的查询转发到 IP 地址，并且您可以使用 AssociateResolverRule 将规则与 VPC 关联。对于集中式 DNS 架构，您可以在一个中央账户中创建转发规则，并将其与其它账户中的 VPC 进行 AssociateResolverRule 关联，还可以选择使用 AWS Resource Access Manager (RAM) 和 PutResolverRulePolicy 来控制关联。
Route 53 Resolver DNS Firewall 提供基于域的过滤和日志记录功能。您可以使用 CreateFirewallDomainList 创建域列表，使用 CreateFirewallRuleGroup 创建规则组，然后将规则组 AssociateFirewallRuleGroup 到 VPC 以强制执行规则。防火墙规则可以 BLOCK（阻止）、ALLOW（允许）或 OVERWRITE（覆盖）响应，并且您可以将评估日志记录到 CloudWatch Logs 或 S3。使用 CreateFirewallRule 和 PutFirewallRuleGroupPolicy 进行管理并应用有优先级的规则，特别是为了限制通过 DNS 的数据泄露或阻止来自 VPC 附加资源的恶意域访问。
设计模式与权衡
对于高可用、全球分布式的服务，使用基于延迟或地理位置的路由将客户端定向到最近的健康端点，并结合健康检查来移除不健康的区域端点。延迟路由依赖于 Route 53 的区域延迟表，适用于多区域双活（active-active）设计；故障转移路由更适合主备（active-passive）灾难恢复场景，即一次只有一个区域接收流量。加权路由通过为记录分配权重值并使用 ChangeResourceRecordSets 更改它们，来支持渐进式流量切换（蓝绿部署或金丝雀部署）。多值应答路由可以返回多个 IP 以实现客户端负载分配，并且需要健康检查来确保只返回健康的 IP。
私有托管区和解析器端点是多账户、多 VPC 名称解析的典型模式。对于拥有多个业务部门的场景，一个托管私有托管区或解析器端点的中央共享服务 VPC 可以简化管理：创建一个私有托管区并使用 AssociateVPCWithHostedZone 附加服务 VPC，或者运行 Route 53 Resolver 出站/入站端点和转发规则，这样每个账户在依赖中央 DNS 策略的同时，仍能保持其 VPC 的隔离性。权衡之处在于，与许多 VPC 关联的私有托管区会使 IAM 和变更控制复杂化，并且跨账户关联需要一个授权步骤。解析器转发会带来集中的运营开销，但具有可扩展性，因为您不需要将每个 VPC 直接与每个托管区关联；相反，您只需关联解析器规则。
在强制执行严格的访问路径时——例如要求流量只能通过 Global Accelerator 流入——您必须设计安全组和网络控制来与 DNS 相匹配。Route 53 可以通过创建带有加速器静态 IP 地址的 A 记录或使用 CNAME 指向加速器管理的域来指向 Global Accelerator，但强制执行是在 ALB 安全组和网络 ACL 层完成的。ALB 安全组应仅允许来自 Global Accelerator 静态 IP 地址的入站流量；Global Accelerator 保证这些静态 IP 将是传入流量的源头，因此限制入站流量可以维护“仅通过加速器访问”的要求。
常见陷阱与决策标准
一个典型的陷阱是认为 Route 53 的健康检查会立即移除端点；DNS 缓存（TTL）和客户端解析器的行为意味着故障转移并非瞬时完成。对于关键的故障转移域名，应保持较低的 TTL，但请记住，较低的 TTL 会增加查询量和成本。另一个常见的错误是在不了解 VPC 关联的情况下，在公有和私有托管区中复制域名：与公有托管区同名的私有托管区会为源自关联 VPC 的查询屏蔽公有答案，这对于分离-水平（split-horizon）DNS 来说通常是期望的行为，但如果没有文档记录，可能会出乎意料。
请仔细选择 Alias 记录和 CNAME 记录：对于 ELB 和 CloudFront，Alias 记录是更优选的，因为它们避免了额外的 DNS 查询，并且受到 Route 53 变更传播逻辑的支持，但它们与 AWS 资源的托管区 ID 绑定，不能用于任意外部端点。在设计跨账户 DNS 时，如果关注扩展性或管理边界，应优先选择解析器规则和端点，而不是将许多 VPC 直接关联到单个私有托管区；解析器规则提供了更精细的控制，并且更容易使用 CloudTrail 进行审计。
实践问题：用例场景
公司：NimbusPay — 挑战：为 EKS 后端提供安全的、低延迟的、基于 TLS 的 gRPC 服务，并支持双向 TLS；强制 Web 前端只能通过 Global Accelerator 访问；并允许多个跨账户的业务单元 VPC 使用集中化的 DNS 控制来消费共享数据服务。
- 对于需要端到端 TLS、双向认证和数千个并发连接的 gRPC 服务，应部署一个 Network Load Balancer (NLB)，其在 443 端口上使用 TCP 侦听器，并将目标类型设置为
ip，以便 Pod IP 被直接注册。配置 AWS Load Balancer Controller 的注解
undefined
并将目标组协议设置为 TCP；不要在 NLB 上终止 TLS（即不使用 TLS 侦听器），以便将双向 TLS 请求直通到 Pod 容器中，在容器内强制执行服务器证书和客户端证书验证。使用指向 NLB 的 Route 53 A 记录 (Alias)，通过
undefined
进行设置；仅在需要快速故障转移时才选择低 TTL，否则为了 DNS 的稳定性应保持一个保守的 TTL 值。
为确保 Web 前端 ALB 只接受来自 Global Accelerator 的流量，应预置一个加速器，并将其两个静态 IP 地址分配给 NimbusPay。配置 Route 53 公有记录，将公共域名解析到加速器的 IP（使用包含静态 IP 的 A 记录）。在 ALB 上，设置安全组的入站规则，只允许这些静态 IP 地址，并关闭 0.0.0.0/0。这强制要求只有来自加速器静态 IP 的流量才能到达 ALB。使用 CloudWatch Logs 和 VPC Flow Logs 来验证传入的源 IP，并审计非加速器流量是否被阻止。
对于多个跨账户的、需要访问共享服务的业务单元 VPC，应在共享服务账户中使用
undefined
部署一个中央 Route 53 Resolver 出站/入站端点对，并将这些端点放置在私有子网中。在共享账户中为共享服务域创建转发规则（
undefined
），并使用 AWS RAM 共享这些规则，或使用
undefined
允许关联。每个业务单元将其 VPC 与该解析器规则关联（
undefined
），从而实现域名解析，而无需将所有 VPC 直接附加到私有托管区。对于敏感控制，可以将 Route 53 Resolver DNS Firewall 规则组（
undefined
和
undefined
）附加到共享 VPC，以阻止不必要的数据外泄或强制执行域名白名单。基本原理：NLB TCP 直通模式保留了双向 TLS，并能扩展到大量并发连接；将 ALB 的入站流量限制为 Global Accelerator 的静态 IP，强制实现了“只能通过加速器访问”；而带有集中管理规则的解析器端点，则可以在跨账户扩展 DNS 解析的同时，保留每个账户的 IAM 边界和审计能力。
← Transit Gateway 与网络拓扑 · 所有领域 · 负载均衡与流量管理 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →