使用AWS SDK for JavaScript更新CloudFront分发以删除时遭遇Rate exceeded错误的排查求助

我来帮你分析下遇到的「Rate exceeded」错误，毕竟在操作CloudFront API时，限流问题是很常见的坑，结合你的情况，可能有以下几个原因：

1. 短时间内API调用频率超限 #

CloudFront的UpdateDistribution接口有严格的请求速率限制，虽然你创建分发的功能正常，但更新操作的限额可能和创建不同，或者你在测试/调试过程中短时间内重复触发了多次更新请求（比如循环重试、脚本重复执行），直接触发了AWS的限流机制。

2. 无效请求的重复重试导致限流 #

你配置里使用了IfMatch: distribution.eTag，如果这个eTag不是当前分发的最新值（比如之前的更新已经改变了分发状态，你还在用旧的eTag），每次请求都会返回412 Precondition Failed错误。如果你的代码没有处理这个错误，而是直接重试，就会在短时间内发送大量无效请求，同样触发「Rate exceeded」。

3. 代码逻辑导致的不必要重复更新 #

检查你的代码是否存在逻辑问题：比如每次运行都无条件调用UpdateDistribution，即使分发配置没有任何实际变化。这种无意义的重复请求也会快速消耗你的API调用额度。

对应的解决方案： #

• 实现指数退避重试策略：AWS SDK for JavaScript内置了重试机制，但你可以显式配置指数退避，避免短时间内重复请求。比如初始化CloudFront客户端时：

  const cloudfront = new AWS.CloudFront({
    retryDelayOptions: { base: 1000 }, // 初始延迟1秒
    maxRetries: 3
  });
  

  如果是自定义重试逻辑，记得每次失败后延迟时间翻倍，直到达到最大重试次数。

• 确保使用最新的ETag：每次调用UpdateDistribution前，先调用GetDistribution获取分发的最新信息，拿到最新的eTag再发起更新请求，避免因为eTag过期导致的无效请求。

• 添加请求频率控制：在代码里添加调用间隔，比如如果是自动化脚本，两次更新请求之间至少间隔几秒钟；如果是测试场景，避免连续点击触发多次请求。

• 检查并优化更新逻辑：只有当分发配置确实需要修改时，才调用UpdateDistribution。可以先对比当前配置和要更新的配置，确认有差异后再发起请求。

• 排查账户限额（最后考虑）：如果以上方法都无效，可能是你的AWS账户的CloudFront API限额低于你的需求，可以在AWS控制台的「Service Quotas」里查看并申请提高UpdateDistribution的调用限额，但这种情况比较少见。

内容的提问来源于stack exchange，提问作者aurixel