Lambda 的 15 分钟限制为何是 15 分钟 - 无服务器设计约束背后的合理性
从 Firecracker 的设计理念和多租户运维角度，解析 Lambda 最大执行时间 15 分钟、内存上限 10GB、负载 6MB 等各项限制为何设定为这些值。
限制不是约束而是设计决策
开发者初次使用 Lambda 时首先面对的就是各种限制（Limits）。最大执行时间 15 分钟、内存 128MB 至 10,240MB、同步调用负载 6MB、部署包 250MB（解压后）。这些数字并非随意决定，而是在多租户环境中平衡资源公平性、运维安全性和成本效率的结果。Lambda 在同一物理基础设施上运行数百万客户的函数，任何一个函数都不能独占资源或影响其他客户。这些限制是实现这种隔离的工程手段。
15 分钟限制的历史与背景
Lambda 在 2014 年发布时，最大执行时间仅为 60 秒。2016 年延长至 5 分钟，2018 年提升至当前的 15 分钟。这种阶段性延长反映了客户用例的扩展和 AWS 基础设施优化的进展。15 分钟这个值有几个技术和运维方面的依据。第一，Firecracker MicroVM 的生命周期管理：长时间运行的 MicroVM 会占用物理主机的内存和 CPU，降低主机的利用率。第二，故障恢复：15 分钟内的处理在失败时可以安全重试，而数小时的处理重试成本极高。第三，架构引导：促使开发者将处理分解为小单元，通过 Step Functions 编排。
内存 10GB 与负载 6MB 的原因
Lambda 的内存上限在 2020 年从 3,008MB 提升至 10,240MB（10GB）。该上限由 Firecracker MicroVM 运行的物理主机内存容量和单台主机同时运行的 MicroVM 数量反推得出。物理主机的内存由数百个 MicroVM 共享，因此单个 MicroVM 可分配的内存有上限。同步调用的负载限制 6MB 是 API Gateway 和 Lambda 服务之间的网络传输效率决定的。大于 6MB 的数据应通过 S3 传递引用，而非直接包含在负载中。异步调用的负载限制为 256KB，这是 SQS 消息大小限制的反映。
默认并发数 1,000 的限制
Lambda 每账户的默认并发数为 1,000。该限制是防止新账户意外大量同时执行 Lambda 函数导致高额账单的安全措施。通过限额提升请求，可将并发数提升至数万甚至数十万。并发数限制不仅保护 Lambda 本身，还保护 Lambda 连接的下游服务。例如，如果 Lambda 以 1,000 并发访问 RDS 数据库，数据库连接池可能耗尽。预留并发（Reserved Concurrency）可为特定函数保留并发配额，防止其他函数消耗所有配额。
将限制转化为架构设计的指南
将 Lambda 的限制视为「不便的约束」还是「设计指南」，架构质量会有很大差异。15 分钟限制促使将处理分解为小单元，通过 Step Functions 编排。Step Functions 的 Express Workflow 最长 5 分钟，Standard Workflow 最长 1 年，Lambda 的 15 分钟限制在两者之间，适合作为单个处理步骤的粒度。负载 6MB 限制促使采用通过 S3 传递大数据的模式，这本身就是可扩展架构的最佳实践。