AWS Lambda SnapStart: How It Works, What It Fixes, and When to Use It

Initialization can account for much of a Java Lambda function’s cold-start time, especially when it loads a framework and opens connections. SnapStart restores an initialized snapshot; evaluate its restore latency and state-handling requirements against your workload.

How SnapStart Uses a Snapshot

Standard Lambda cold starts require four sequential steps: allocate a microVM, load the runtime, run initialization code, then handle the invocation. Steps one through three represent irreducible overhead — they happen every time a new execution environment is needed.

SnapStart breaks that sequence by checkpointing the execution environment after step three completes. AWS takes a snapshot of the fully initialized execution environment — memory state, file system, network configuration — and stores it. When a new execution environment is needed, Lambda restores from the snapshot instead of initializing from scratch.

Restoration avoids repeating much of initialization, but still has a latency cost. Measure restore time with your dependencies and lifecycle hooks.

Which Runtimes Support SnapStart

SnapStart supports Java 11 and newer, Python 3.12 and newer, and .NET 8 and newer among its managed runtimes. Check the AWS support and compatibility documentation for your runtime and deployment format.

Enabling SnapStart

Enabling SnapStart is a single configuration change on the Lambda function:

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

SnapStart only applies to published versions — it does not work on $LATEST. This means your deployment process must publish a version after each code update. If you are using Lambda aliases and weighted traffic routing, you are likely already publishing versions. If not, adding version publication is a small workflow change.

After enabling SnapStart, the first deployment after the setting change will take longer than usual — Lambda is initializing and snapshotting the new version. Subsequent deployments follow the same pattern.

State to Check After Restoration

SnapStart restores an execution environment from a frozen snapshot. Any state that was valid at snapshot time but is no longer valid at restore time will cause problems.

The most common issues:

Unique identifiers generated at init: If your initialization code generates a UUID, cryptographic seed, or random value meant to be unique per execution environment, all restored environments will share the same value. This breaks uniqueness guarantees.

Network connections: A database connection or HTTP keep-alive established during initialization will be stale or invalid after restore. Attempting to use it will produce errors.

Time-sensitive tokens: Authentication tokens fetched during initialization expire. A token that was valid when the snapshot was taken may be expired when the environment is restored hours or days later.

SnapStart Lifecycle Hooks

AWS provides two lifecycle hooks specifically designed to handle snapshot-state invalidation:

• beforeCheckpoint: runs before the snapshot is taken. Use it to flush and close any state that should not be persisted.
• afterRestore: runs after the environment is restored from snapshot but before the handler is invoked. Use it to re-establish connections, regenerate unique identifiers, and refresh tokens.

In Java, implement these via the RuntimeHook interface:

public class MyHook implements RuntimeHook {
    @Override
    public void beforeCheckpoint(Context context) {
        // Close DB connections, flush state
    }
 
    @Override
    public void afterRestore(Context context) {
        // Re-establish DB connections, refresh tokens
    }
}

Teams using frameworks like Quarkus or Micronaut with SnapStart support get these hooks managed automatically for common resources. Spring Boot integration has improved but may require manual hook implementation depending on which beans you initialize.

SnapStart vs Provisioned Concurrency

These two features solve the same problem — cold start latency — with different mechanisms and different cost profiles.

Provisioned Concurrency keeps initialized execution environments warm at all times. You pay for the concurrency even when no invocations are occurring. The cost is continuous.

SnapStart restores snapshots instead of holding warm environments. For supported Java managed runtimes, SnapStart has no additional charge. Other supported runtimes incur snapshot caching and restoration charges; check AWS Lambda pricing for current rates.

Compare measured restore latency with your endpoint’s latency target. AWS does not support SnapStart and provisioned concurrency on the same function configuration.

When to Use SnapStart Over Provisioned Concurrency

• Traffic pattern is bursty or unpredictable
• The function is invoked infrequently enough that idle provisioned concurrency cost would be significant
• Measured restore latency fits the endpoint’s p99 latency target

When to Choose Provisioned Concurrency

• User-facing endpoints with strict latency SLAs
• Functions on the critical authentication or payment path
• Traffic patterns are predictable enough to size provisioned concurrency accurately

Choose provisioned concurrency when the workload needs initialized environments ready to handle traffic and the additional cost is justified. Schedule or scale it to match expected demand.

Practical Limits and Considerations

• SnapStart snapshots are stored per published version. Old version snapshots are deleted when the version is deleted.
• SnapStart functions can access VPC resources. Check restored application connections and reconnect when needed.
• Functions with very large heap sizes at init time produce larger snapshots, which adds restore time. Lean initialization remains important even with SnapStart.

Before Enabling SnapStart

Measure initialization and restore latency, test state that survives the snapshot, and verify runtime compatibility. Use those results to decide whether SnapStart meets the function’s latency and operating-cost requirements.

Discuss AWS infrastructure with LinkIT.