背景与核心变更

Amazon Route 53 近期对其 DNS 管理接口实施了两项重要调整。自 2026 年 7 月 30 日起，所有账户的默认 API 请求速率限制从原先的每秒 5 次提升至 每秒 10 次。与此同时，服务引入了基于变更限流（Change-Based Throttling, CBT）的新模型，以账户为单位衡量 DNS 变更吞吐。该调整立即生效，主要受益于基础设施即代码（IaC）与多账户架构下日益增长的 DNS 自动化需求。

需注意，上述限制仅适用于 Route 53 的 DNS API（托管区域、记录集、健康检查）。Resolver、Profiles 以及域名注册接口仍沿用各自独立的限额。

双维度令牌桶限流模型

Route 53 现在对每账户施加两个相互独立的限流阈值，均采用令牌桶算法：桶以稳定速率填充（持续限额），并具备最大令牌数（突发容量）。任一边界触发即导致请求受限。

请求速率限制

该限制控制账户每秒可发起的 API 调用总量，默认桶容量为 50（突发），持续填充速率为 10/秒。部分操作如 CreateHostedZone 填充率仅 2/秒，CreateHealthCheck 为 0.5/秒。详细分操作表见 官方文档。

变更吞吐量限制

新模型聚焦于实际 DNS 记录修改量，而非调用次数。默认桶容量 1500（突发），持续填充 100 令牌/秒。不同操作消耗令牌数不同：

  • ChangeResourceRecordSets 的 CREATE/DELETE：每变更 1 令牌
  • UPSERT：每变更 2 令牌
  • 关联或取消关联 VPC、创建或删除托管区：各 2 令牌
  • 其余 API 操作消耗 0 令牌

单次 ChangeResourceRecordSets 请求最多可携带 1000 个变更，但会同时消耗两类桶令牌。

场景影响与应对实践

对于 Terraform、AWS CDK 等 IaC 工具用户，通常每次调用变更较少，请求速率提升直接加快部署且减少限流错误；只要总变更低于 100/秒，新模型无额外约束。

批量迁移海量记录时，变更吞吐成为瓶颈。可长期维持 100 变更/秒；若一次性提交 ≤1500 变更，突发容量可完全吸收。建议将变更均匀铺开，例如每请求封装 100 变更、每秒 1 请求，恰好匹配持续速率。

最佳实践包括：

  • 平衡请求频率与批大小：请求受限时增大单批变更（上限 1000），变更受限时降低每秒总变更数。
  • 利用突发应对偶发峰值，而非作为持续吞吐基准。
  • 对 HTTP 400 且错误码为 Throttling 的响应采用指数退避与抖动重试；其他 400 错误属请求非法，不应重试。
  • 监控应用日志中的 Throttling 响应以及时感知限额逼近。

对读者的意义与技术解读

尽管本站核心关注网络诊断与 DNS 查询等场景，但 Route 53 的限流演进对运维与 SRE 具有横向参考价值。首先，令牌桶模型清晰分离了“调用频次”与“实际工作负载”，这种设计提醒我们在编写 DNS 自动化脚本时，不能仅关注 API 调用次数，还需核算记录变更量，尤其是在混合使用 UPSERT 与批量操作时。其次，对于依赖公有云 DNS 的站点，理解服务商端的限流机制有助于排查“诡异”的部署失败——当 CI/CD 流水线报出 400 Throttling 却调用量不高时，很可能是变更吞吐超限。最后，突发容量不应被视为常态吞吐，在规划大规模 DNS 迁移时，应以持续速率（100 变更/秒）为基准排期，避免误用突发导致后续请求被掐断。这些思路同样适用于自建 DNS 系统或私有解析服务的配额规划。