AWS 将 Lambda SnapStart 扩展到了容器镜像函数。这个变化解决了一个长期存在的打包取舍：Zip 部署包的体积上限更小，而容器镜像可以容纳更多依赖；但团队过去往往要在依赖空间和亚秒级启动之间做选择。
现在，使用容器镜像的 Lambda 函数也可以采用 SnapStart。对于依赖较多、又对启动延迟敏感的函数，这意味着不必仅为了满足 Zip 限制而删减运行时内容。
一个真实存在的工程取舍
Lambda Zip 归档的上限是 250 MB，而容器镜像函数可以达到 10 GB。这个差距足以影响项目的技术决策：数据处理库、科学计算依赖、语言运行时组件，或者多个内部 SDK，都可能让 Zip 包迅速逼近上限。
过去的选择通常有两条路：
- 继续使用 Zip，享受较小的部署包，但必须严格控制依赖体积。
- 改用容器镜像，获得更大的依赖空间，却需要面对启动速度方面的顾虑。
一个月前的 Reddit 讨论就展示了这种压力：为了把已安装的包塞进限制，一些团队甚至会移除空白字符和文档字符串。这样的处理可能暂时解决体积问题，但也会增加构建流程复杂度，并让依赖管理变得更脆弱。
SnapStart 支持容器镜像后，第二条路线不再天然意味着放弃快速启动。依赖空间和启动延迟可以分别处理，而不是绑定成一次打包决策。
容器镜像如何落地
可以把镜像看成 Lambda 函数的运行时载体，把 SnapStart 看成发布版本启动路径上的优化选项。一个最小的 Python 容器镜像示例可以这样写：
FROM public.ecr.aws/lambda/python:3.12
COPY requirements.txt ${LAMBDA_TASK_ROOT}/
RUN pip install -r ${LAMBDA_TASK_ROOT}/requirements.txt \\
--target ${LAMBDA_TASK_ROOT}
COPY app.py ${LAMBDA_TASK_ROOT}/
CMD ["app.handler"]
app.py：
import json
def handler(event, context):
return {
"statusCode": 200,
"headers": {"content-type": "application/json"},
"body": json.dumps({"ok": True, "request_id": context.aws_request_id}),
}
下面是一组可改造的命令。运行前请替换 AWS 区域、账号 ID、ECR 仓库名和函数名；示例假设已经安装并配置 AWS CLI、Docker，并拥有相应的 ECR 与 Lambda 权限。
set -euo pipefail
AWS_REGION="us-east-1"
AWS_ACCOUNT_ID="123456789012"
REPOSITORY="lambda-snapstart-demo"
FUNCTION_NAME="lambda-snapstart-demo"
IMAGE_TAG="latest"
aws ecr describe-repositories \\
--repository-names "$REPOSITORY" \\
--region "$AWS_REGION" >/dev/null 2>&1 || \\
aws ecr create-repository \\
--repository-name "$REPOSITORY" \\
--region "$AWS_REGION" >/dev/null
REGISTRY="$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com"
IMAGE_URI="$REGISTRY/$REPOSITORY:$IMAGE_TAG"
aws ecr get-login-password --region "$AWS_REGION" | \\
docker login --username AWS --password-stdin "$REGISTRY"
docker build --platform linux/amd64 -t "$IMAGE_URI" .
docker push "$IMAGE_URI"
aws lambda create-function \\
--function-name "$FUNCTION_NAME" \\
--package-type Image \\
--code ImageUri="$IMAGE_URI" \\
--role "arn:aws:iam::$AWS_ACCOUNT_ID:role/lambda-execution-role" \\
--region "$AWS_REGION"
aws lambda update-function-configuration \\
--function-name "$FUNCTION_NAME" \\
--snap-start ApplyOn=PublishedVersions \\
--region "$AWS_REGION"
aws lambda publish-version \\
--function-name "$FUNCTION_NAME" \\
--region "$AWS_REGION"
这段流程的关键点是发布版本：命令先配置 ApplyOn=PublishedVersions，再发布一个版本用于验证。生产环境还应把版本、别名和流量切换纳入现有发布流水线，而不是只更新 $LATEST 后直接结束。
更大的镜像不等于可以无限装依赖
10 GB 是容量上限，不是依赖管理策略。容器镜像会让团队获得更多空间，但也可能带来更长的构建时间、更大的推送体积和更复杂的漏洞扫描结果。
可以这样控制风险：
- 使用多阶段构建，避免把编译工具和缓存带进最终镜像。
- 固定依赖版本，定期清理未使用的库。
- 将镜像层按变化频率组织，让业务代码变更不必重复上传所有内容。
- 在启用 SnapStart 前，检查初始化阶段是否包含外部连接、随机数生成或只应执行一次的副作用操作。
- 通过真实依赖和真实流量模式测试启动延迟，而不是只比较镜像大小。
这些是通用实践建议，具体初始化行为和兼容边界仍应以目标运行时及 AWS Lambda 文档为准。SnapStart 能缓解启动路径问题，但不能替代镜像瘦身、依赖审计和发布版本管理。
采用前的检查清单
如果函数已经因为 Zip 的 250 MB 限制而被迫删减依赖，可以按下面的顺序评估：
- 统计真正需要的运行时依赖，确认问题确实来自包体积，而不是构建过程误带了缓存或开发工具。
- 将函数构建为容器镜像，并验证架构、入口点、权限和日志行为。
- 为已发布版本启用 SnapStart，分别测量首次调用、后续调用和依赖初始化的实际表现。
- 通过别名逐步切换流量，观察错误率、延迟和成本变化。
- 保留回滚路径：镜像标签、函数版本和别名都应可追踪。
这次扩展的价值不只是把一个配置项带到了容器镜像。它改变了 Lambda 的打包决策边界：当函数需要大量依赖时，团队可以优先选择更合适的运行时载体，再单独处理启动性能，而不必为了跨过 Zip 限制去删除文档字符串或改写安装包内容。