本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
限制 Amazon Route 53 API 请求
重要
亚马逊 Route 53 更新了其 API 限制行为。此更新包括增加每秒请求数限制和引入基于变化的限制。本页详细描述了更新的限制。
Amazon Route 53 对每个账户的 API 请求进行限制，以维护服务稳定性并确保所有客户的公平使用。Route 53 适用两个独立限制：
-
请求速率：每秒 API 请求数。
-
变更吞吐量：修改 DNS 数据的 API 操作汇总的每秒单个 DNS 记录更改次数。
请求可以受到任一限制的限制。当请求受到限制时，亚马逊 Route 53 会返回 HTTP 400 错误 () Bad request。响应标头还包括一个其值为 Throttling 的 Code 元素，以及一个值为 Rate exceeded 的 Message 元素。
如何应用节流
亚马逊 Route 53 使用代币存储桶算法。每个限额都有一个存储桶，可容纳最大数量的代币。每次请求（请求速率限制）或每次更改（更改吞吐量限制）都会从适用的存储桶中移除令牌。水桶每秒以固定速率重新装满，直至最大容量。如果充值代币在存储桶已满时到达，Route 53 会将其丢弃。
两个值描述了每个存储桶：
-
存储桶的最大容量是您的爆发量：存储桶已满时 Route 53 可以同时吸收的请求或更改数量。
-
存储桶充值率是您的持续速率：您可以无限期保持的每秒请求或更改次数。
您可以在添加代币时使用充值；您无需等待存储桶完全充值。
请求费率代币存储桶大小和充值率
Route 53 在两个级别上应用请求速率限制：
-
账户级别：来自您账户的所有亚马逊 Route 53 API 请求均来自一个存储桶。
-
账户和操作级别：每个 API 操作也有自己的存储桶。
请求消耗两个存储桶中的令牌，如果其中一个存储桶为空，则请求会受到限制。以下操作具有不同的默认请求速率限制。
| API 操作 | 存储桶最大容量 | 存储桶重填速率 |
|---|---|---|
| 所有 Amazon Route 53 API 操作合并（账户级别） | 50 | 10 |
| 下面未列出的任何 API 操作（每个操作的默认值） | 50 | 10 |
AssociateVPCWithHostedZone |
20 | 5 |
ChangeCidrCollection |
40 | 5 |
CreateCidrCollection |
40 | 5 |
CreateHealthCheck |
50 | 0.5 |
CreateHostedZone |
40 | 2 |
CreateReusableDelegationSet |
40 | 2 |
CreateTrafficPolicyInstance |
1 | 1 |
DeleteCidrCollection |
40 | 5 |
DeleteHealthCheck |
15 | 3 |
DeleteHostedZone |
40 | 5 |
DeleteReusableDelegationSet |
40 | 5 |
DeleteTrafficPolicyInstance |
1 | 1 |
DisassociateVPCFromHostedZone |
10 | 5 |
GetHealthCheckLastFailureReason |
4 | 1 |
GetHealthCheckStatus |
4 | 1 |
UpdateHealthCheck |
50 | 5 |
UpdateTrafficPolicyInstance |
1 | 1 |
有关亚马逊 Route 53 API 操作的完整列表，请参阅亚马逊 Route 53 API 参考中的操作。
CreateHealthCheck 请求
您可以每隔 2 秒每个 Amazon Web Services 账户提交一个 CreateHealthCheck 请求。这相当于上表中显示的每秒 0.5 个请求的重新填充率。
更改吞吐量限制
除请求速率限制外，修改 DNS 数据的 API 操作还受变更吞吐量限制的约束。此限制使用单独的代币存储桶，该存储桶的耗尽基于请求进行的 DNS 记录更改的次数，而不是请求的数量。更改吞吐量受每个 API 操作的限制 Amazon Web Services 账户，而不是每个 API 操作的限制。以下所有操作均来自一个存储桶，该存储桶的最大容量为 1,500 次更改（爆发），并以每秒 100 次更改的速度重新填充（持续）。
更改的计算方式如下：
| 操作 | 消耗的代币 |
|---|---|
ChangeResourceRecordSets |
每人 1 个CREATE，每个 1 个DELETE，每个 2 个 UPSERT |
AssociateVPCWithHostedZone |
2 |
DisassociateVPCFromHostedZone |
2 |
CreateHostedZone |
2 |
DeleteHostedZone |
2 |
所有其他 Amazon Route 53 API 操作均不消耗变更吞吐量令牌，并且仅受请求速率的限制。
示例：您可以提交包含 1,000 个更改（一次突发）的单个请求，这将消耗 1,000 个令牌。爆发后，水桶以每秒 100 个代币的速度充满。如果您继续每秒提交 100 次更改，则可以无限期地保持该速率。如果您尝试维持每秒 500 次更改，则存储桶将耗尽，后续请求将受到限制，直到其重新填满。
监控 API 节流
您可以通过观察应用程序日志中的 HTTP 400 响应或通过 CloudWatch 指标跟踪 API 使用情况来监控亚马逊 Route 53 API 的使用情况。当您收到限制错误时，您的请求超过了前面部分中描述的限制之一。
重试和指数回退
当您轮询或重试 API 请求时，我们建议使用指数退避算法来计算请求之间的休眠间隔。指数退避会逐渐延长重试之间的等待时间，以获得连续的错误响应。实现最大延迟间隔和最大重试次数，并考虑添加抖动（随机延迟）以防止连续碰撞。有关更多信息，请参阅构建器库中的
每个 Amazon SDK 都实现自动重试逻辑，包括自适应重试模式，该模式可根据限制调整客户端请求速率。对于经常接近这些限制的工作负载，可以考虑启用自适应重试。有关更多信息，请参阅 Amazon SDKs and Tools Reference Guide 中的 Retry behavior。
申请提高限制
您可以通过 Amazon 支持请求提高 API 请求率或更改吞吐量限制。要申请加薪，请执行以下操作：
-
打开Amazon 支持中心
。 -
创建案例并选择提高服务限额。
-
对于限制类型，选择路线 53 。
-
提供您的当前使用量和所需的限额。
API 限制的最佳实践
-
平衡请求速率与批量大小：如果您受到请求速率限制的限制，请为每个请求发送更多更改。如果您受到变更吞吐量限制的限制，请降低总更改率。无论是非常小的批量还是非常大的批量本身都不是最佳选择。
-
使用批处理实现原子性：单个
ChangeResourceRecordSets请求中的所有更改都是以原子方式应用的，因此它们一起成功或失败。 -
随时间推移分散更改：在几秒钟内均匀分配更改，而不是同时提交大批量更改。
-
依靠突发来偶尔的峰值，而不是持续的吞吐量：突发容量可以容纳合法的流量峰值；它不是持续的运营上限。
-
使用指数退避重试：当您收到 HTTP 400 响应时，延迟时间会随着每次尝试的增加而增加（参见）。重试和指数回退
-
主动提高请求限额：如果您预计工作负载会增长，请在达到限制之前申请提高请求上限（参见申请提高限制）。
有关更广泛的亚马逊 Route 53 指南，请参阅Amazon Route 53 的最佳实践。