Lambda 的 15 分钟限制为何是 15 分钟 - 隐藏在无服务器设计约束中的合理性
本文从多租户运营和执行环境生命周期的角度，讲解 Lambda 的最长执行时间 15 分钟、内存上限 10 GB、负载 6 MB 等无服务器各类限制的当前值。同时讲解这些限制如何影响架构设计。
限制不是约束，而是设计决策
开始使用 Lambda 的开发者首先面对的，就是各类限制（Limits）。最长执行时间 15 分钟、内存 128 MB 到 10,240 MB、同步调用的负载 6 MB、部署包 250 MB（解压后）是代表性的值（截至 2026 年 8 月 / 基于官方的配额列表）。AWS 并未公布这些值是如何确定的。因此，下文所述并非官方的设计依据，而是从多租户环境中的资源公平性、运维的安全性、成本效率这些角度能够解读出的合理性。Lambda 是一项在同一物理基础设施上运行众多客户函数的多租户服务。如果 1 个函数无限制地消耗资源，就会影响其他客户的函数。限制是防止“吵闹邻居问题”的护栏，同时也是塑造无服务器设计范式的有意约束。正因为有限制，开发者才会把处理拆分成小的单元，设计出事件驱动、松耦合的架构。
15 分钟限制的历史与背景
Lambda 于 2014 年推出时，最长执行时间仅为 60 秒。在 2015 年 10 月的 re:Invent 2015 上延长到 5 分钟，并于 2018 年 10 月提高到现在的 15 分钟。这种逐步的延长反映了客户用例的扩大，以及 AWS 方面基础设施优化的进展。不过，关于“为何停在 15 分钟”，找不到 AWS 说明决定依据的官方资料。以下并非公布的设计理由，而是对这一上限在实际工作中如何起作用的梳理。第一，是与执行环境生命周期的关系。Lambda 函数在基于 Firecracker 的 MicroVM 上准备的执行环境中运行，这些执行环境虽然会跨调用重复使用，但并不是永久的。由于执行时间有上限，自然会强制采用不在本地磁盘或全局变量中保留状态的设计。第二，是故障检测与恢复的角度。如果函数持续长时间运行，就难以检测死锁和无限循环。超时可以按每次调用在 1 秒到 900 秒（15 分钟）的范围内设置，作为自动终止异常执行的安全网发挥作用。第三，是成本的可预测性。由于 Lambda 按执行时间计费，如果执行时间没有上限，因缺陷导致的无限循环会带来意料之外的高额账单。15 分钟的上限保证了即使在最坏的情况下，1 次执行的成本也会落在可预测的范围内。对于 15 分钟内无法完成的处理，常规做法是用 Step Functions 拆分并编排，或者委托给 AWS Batch 或 Fargate 的任务。
2014 年推出，2018 年起为 15 分钟
内存 10 GB 与负载 6 MB 在实际工作中的含义
Lambda 的内存上限于 2020 年从 3,008 MB 提高到 10,240 MB（10 GB）。内存设置也与 CPU 的分配联动。1,769 MB 时分配相当于 1 个 vCPU 的处理能力，上限 10,240 MB 时分配相当于约 6 个 vCPU 的处理能力。也就是说，增加内存的操作本身也就是增加计算能力的操作。10 GB 是能够覆盖机器学习推理、大规模数据转换、内存密集型计算处理的实用上限。为何在 10,240 MB 划线的计算依据并未公布，因此即使看到“是根据物理主机的配置倒推出来的”这类说明，也应当将其作为推测对待。负载的上限是同步调用 6 MB、异步调用 256 KB（截至 2026 年 8 月）。与 API Gateway 组合使用时，还需要同时注意 API Gateway 一侧的请求/响应负载上限为 10 MB。此外，二进制数据经 Base64 编码后会增加约 33%，因此实际能传送的原始数据量小于数值上的上限。官方并未说明 6 MB 这个值是否由 API Gateway 的 10 MB 倒推而来。无论如何，在处理大型数据时，推荐采用将数据保存到 S3、只把对象键传给 Lambda 的“声明检查模式”（claim check pattern）。在异步调用中，请求会先存入 Lambda 一侧的队列，然后再传递给函数。256 KB 这一上限的理由并未公布，但调用经由队列的方式已有官方说明。
并发数 1,000 的默认限制
Lambda 每个账户的默认并发数在每个区域为 1,000（截至 2026 年 8 月）。这一限制是一种保护措施，用于防止新账户在无意中同时运行大量 Lambda 函数而产生高额账单。这个值可以通过配额提升申请来提高（提高后能达到的值并未统一公布，会根据使用记录和预期用量进行审核）。并发数的限制不仅保护 Lambda，也起到保护 Lambda 所连接的下游服务的作用。例如，Lambda 连接 RDS 数据库时，如果并发数没有限制，就会超过数据库的最大连接数。如果使用 RDS Proxy，可以通过连接池加以缓解，但并发数的限制本身就作为第一道防线发挥作用。如果设置函数级别的预留并发（Reserved Concurrency），就可以防止特定函数耗尽其他函数的并发容量。例如，为重要的 API 后端函数设置 500 的预留并发、为批处理函数设置 100，批处理的激增就不会影响 API 的性能。
让限制为己所用的架构设计
把 Lambda 的限制视为“不便的约束”还是“设计的指南”，架构的质量会大幅变化。15 分钟的限制会促使人们采用把处理拆分成小单元、并用 Step Functions 编排的设计。Step Functions 的 Express Workflow 最长可运行 5 分钟，Standard Workflow 最长可运行 1 年。因此，可以让各个函数保持在 15 分钟以内，同时在整体上构成长时间运行的工作流。6 MB 的负载限制会促使人们采用用 S3 在函数之间传递数据的声明检查模式，结果是函数之间的松耦合程度提高。内存限制会促使人们采用把处理流式化的设计。可以不把 10 GB 的文件一次性读入内存，而是把聚合交给 Amazon Athena。也可以用 S3 的范围（Range）请求或 S3 Object Lambda 分段读取对象，或用 Kinesis Data Streams 按记录流式传输。采用这些方法，就可以用少量内存处理大量数据。另外，S3 Select 已停止向新客户提供，因此不再是新设计的选项（截至 2026 年 8 月）。这些限制最终会引导开发者走向可扩展且容错性高的架构。如果没有限制，开发者大概会经不住诱惑，写出巨大的单体函数。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。