Lambda SnapStart: Reduce Java Cold Starts to Milliseconds (2026)

Lambda SnapStart can make your Java functions start up in milliseconds, but it’s not a magic bullet that just works out of the box.

Let’s see it in action. Imagine a standard Java Lambda function that does a little bit of work, say, processing a simple JSON payload.

{
  "key": "value"
}

Without SnapStart, the first time this function is invoked after a period of inactivity, it has to go through the full initialization process. This involves downloading the code, starting the JVM, initializing static variables, and then running the handler. For a typical Java application, this can easily take several seconds.

Now, let’s enable SnapStart. We’ll need to configure it in our Lambda function’s settings.

{
  "FunctionName": "MyJavaSnapStartFunction",
  "State": "Enabled",
  "Runtime": "java11",
  "Handler": "example.MyHandler::handleRequest",
  "Code": {
    "S3Bucket": "my-lambda-bucket",
    "S3Key": "my-java-app.jar"
  },
  "SnapStart": {
    "ApplyOn": "PublishedVersions"
  }
}

When we deploy this function and invoke it for the first time after deployment or a period of inactivity, something different happens. Lambda creates an initialized snapshot of the function’s execution environment, including the JVM state and loaded static data. This snapshot is then encrypted and stored. Subsequent invocations reuse this snapshot, bypassing the lengthy JVM startup and initialization. The result? Millisecond cold starts.

The core problem SnapStart solves is the significant overhead of Java’s JVM startup. Unlike languages that compile to native code or have lighter runtimes, starting a JVM, loading classes, and initializing static data is inherently time-consuming. This delay is particularly noticeable in serverless environments where functions can be scaled down to zero and need to be ready to serve requests instantly. SnapStart effectively "pre-warms" the JVM by taking a snapshot of it after it’s already initialized.

Here’s the mental model:

1. First Invocation (or after a long idle period): Lambda provisions a container, starts the JVM, loads your code, and initializes all static variables. This is the "warm-up" phase.
2. Snapshotting: Before returning the result of this first invocation, Lambda takes a cryptographically signed snapshot of the entire execution environment. This includes the JVM’s heap, stack, and loaded classes.
3. Storage: This snapshot is encrypted and stored by AWS.
4. Subsequent Invocations: For subsequent requests, Lambda reuses an existing, warm execution environment. If a warm environment exists, it’s used directly. If not, Lambda retrieves the latest published snapshot, decrypts it, and restores the execution environment from that snapshot. The JVM is already running and initialized, so only a very minimal amount of work is needed to get to your handler.

The key levers you control are:

• ApplyOn: This setting determines when SnapStart is applied. PublishedVersions means it will be applied to new published versions of your function. Always means it will be applied to every new deployment, including drafts. For most use cases, PublishedVersions is preferred as it ensures SnapStart is applied only after you’ve explicitly published a version you’re happy with.
• Initialization Code: Any code that runs during static initialization of your Java classes will be part of the snapshot. This means that expensive operations like loading large configuration files, establishing database connections (though not recommended for Lambda), or initializing complex object graphs will be performed once when the snapshot is created, not on every invocation.
• Dependencies: The size and complexity of your dependencies directly impact the time it takes to initialize the JVM and load classes. While SnapStart helps, keeping your dependency footprint lean still benefits overall performance.

The "published versions" strategy for ApplyOn is critical. When you enable SnapStart on PublishedVersions, AWS only creates the snapshot when you publish a new version of your Lambda function. This means any changes you make to your code won’t benefit from SnapStart until you explicitly publish a new version. If you’re iterating quickly on code changes, you might want to temporarily switch ApplyOn to Always during development and then back to PublishedVersions for production releases.

When you enable SnapStart, your Lambda function deployment package must be stored in Amazon S3.

The next challenge you’ll likely encounter is managing the size of your deployment package, as SnapStart doesn’t inherently compress your code, and larger packages still take longer to download, even if the JVM startup is faster.