AWS recently extended Lambda SnapStart to functions packaged as container images, removing a trade-off that has shaped how teams package heavy Python dependencies. Container image functions can hold up to 10 GB, compared with 250 MB for zip archives, but until now choosing containers meant giving up SnapStart and accepting startup times of several seconds while Lambda downloaded image layers and initialized the runtime.

SnapStart takes a snapshot of the initialized execution environment at deployment, caches it, and resumes from it on invocation rather than initializing from scratch. AWS reports startup times dropping to sub-second. The capability previously covered only the managed runtimes for Python, .NET, and Java.

The constraint it removes was visible on Reddit a month before the announcement. A team running pandas and numpy in Lambda described hitting the 250 MB ceiling and resorting to stripping whitespace, comments, and docstrings from their own code and from installed packages, recovering about 5 MB:

While using containers does solve the limit problem, it does remove a critical feature: SnapStart.

The original poster noted that docstrings could only be removed where nothing called __doc__, and pushed back on suggestions to rearchitect, writing that the code was legacy, coupled into the stack, and that the real world has tech debt.

The thread corrected one common assumption. Two commenters pointed to AWS documentation confirming that Lambda layers count against the same 250 MB unzipped budget, so moving pandas and numpy into a layer buys no room. One summarized the position teams were left in:

if you need to keep snapstart, the escape hatch is mounting an efs access point and importing the heavy libs from there at init - you eat the cold start once but stay on zip-based lambda. the whitespace/docstring stripping works but it means you're one dependency bump away from being stuck again.

Most of the thread argued the tool was wrong rather than the packaging. Several commenters suggested ECS Fargate, Step Functions or AWS Batch, on the grounds that pandas-heavy work is batch-oriented and Lambda is a poor fit for it. One noted that container image functions can already start faster than a 250 MB zip in some cases, before SnapStart entered the picture.

Those arguments still hold. What has changed is that teams choosing containers for dependency size no longer pay a startup penalty for it, which narrows the cases where the size limit alone forces a rearchitecture.

Support is not uniform across base images. For AWS base images with Java 11 or later, Python 3.12 or later, and .NET 8 or later, the experience matches zip archives. Any other image, including Node.js, Ruby, and custom bases, must add LABEL com.amazonaws.lambda.feature.snapstart="Allow" to its Dockerfile or implement SnapStart runtime hooks. Without one of those, publishing the version fails during initialization.

Tooling has caught up quickly. Serverless Framework 4.42.0 shipped support within a week of the announcement, after a user opened an issue pointing at it. A maintainer noted that setting snapStart on an image-based function already deployed correctly before the release, which closed the remaining gaps: the framework now rejects an ephemeral storage size above 512 MB combined with SnapStart before deploying, and a failed version publish on a container function prints a hint pointing at the label or runtime hooks rather than a raw CloudFormation message. The same maintainer observed that AWS's own SnapStart documentation still described the Java-only era.

One difference between the two packaging models remains. AWS patches the runtime for zip-based functions. With container images, keeping the base image current is the customer's responsibility, and SnapStart does not change that.

SnapStart for container images is available in all commercial AWS regions except Asia Pacific in New Zealand and Taipei, and can be activated on new or existing functions through the API, console, CLI, CloudFormation, SAM, SDK, and CDK. AWS documents SnapStart pricing separately from standard Lambda pricing.