AWS Lambda SnapStart Now Supports Container Images

Container images in AWS Lambda have always carried a hidden tax: cold starts measured in seconds, not milliseconds. Teams running ML inference or interactive APIs in containers faced an ugly trade-off — pay for provisioned concurrency to keep functions warm, or accept latency spikes that ruled them out for production user-facing workloads. AWS just eliminated that trade-off. Lambda SnapStart — the snapshot-and-resume mechanism that cuts cold starts to sub-second for zip-packaged functions — now supports container image deployments too.

The announcement landed in July 2026 with minimal fanfare, but the implications are significant. Container images were the preferred deployment format for anything serious in Lambda — ML libraries, large dependencies, custom runtimes, teams standardizing on ECR pipelines across ECS and Lambda. The cold start penalty was the one thing holding them back from latency-sensitive workloads. That penalty is now opt-in to remove.

How Lambda SnapStart Works

SnapStart intercepts the initialization phase at deploy time rather than invocation time. When you publish a function version, Lambda runs your initialization code, takes a Firecracker MicroVM snapshot of the fully initialized memory and disk state, encrypts it, and caches it. On every subsequent cold invocation, Lambda resumes from that cached snapshot instead of reinitializing. AWS maintains multiple copies for resiliency and automatically patches snapshots with runtime and security updates.

The result: cold starts that previously ran several seconds for large container images drop to sub-second. Java benchmarks show roughly 90% cold start reduction, with real-world P99 improvements near 94%. For ML inference serving a Python model with PyTorch dependencies, this closes the performance gap between container and zip Lambda deployments almost entirely.

Which Runtimes Get SnapStart Without Extra Work

If you are using AWS managed base images for Java 11+, Python 3.12+, or .NET 8+, SnapStart works automatically. Enable it, publish a version, and you are done — no code changes required. These three runtimes cover the majority of container Lambda use cases, particularly ML workloads on Python.

Node.js and Ruby managed runtimes are not supported. Custom base images require additional configuration, but there is a fast path for teams that do not need lifecycle hooks.

How to Enable SnapStart on a Container Function

The process mirrors zip functions. Enable via AWS CLI:

aws lambda update-function-configuration \
  --function-name my-function \
  --snap-start ApplyOn=PublishedVersions

aws lambda publish-version --function-name my-function

Confirm activation by checking that OptimizationStatus is On and State is Active in the get-function-configuration output. SAM, CDK, and CloudFormation all support SnapStart properties natively. One hard constraint: SnapStart only applies to published function versions. It does not work on the unpublished $LATEST version.

Custom Base Images: The One-Line Fix

If you are running a custom base image and do not need before-snapshot or after-restore hooks, add a single label to your Dockerfile:

LABEL com.amazonaws.lambda.feature.snapstart="Allow"

That is the entire change. If your function does need hooks — to re-seed random number generators or refresh credentials before snapshotting — you will need to implement the Runtime API lifecycle calls. The process involves checking the AWS_LAMBDA_INITIALIZATION_TYPE environment variable and calling GET /runtime/restore/next at the right moment in your initialization flow.

What to Watch Out For

Uniqueness. Any values generated during initialization — unique IDs, secrets, entropy for random number generators — get frozen into the snapshot and shared across all execution environments resumed from it. Generate these values inside your handler, not during initialization. Network connections established during init may not survive restoration; re-validate them in the handler before use.

Pricing. Unlike Java zip functions, which get SnapStart at no extra charge, container image SnapStart carries snapshot caching and restoration fees based on memory allocation. Account for this in cost modeling, especially for high-memory functions with infrequent invocations. AWS deletes snapshots after 14 days of inactivity, returning a SnapStartNotReadyException on the next invocation until a fresh snapshot is initialized.

Regional availability. SnapStart for container images is available in all commercial AWS regions except Asia Pacific (New Zealand) and Asia Pacific (Taipei).

Incompatibilities. Provisioned concurrency, Amazon EFS mounts, Amazon S3 Files, and ephemeral storage above 512 MB are not supported alongside SnapStart.

What to Do Now

If you are running Python 3.12+, Java 11+, or .NET 8+ in Lambda container images, enabling SnapStart requires publishing a new function version. Review initialization code for uniqueness issues first, then enable via CLI or your IaC tool and publish. The full AWS announcement covers the rollout, and the SnapStart documentation covers pricing details and edge cases.

For teams that ruled out container-based Lambda because of cold start latency: that reasoning no longer holds for the runtimes that matter most. The performance gap between zip and container deployments has effectively closed.