Lambda SnapStart扩展支持容器镜像函数

亚马逊云科技已将 Lambda SnapStart 扩展到容器镜像函数。容器镜像容量上限为 10 GB，远高于 ZIP 部署包解压后 250 MB 的限制，使用 pandas、numpy 等大型 Python 依赖时，不再需要在容量与启动速度之间取舍。此前，容器函数虽然能突破体积限制，却无法使用 SnapStart，下载镜像层和初始化运行时可能带来数秒延迟。

SnapStart 会在部署阶段保存已完成初始化的执行环境快照并缓存，调用时直接恢复，而不是重新执行完整初始化流程，官方称冷启动时间可降至 1 秒以内。该能力此前支持 Python、.NET 和 Java 托管运行时；本次扩展后，搭载 Java 11+、Python 3.12+ 或 .NET 8+ 的 AWS 基础镜像可按 ZIP 函数的方式使用。

这一变化回应了大型依赖带来的实际困境。此前有运行 pandas 和 numpy 的团队为节省约 5 MB，不得不从代码和依赖包中删除空格、注释及文档字符串；文档字符串只有在代码不调用 __doc__ 时才能移除，而且依赖升级后问题可能再次出现。将依赖放入 Lambda 层也无法绕开 250 MB 的解压后配额，另一种变通方案是初始化时挂载 EFS 访问点，但仍需承受一次冷启动。

部分开发者认为，大量使用 pandas 的任务更适合 ECS Fargate、Step Functions 或 AWS Batch，相关架构建议并未因本次更新失效。不同之处在于，因依赖体积选择容器镜像的团队如今无需再牺牲启动性能，也能减少仅为突破大小限制而进行的架构重构。

并非所有镜像都能直接启用该功能。Node.js、Ruby 以及自定义基础镜像需要在 Dockerfile 中加入 LABEL com.amazonaws.lambda.feature.snapstart=“Allow”，或实现 SnapStart 运行时钩子；缺少相应配置时，函数版本会在初始化阶段发布失败。Serverless Framework 4.42.0 已加入支持：部署前会阻止临时存储超过 512 MB 且同时启用 SnapStart 的配置，并在容器函数发布失败时提示检查标签或运行时钩子，而非仅显示原始 CloudFormation 错误。不过，相关官方文档仍有部分内容停留在仅支持 Java 的旧版本状态。

ZIP 函数的运行时补丁仍由 AWS 负责，容器镜像则需要用户自行维护基础镜像更新，SnapStart 不会改变这一责任边界。目前该能力已在除亚太地区（新西兰）和台北外的所有 AWS 商用区域推出，可通过 API、控制台、CLI、CloudFormation、SAM、SDK 和 CDK 为新建或现有函数启用；具体 SnapStart 费用与标准 Lambda 费用已分别列于定价文档中。