一个传统应用程序被迁移到一个 Lambda 函数中，该函数在月末执行许多第三方 API 调用来拉取数据，然后处理这些数据以生成月度报告。第三方提供商引入了限制：每分钟和每天的 API 调用次数是固定的（在响应头中提供），超出限制时会返回错误。如果应用程序必须进行限流以避免超出限制，则整个数据处理运行现在可能需要数天。重构此无服务器工作流以遵守这些限制的最具操作效率的方法是什么？

AWS Step Functions 状态机是编排复杂工作流的理想选择。当第三方 API 返回速率限制错误时，Step Functions 可以利用其 Wait 状态来暂停执行，等待预设时间后再进行重试，从而避免超出 API 限制。这种方法将限流逻辑直接集成到工作流中，实现了操作效率和弹性。 其他选项的不足之处： 将 API 调用任务发送到 Amazon SQS 队列并让 Lambda 轮询：虽然可以实现限流，但需要额外的逻辑来管理轮询速率和重试机制，增加了复杂性。 创建 CloudWatch Logs 指标和警报来停止 Lambda：这种方法是反应性的，只有在达到限制后才停止 Lambda，无法主动预防超出限制，并且停止后需要手动干预或额外的自动化来恢复。 使用 Amazon Kinesis Data Firehose 批量处理请求：Kinesis Data Firehose 主要用于数据流的批量传输，而不是用于主动管理和限制单个 API 调用，它无法直接解决API速率限制问题。