AWS Lambda 正在向长时间运行的任务靠近：运行在 Lambda Managed Instances 上的函数，单次执行最长可达 90 分钟，是此前 15 分钟上限的六倍。不过，这不意味着可以让传统同步请求等待 90 分钟；同步请求的限制没有随之改变。选型时，关键不只是“函数能跑多久”，还有调用方如何等待、任务中断后如何恢复。
90 分钟改变了哪些选择
过去，一个预计运行半小时的数据处理任务，很容易因为 15 分钟上限而被拆分，或者转向容器与常驻服务。新的执行时长让部分批处理、文件转换和周期性维护任务有机会继续采用函数模式。
但适用范围要看清：90 分钟针对 Lambda Managed Instances 上运行的函数，不能把它当作所有 Lambda 函数的新默认值。尤其不要把长时间计算直接塞进需要即时响应的 HTTP 请求里。即使后端可以继续工作，客户端、网关和调用链上的超时也可能先结束等待。
把长任务设计成“可提交、可查询”
可以这样实践：让 API 接收任务并返回任务 ID，由后台异步执行；调用方随后查询状态或接收完成通知。执行函数还应定期保存进度，使重试不必从头开始。
下面的命令演示如何异步调用一个已部署的函数。运行前，将 my-long-job 换成你的函数名，并确认该函数及其运行环境适用于你的目标执行时长。异步调用只说明调用方不等待执行完成，不会自动把函数的时长上限提高到 90 分钟。
aws lambda invoke \
--function-name my-long-job \
--invocation-type Event \
--cli-binary-format raw-in-base64-out \
--payload '{"job_id":"job-2025-001","input":"s3://my-bucket/input.csv"}' \
/tmp/lambda-invoke-response.json
cat /tmp/lambda-invoke-response.json
这条命令也不提供可靠的最终任务状态。生产环境中，可以用持久化存储记录 job_id、处理进度、完成结果和错误，并定义重复提交与重试的处理方式。
时长增加，不等于可以忽略故障
运行越久，越要明确超时、外部服务失败和部分结果的处理策略。一个实用检查清单是：
- 留出收尾时间：不要把工作量排到执行时限的最后一秒。
- 保存可恢复的进度：检查点应放在持久化存储中，而不是只放在进程内存或临时文件里。
- 让步骤尽量幂等：任务重新执行时，避免重复写入或重复扣费。
- 计算总成本：比较执行时间、资源占用和运维复杂度，而不只比较是否需要维护服务器。
90 分钟让 Lambda 能覆盖更多长任务，却没有抹平函数调用与传统服务之间的差异。如果任务需要持续对外提供连接或紧密控制进程生命周期，常驻服务或容器仍可能更合适；如果任务有明确起点和终点、可以异步提交且能够恢复进度，新的时长范围就值得评估。