AWS Lambda SnapStart for a Model-Calling Function

SnapStart moves the initialization phase from invocation time to publish time. AWS initializes the function when you publish a version, takes a Firecracker microVM snapshot of the initialized environment, and resumes new environments from that snapshot instead of running your init code again. For a function whose init cost is loading an SDK and building a client, that is exactly the phase you wanted to delete.

What SnapStart does

AWS documents the mechanism plainly: on publish, Lambda initializes the function, snapshots the memory and disk state of the execution environment, encrypts the snapshot and caches it; on the first invocation of that version and as concurrency scales up, it resumes from the cache rather than initializing from scratch. The SnapStart documentation describes the result as “as low as sub-second startup performance”, and is careful to say that functions invoked infrequently might not see the same improvement.

That caveat is the one to internalise. SnapStart removes your init time; it does not remove the platform’s work in restoring a snapshot, which is charged and reported separately. AWS positions provisioned concurrency, not SnapStart, as the answer where the latency requirement is strict, and the two cannot be combined.

Whether your function is eligible

Most of the time spent on SnapStart is spent discovering it does not apply. The constraints, as documented at the time of writing:

• Runtimes. Java 11 and later, Python 3.12 and later, .NET 8 and later. Other managed runtimes, OS-only runtimes and container images are not supported.
• Container images are out. This is the one that catches AI functions, because the reason a model-calling function is packaged as a container is usually that its dependency tree outgrew the 250 MB unzipped zip limit. A function packaged that way cannot use SnapStart at all, and the fix is to shrink the package rather than to configure anything.
• Not with provisioned concurrency, not with Amazon EFS, and not with ephemeral storage above 512 MB.
• Published versions only. SnapStart applies to published versions and to aliases pointing at versions, never to $LATEST. If your integration invokes the unqualified function name, it is not using SnapStart no matter what the configuration says.
• Regions. AWS documents availability in all commercial Regions except Asia Pacific (New Zealand) and Asia Pacific (Taipei).

On price: AWS states there is no additional cost for SnapStart on Java managed runtimes. For the others you pay a caching charge per published version with SnapStart enabled, billed for a minimum of three hours and continuing while the version stays active, plus a restoration charge each time an environment is restored. Both scale with configured memory. A pipeline that publishes a version on every commit is therefore accumulating cached snapshots, and the documentation points at ListVersionsByFunction and DeleteFunction for cleaning them up.

Enabling it

1. Turn it on: aws lambda update-function-configuration --function-name my-function --snap-start ApplyOn=PublishedVersions. The only other value is None.
2. Publish a version: aws lambda publish-version --function-name my-function. This is where the init actually runs and the snapshot is taken, so this call is slower than a normal publish and can fail on init errors that you would previously have seen at invoke time.
3. Confirm with aws lambda get-function-configuration --function-name my-function:1 and look for OptimizationStatus of On together with a function State of Active. While the snapshot is being created the state is Pending and invocations of that version fail.
4. Invoke the qualified version or an alias pointing at it — my-function:1 or my-function:prod — never the bare name.

In infrastructure as code this is one property rather than a workflow: CloudFormation takes a SnapStart entity on AWS::Lambda::Function, SAM takes a SnapStart property on AWS::Serverless::Function, and the CDK exposes SnapStartProperty. All of them still require a published version and an alias to be of any use.

The two things that break

A snapshot is one initialized state reused across many environments, which invalidates two assumptions that init code normally gets for free.

Uniqueness. Anything generated once during initialization is now identical in every environment resumed from that snapshot. AWS calls this out for unique ids, unique secrets and the entropy used for pseudorandomness. In a model-calling function the usual instances are a client-side request id or idempotency key seeded at init, a cached correlation prefix, and any random seed used to pick between providers or shuffle a candidate list. Move all of it into the handler. A deterministic idempotency key shared across environments is worse than a slow cold start: it makes retried requests look like duplicates of each other to whatever is deduplicating downstream.

Connection state. AWS documents that the state of connections established during initialization is not guaranteed when the function resumes, and that connections an AWS SDK establishes usually resume automatically while others should be validated and re-established. The pattern of building an HTTP client with a warm keep-alive pool at module scope — the standard advice for reducing per-request latency to a model API — is exactly the pattern this affects. The connection was made from an environment that no longer exists, potentially hours earlier. Build the client at init, by all means, but let it establish connections lazily on first use in the handler, and set an idle timeout short enough that a stale socket is discarded rather than written to. Runtime hooks give you a documented place to do this deliberately: code registered to run after restore executes on every resume, and its duration is included in Billed Restore Duration.

One related detail worth knowing before it confuses you: with SnapStart active the runtime uses the container credentials variables AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN instead of the access key environment variables, so that credentials captured in a snapshot cannot expire before restore. Code that read AWS_ACCESS_KEY_ID directly stops working.

Reading the numbers afterwards

The log format changes, which is how you tell whether any of this helped. AWS documents three differences.

• The REPORT line no longer carries Init Duration, because initialization happened at publish. Init Duration moves to a separate INIT_REPORT record, which includes the time spent in any before-checkpoint runtime hook.
• The REPORT line for a new environment gains Restore Duration — restoring the snapshot, loading the runtime and running after-restore hooks — and Billed Restore Duration, which excludes the part performed outside the microVM and is therefore the smaller number.
• AWS states the cold start duration is Restore Duration + Duration. Any dashboard that was computing cold start as Init Duration + Duration silently reports zero after you enable SnapStart, which reads as a spectacular improvement and is a broken query.

There is one more state to have an alert for. For Java runtimes, Lambda deletes a snapshot after 14 days without an invocation; invoking the version after that returns SnapStartNotReadyException while a new snapshot initializes. A rarely used function in a rarely used region will meet this, and the correct handling is to retry after the version reaches Active rather than to treat it as a failure of the model call it was about to make.