A Node.js function deployed as a container image with Lambda SnapStart enabled. When the version is published, Lambda runs the initialization code once and snapshots the environment; invocations then restore from that snapshot instead of cold-starting.

The subject of this example is the one line that makes it work for a Node.js image:

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

Images built on the AWS base images for Java 11+, Python 3.12+ or .NET 8+ are SnapStart-ready without it. Any other image — the Node.js, Ruby and provided.al2023 base images, or a custom base — must carry this label or implement the SnapStart runtime hooks; otherwise publishing the version fails during deployment with did not stabilize … An error occurred during function initialization.

• Latency-sensitive HTTP APIs packaged as container images
• Functions whose initialization loads large dependencies or models

• Docker running locally (deploying builds the image and pushes it to ECR)
• An AWS account and credentials configured for the Serverless Framework

serverless deploy

The output lists the HTTP API endpoint.

Call the endpoint a few times:

curl https://<api-id>.execute-api.<region>.amazonaws.com/

The response reports how the environment started:

{ "initializationType": "snap-start", "functionVersion": "1", "initializedAt": "…" }

initializationType is snap-start because the HTTP API invokes the snapstart alias, which the Framework points at the version published by the latest deploy that changed the function. In CloudWatch Logs the first invocation of a fresh environment shows a RESTORE_REPORT line with the restore duration instead of an INIT_REPORT.

Invoking the function by its unqualified name skips the snapshot:

serverless invoke -f hello

returns "initializationType": "on-demand" and "functionVersion": "$LATEST".

• Uniqueness. Everything at module scope is captured once and shared by every restored environment. Do not create random seeds, unique IDs or cached credentials during initialization; create them inside the handler. See Handling uniqueness with Lambda SnapStart.
• Cost. AWS bills a cached snapshot per published version for runtimes other than Java. SnapStart always publishes a version; versionFunctions only decides whether superseded versions are kept. This example sets it to false so a deploy that publishes a new version deletes the previous one; with the default, each such deploy would retain another billed snapshot. See Cost of retained versions.
• Limits. SnapStart cannot be combined with provisioned concurrency, EFS, S3 Files, or ephemeral storage above 512 MB.

serverless remove

This deletes the function, its versions and snapshots, and the ECR repository the Framework created.