Lambda SnapStart 现在支持容器镜像

最近，亚马逊云科技 将 Lambda SnapStart 的支持范围扩展 "到了以容器镜像形式打包的函数，从而消除了此前影响团队打包大型 Python 依赖项的权衡。容器镜像函数的最大容量可达 10 GB，而 ZIP 压缩包仅为 250 MB；但此前，选择容器就意味着必须放弃 SnapStart，并接受 Lambda 在下载镜像层和初始化运行时期间产生的为时数秒的启动延迟。 SnapStart 会在部署时对已经初始化的执行环境做快照，并将其缓存起来，然后在调用时从中恢复，而非从头开始初始化。亚马逊云科技表示，启动时间已经缩短至不到一秒。此前，该功能仅支持 Python、.NET 和 Java 的托管运行时。 在公告发布前一个月，该功能所要消除的限制已经在 Reddit " 上的讨论中有所体现。一个在 Lambda 中运行 pandas 和 numpy 的团队描述称，他们曾经遇到 250 MB 的上限，不得不从自己的代码和已安装的包中删除空格、注释和文档字符串，从而节省了约 5 MB 的空间： 虽然使用容器确实解决了限制问题，但同时也去除了一个关键功能：SnapStart。 原帖作者指出，只有在没有任何地方调用 __doc__ 的情况下才能移除文档字符串，并反驳了关于重构架构的建议，称该代码是遗留代码，已经与技术栈紧密耦合，而且现实世界中确实存在技术债务。 该讨论帖纠正了一个常见的误解。两位评论者援引 亚马逊云科技的文档 "证实，Lambda 层也会占用相同的 250 MB 解压后配额，因此，将 pandas 和 numpy 移入一个单独部署的层中并不能腾出空间。其中一人总结了团队面临的困境： 如果你需要保留 SnapStart 功能，一个变通方法是在初始化时挂载一个 EFS 访问点，并从那里导入大型库——虽然这样做需要忍受一次冷启动，但可以继续使用基于 ZIP 的 lambda。虽然去除空格和文档字符串的方法可行，但这意味着只要所依赖的版本一升级，你就会再次陷入困境。 该讨论帖中的大部分内容都认为问题出在工具本身，而非打包方式。有几位评论者建议使用 ECS Fargate、Step Functions 或 AWS Batch，理由是大量使用 pandas 的任务属于批处理性质，而 Lambda 并不适合此类场景。有人指出，在某些情况下，容器镜像函数的启动速度本就比 250 MB 的 zip 文件更快，在 SnapStart 出现之前就是这样。 这些论点依然成立。变化在于，那些因依赖项大小而选择容器的团队，不需要再为此付出启动性能的代价，这减少了仅因大小限制而被迫重构架构的情况。 不同基础镜像对该功能的支持情况不尽相同。对于搭载 Java 11 或更高版本、Python 3.12 或更高版本以及 .NET 8 或更高版本的 AWS 基础镜像，其使用体验与 ZIP 归档文件一致。其他任何镜像（包括 Node.js、Ruby 和自定义基础镜像）都必须在其 Dockerfile 中添加 LABEL com.amazonaws.lambda.feature.snapstart=“Allow”，或实现 SnapStart 运行时钩子 "。如果缺少其中任何一项，那么发布该版本时会在初始化阶段失败。 相关工具非常迅速地进行了跟进更新。在用户提交问题报告后， Serverless Framework 4.42.0 " 于公告发布一周内就推出了相关支持。一位维护者指出，在此次发布之前，对于已部署的基于镜像的函数设置 snapStart 其实就已经能够正常工作，这次是填补了剩余的空白：现在，框架会在部署前拒绝将临时存储大小设置为超过 512 MB 并与 SnapStart 同时启用的配置；此外，当容器函数发版失败时，系统会打印一条提示，指向标签或运行时钩子，而不是原始的 CloudFormation 消息。同一位维护者还指出，亚马逊云科技的 SnapStart 文档仍然停留在仅支持 Java 的时代。 这两种打包模型之间仍然存在一个区别。对于基于 ZIP 的函数，AWS 会为其运行时打补丁。而对于容器镜像，保持基础镜像处于最新状态则是客户的责任，SnapStart 并不会改变这一点。 除亚太区（新西兰）和台北以外，面向容器镜像的 SnapStart 已经在所有 AWS 商用区域内推出，用户可以通过 API、控制台、CLI、CloudFormation、SAM、SDK 和 CDK 在新函数或现有函数上启用该功能。亚马逊云科技将 SnapStart 的定价 "与标准 Lambda 定价在文档中分别做了说明。 原文链接： https://www.infoq.com/news/2026/09/lambda-snapstart-container-image/ "