AWS Lambda recently launched SnapStart for container image functions , reducing startup times from several seconds to as low as sub-second. Customers deploy Lambda functions with container images to align with their organization’s container-based deployment standards, or to package larger dependencies up to 10 GB. However, larger container images can experience startup times of several seconds as Lambda downloads image layers and initializes the runtime and application code.
SnapStart addresses this by taking a snapshot of the initialized execution environment during function deployment, caching it, and resuming from it on invocation, instead of initializing from scratch. In November 2022, Lambda launched SnapStart for Java , reducing startup latency by up to 10x. In November 2024, SnapStart expanded to Python and . NET managed runtimes, reducing cold start latency to as low as sub-second. These launches helped developers achieve faster startup time, but only for .
By extending SnapStart support for container image functions, customers can improve startup times for latency-sensitive workloads such as ML inference and interactive APIs. This post covers how SnapStart for container images works, how to enable it, and best practices and considerations for your workloads. When you deploy a Lambda function, you choose one of two deployment models: a . zip file archive or a container image. With managed runtimes we already support SnapStart for Python, . NET, and Java functions, and now we have extended this capability to container images.
When you invoke the deployed function for the first time, or when a burst of traffic arrives, Lambda checks if there is an available execution environment. If none are available, Lambda creates a new one. For container image functions, this means downloading and extracting image layers, bootstrapping the runtime, and running your initialization code. This process can take several seconds, which users experience as a cold start.