Lambda超时无法处理完DynamoDB全量结果，除迁Fargate外有哪些优化方案？

以下方案均无需迁移到Fargate，仅通过调整现有Lambda架构或搭配周边服务即可解决超时问题：

方案1：Lambda分页递归调用 #

• 核心逻辑：修改原有Lambda，取消全局循环，将nextToken作为Lambda入参传递，每次调用仅处理单页/少量页DynamoDB数据，处理完成后如果存在nextToken，就异步调用自身并传入新的nextToken继续处理后续分页
• 优势：改造成本极低，不需要新增其他服务，每次Lambda运行时长仅需覆盖单页数据处理耗时，完全规避15分钟上限问题
• 改造后代码示例：

def lambda_handler(event, context):
    next_token = event.get("nextToken")
    l, new_next_token = get_list_of_records_from_dynamodb(next_token)
    for record in l:
        # 原有预处理+触发Step Function逻辑
        perform_preprocessing_and_trigger_workflow(record)
    if new_next_token:
        # 异步调用自身处理下一页
        lambda_client.invoke(
            FunctionName=context.function_name,
            InvocationType='Event',
            Payload=json.dumps({"nextToken": new_next_token})
        )

方案2：分页逻辑下沉到Step Function #

• 核心逻辑：把DynamoDB分页遍历的逻辑从Lambda中剥离，放到Step Function的工作流中实现：利用Step Function的原生循环能力，每次循环先调用DynamoDB SDK拉取单页数据，再调用Lambda处理该页数据，循环判断nextToken是否存在直到全量处理完成
• 优势：Step Function标准工作流最长可运行1年，完全不受Lambda时长限制，且所有流程可可视化追踪，出错后可以直接从断点重试，不需要重新扫描全表。你本身已经在使用Step Function，技术栈完全对齐，改造成本很低。

方案3：SQS解耦分页调度和业务处理 #

• 核心逻辑：拆分两个Lambda角色：
  1. 调度Lambda：仅负责遍历DynamoDB分页，将每一页的所有记录或者单条预处理任务推送到标准SQS队列，遇到nextToken就异步调用自身继续推消息
  2. 处理Lambda：配置SQS触发，每次消费1~10条消息，执行预处理+触发Step Function逻辑
• 优势：处理层可以水平并行扩展，全表处理速度比串行快数倍到数十倍，且调度和业务逻辑完全隔离，任意环节出错不会影响全局进度，还可以配置死信队列处理异常消息。

额外优化建议 #

• 预处理环节的重复文件读取可以缓存到Lambda的/tmp目录，避免重复IO耗时
• 触发Step Function时使用异步调用（InvocationType='Event'），不需要等待工作流返回响应，大幅提升单页处理速度

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