运行状况检查与 DNS 故障转移

Route 53 运行状况检查会持续监控端点的运行状况，包括 Web 服务器、负载均衡器，以及任何可通过互联网访问的 HTTP/HTTPS/TCP 端点。根据运行状况检查结果，Route 53 可以自动更新 DNS 路由，避免将流量发送到运行状况不佳的资源。

运行状况检查按每项检查每月计费。Route 53 的全球运行状况检查器位于多个 Region 中，会同时探测您的端点，从而为运行状况检查本身提供冗余。只有当达到阈值数量的检查器都确认端点失败时，该端点才会被视为运行状况不佳。

端点运行状况检查会使用您选择的协议（HTTP、HTTPS 或 TCP）、端口以及可选路径，监控特定 IP 地址或域名。对于 HTTP/HTTPS 检查，Route 53 会验证端点是否在超时时间内返回 2xx 或 3xx HTTP 状态码。对于 HTTPS 检查，还可以选择验证 TLS 证书。

主要配置选项包括：请求间隔（10 秒或 30 秒——10 秒可以更快地检测到故障，但成本更高）、失败阈值（标记为运行状况不佳前允许连续失败 1–10 次），以及字符串匹配（可选择验证响应正文是否包含特定字符串）。

计算型运行状况检查使用布尔逻辑（AND、OR、NOT）组合多个子运行状况检查的结果。您可以据此根据多个信号定义应用程序级别的运行状况，而无需创建复杂的路由链。

例如：只有 API 服务器检查和数据库检查都通过时，Web 应用程序才处于正常状态。请创建一个 Type 为 AND 的计算型运行状况检查，并引用这两个端点检查。如果任一检查失败，计算型运行状况检查也会失败，Route 53 随后会从响应中移除关联的 DNS 记录。

CloudWatch 告警运行状况检查会将 Route 53 运行状况检查连接到 CloudWatch 告警的状态。如果告警处于 ALARM 状态，则运行状况检查会被标记为运行状况不佳；如果处于 OK 或 INSUFFICIENT_DATA 状态，则会被标记为运行状况良好。

对于位于 VPC 内部的端点（Route 53 的外部运行状况检查器无法访问这些端点），这种模式非常有用。您无需探测私有端点，而是为其创建 CloudWatch 指标和告警，然后根据告警状态确定 Route 53 运行状况检查的结果。此外，还可以根据错误率或队列深度等业务指标执行运行状况检查。

Route 53 运行状况检查器是由 AWS 管理、位于 VPC 外部的服务器，它们通过公共互联网访问端点。标准端点运行状况检查无法访问私有子网中的资源。对于私有端点，请采用以下方法之一：

• 从 VPC 内部发布自定义 CloudWatch 指标（例如来自应用程序的成功/失败信号），创建告警，并使用 CloudWatch 告警运行状况检查
• 使用 CloudWatch 复合告警，汇总 VPC 内部 ELB、RDS 或应用程序的指标

对于私有子网中的数据库、内部负载均衡器和后端服务，这种模式至关重要。

您可以在 Route 53 控制台的 Health Checks 下查看运行状况检查状态，也可以通过 API 查询该状态。Route 53 会将运行状况检查指标发布到 CloudWatch 的 AWS/Route53 命名空间，其中包括 HealthCheckStatus（1 = 运行状况良好，0 = 运行状况不佳）和 HealthCheckPercentageHealthy（报告端点运行状况良好的 Route 53 检查器所占的百分比）。

请针对 HealthCheckStatus 设置 CloudWatch 告警，以便在端点状态变为不健康时接收 SNS 通知，让您能够在值班团队发现 DNS 故障转移已经发生之前及时了解情况。

当 Route 53 检测到 Primary 记录的运行状况检查失败时，它会从 DNS 响应中移除 Primary，并返回 Secondary 的地址。这称为 DNS 故障转移。切换会在评估周期（运行状况检查器失败次数 × 请求间隔）加上记录 TTL 的时间内完成。

例如：请求间隔 = 30 秒，失败阈值 = 3，TTL = 60 秒。最坏情况下的故障转移时间约为 3 × 30 + 60 = 150 秒。设置较低的 TTL（例如 10 秒）和更快的运行状况检查间隔（10 秒），可以将时间缩短为 3 × 10 + 10 = 40 秒。

运行状况检查不仅可以关联到 Failover 记录，也可以关联到 Weighted 记录和 Latency 记录。当 Weighted 记录的运行状况检查失败时，Route 53 会将该记录的流量权重按比例重新分配给运行状况良好的加权记录。当 Latency 记录的运行状况检查失败时，Route 53 会将查询路由到下一个延迟最低且运行状况良好的记录。

这样一来，Weighted 和 Latency 路由策略无需显式的 Failover 记录，也能应对端点故障。一个常见的 SAA-C03 模式是：跨 Region 使用带运行状况检查的 Latency 路由，同时实现性能优化和自动灾难恢复。

使用 Route 53 构建具有弹性的多 Region 主动-主动架构：

1. 为每个 Region（us-east-1、eu-west-1、ap-southeast-1）创建 Latency 记录，并为每条记录配置运行状况检查
2. 当所有 Region 的运行状况都良好时，将用户路由到延迟最低的 Region
3. 如果某个 Region 的运行状况检查失败（应用程序停止运行或无响应），Route 53 会自动将其从 DNS 响应中移除，并将查询路由到下一个最合适且运行状况良好的 Region
4. 当发生故障的 Region 恢复后，运行状况检查通过，Route 53 会将其重新加入轮换

这样无需手动干预，即可实现具有性能优化的全球自动故障转移。

Route 53 运行状况检查器来自 AWS IP 范围 JSON 文件中 ROUTE53_HEALTHCHECKS 部分所列的一组已发布 IP 范围。如果您的端点受到防火墙或安全组保护，并且入站访问受到限制，则必须允许来自这些 IP 范围的流量，运行状况检查才能成功。

另一种方法是使用面向公共网络的端点，将请求代理到私有后端（例如 ALB），并通过该端点执行运行状况检查。ALB 的安全组只需允许 Route 53 IP 范围，而后端的安全组只允许 ALB 安全组，从而保持纵深防御策略。

Route 53 运行状况检查的最佳实践：

• 创建专用的 /health 端点，检查所有关键依赖项（数据库连接、缓存可达性），并且只有在全部正常运行时才返回 200
• 对于关键的生产端点，使用 10 秒的请求间隔，以更快地检测故障
• 在 CloudWatch 中监控 HealthCheckPercentageHealthy——部分故障（只有部分 Route 53 检查器失败）可能表示区域网络问题或间歇性问题
• 对于 VPC 私有资源，根据应用程序指标使用 CloudWatch 告警运行状况检查
• 在生产环境依赖故障转移之前，先在非生产环境中进行测试

请测试您对本课 AWS 解决方案架构师（SAA-C03）相关概念的理解。

在本课中，您学习了：端点运行状况检查器从外部 Route 53 检查器探测 HTTP/HTTPS/TCP，CloudWatch 告警运行状况检查支持监控私有 VPC 资源，以及计算型运行状况检查使用布尔逻辑组合多个信号。DNS 故障转移速度取决于运行状况检查间隔、失败阈值和 TTL。接下来，我们将探讨 CloudFront 分配和源站。