一個傳統應用程式被遷移到 Lambda function，它在月底執行許多第三方 API 呼叫來提取資料，然後處理這些資料以產生月度報告。第三方供應商引入了限制：每分鐘和每天的 API 呼叫次數是固定的（在回應標頭中提供），超出限制時會返回錯誤。如果應用程式必須限流以避免超出限制，整個資料處理執行可能需要數天。要重構這個無伺服器工作流程以遵守這些限制，最符合操作效率的方法是什麼？

正確答案是使用 AWS Step Functions 狀態機來協調呼叫，因為 Step Functions 提供內建的錯誤處理、重試機制和暫停（Wait state）功能，非常適合處理外部 API 的速率限制。當偵測到速率限制錯誤時，Step Functions 可以暫停執行一段時間，然後自動重試，確保應用程式遵守第三方限制，同時最終完成所有資料處理。 將 API 呼叫任務傳送到 Amazon SQS queue 並讓 Lambda 輪詢，雖然可以實現限流，但需要額外的邏輯來管理延遲和重試，不如 Step Functions 的內建功能操作高效。建立 CloudWatch Logs 指標和警報來停止 Lambda 會導致處理中斷，無法自動恢復，不符合「重構以遵守限制」且「完成資料處理」的需求。使用 Amazon Kinesis Data Firehose 批次處理並傳送到 S3，然後觸發 Lambda，這種方法主要用於資料收集和批次處理，但對於需要即時響應速率限制並延遲重試的場景不適用，且會增加不必要的複雜性。