AWS extends Lambda SnapStart to container images, bringing sub-second cold starts to 10 GB functions

SnapStart caches an initialized execution environment at deploy time and resumes from it on invocation rather than initializing from scratch, and AWS has now extended that mechanism to container image functions. Previously, teams picking containers to fit dependencies beyond the 250 MB zip limit accepted startup times of several seconds while image layers downloaded and the runtime initialized on each cold path. With the change, those multi-gigabyte images resume from a snapshot and reach sub-second startup, matching what zip-packaged functions have had since the managed runtimes for Python.NET, and Java were covered. The release is dated September 12, 2026 in the source, and it removes a constraint that the article traces back to developer workarounds visible a month before the announcement.

Adoption carries concrete configuration work. Only AWS base images with Java 11 or later, Python 3.12 or later, or .NET 8 or later get the experience zip archives have; Node.js, Ruby, and any custom image must add LABEL com.amazonaws.lambda.feature.snapstart="Allow" to the Dockerfile or implement SnapStart runtime hooks. Without one of those, the version fails to publish during initialization. Serverless Framework 4.42.0 shipped support within a week of the announcement, including a check that rejects ephemeral storage above 512 MB combined with SnapStart at deploy time and a hint pointing at the label when a publish fails, but teams using raw CloudFormation or SAM still see the underlying error and must wire the label themselves.

The feature stops working in three places worth flagging. Region coverage excludes Asia Pacific (New Zealand) and Asia Pacific (Taipei), so functions in those regions cannot use it. Ephemeral storage above 512 MB combined with SnapStart is now rejected by Serverless Framework, so large scratch space plus fast cold starts is not yet supported through that tool. AWS patches the runtime for zip-based functions but not for container images, so keeping the base image current remains a customer responsibility, and a Serverless Framework maintainer noted that AWS's own SnapStart documentation still describes the Java-only era, so cross-referencing the announcement is advisable.

The article is framed unusually, built around a Reddit thread from a month before the announcement in which a team running pandas and numpy hit the 250 MB ceiling and resorted to stripping whitespace, comments, and docstrings from installed packages to recover about 5 MB. Commenters in that thread pointed out that Lambda layers count against the same 250 MB unzipped budget, so moving dependencies to a layer does not free space, and proposed mounting an EFS access point and importing heavy libraries from there at init as an alternative. Several commenters argued the tool itself was wrong and suggested Fargate, Step Functions, or AWS Batch for batch-style pandas work. SnapStart for containers removes the size-versus-startup tension but does not address the workload-fit question that thread raised, so for genuinely batch-shaped Python jobs the rearchitecture case remains even after this release.