Improving startup performance with Lambda SnapStart - AWS Lambda
Supported features and limitationsSupported RegionsCompatibility considerationsPricingSnapStart and provisioned concurrencyAdditional resources

Improving startup performance with Lambda SnapStart

Lambda SnapStart for Java can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. The largest contributor to startup latency (often referred to as cold start time) is the time that Lambda spends initializing the function, which includes loading the function's code, starting the runtime, and initializing the function code.

With SnapStart, Lambda initializes your function when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When you invoke the function version for the first time, and as the invocations scale up, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup latency.

Important

If your applications depend on uniqueness of state, you must evaluate your function code and verify that it is resilient to snapshot operations. For more information, see Handling uniqueness with Lambda SnapStart.

Topics

Supported features and limitations

SnapStart supports Java 11 and later Java managed runtimes. Other managed runtimes (such as nodejs20.x and python3.12), OS-only runtimes, and container images are not supported.

SnapStart does not support provisioned concurrency, the arm64 architecture, Amazon Elastic File System (Amazon EFS), or ephemeral storage greater than 512 MB.

To work with SnapStart, you can use the Lambda console, the AWS Command Line Interface (AWS CLI), the Lambda API, the AWS SDK for Java, AWS CloudFormation, AWS Serverless Application Model (AWS SAM), and AWS Cloud Development Kit (AWS CDK). For more information, see Activating and managing Lambda SnapStart.

Note

You can use SnapStart only on published function versions and aliases that point to versions. You can't use SnapStart on a function's unpublished version ($LATEST).

Supported Regions

SnapStart is available in the following AWS Regions:

  • US East (N. Virginia)

  • US East (Ohio)

  • US West (N. California)

  • US West (Oregon)

  • Africa (Cape Town)

  • Asia Pacific (Hong Kong)

  • Asia Pacific (Mumbai)

  • Asia Pacific (Hyderabad)

  • Asia Pacific (Tokyo)

  • Asia Pacific (Seoul)

  • Asia Pacific (Osaka)

  • Asia Pacific (Singapore)

  • Asia Pacific (Sydney)

  • Asia Pacific (Jakarta)

  • Asia Pacific (Melbourne)

  • Canada (Central)

  • Europe (Stockholm)

  • Europe (Frankfurt)

  • Europe (Zurich)

  • Europe (Ireland)

  • Europe (London)

  • Europe (Paris)

  • Europe (Milan)

  • Europe (Spain)

  • Middle East (UAE)

  • Middle East (Bahrain)

  • South America (São Paulo)

Compatibility considerations

With SnapStart, Lambda uses a single snapshot as the initial state for multiple execution environments. If your function uses any of the following during the initialization phase, then you might need to make some changes before using SnapStart:

Uniqueness

If your initialization code generates unique content that is included in the snapshot, then the content might not be unique when it is reused across execution environments. To maintain uniqueness when using SnapStart, you must generate unique content after initialization. This includes unique IDs, unique secrets, and entropy that's used to generate pseudorandomness. To learn how to restore uniqueness, see Handling uniqueness with Lambda SnapStart.

Network connections

The state of connections that your function establishes during the initialization phase isn't guaranteed when Lambda resumes your function from a snapshot. Validate the state of your network connections and re-establish them as necessary. In most cases, network connections that an AWS SDK establishes automatically resume. For other connections, review the best practices.

Temporary data

Some functions download or initialize ephemeral data, such as temporary credentials or cached timestamps, during the initialization phase. Refresh ephemeral data in the function handler before using it, even when not using SnapStart.

SnapStart pricing

There's no additional cost for SnapStart. You're charged based on the number of requests for your functions, the time that it takes your code to run, and the memory configured for your function. Duration is calculated from the time that your code begins running until it returns or otherwise ends, rounded up to the nearest 1 ms.

Duration charges apply to code that runs in the function handler, initialization code that's declared outside of the handler, the time it takes for the runtime (JVM) to load, and any code that runs in a runtime hook. For more information about how Lambda calculates duration, see Monitoring for Lambda SnapStart.

For functions configured with SnapStart, Lambda periodically recycles the execution environments and re-runs your initialization code. For resiliency, Lambda creates snapshots in multiple Availability Zones. Charges apply each time that Lambda re-runs your initialization code in another Availability Zone. For more information about how Lambda calculates charges, see AWS Lambda Pricing.

Comparing Lambda SnapStart and provisioned concurrency

Both Lambda SnapStart and provisioned concurrency can reduce cold starts and outlier latencies when a function scales up. SnapStart helps you improve startup performance by up to 10x at no extra cost. Provisioned concurrency keeps functions initialized and ready to respond in double-digit milliseconds. Configuring provisioned concurrency incurs charges to your AWS account. Use provisioned concurrency if your application has strict cold start latency requirements. You can't use both SnapStart and provisioned concurrency on the same function version.

Note

SnapStart works best when used with function invocations at scale. Functions that are invoked infrequently might not experience the same performance improvements.

Additional resources

In addition to reading the other topics in this chapter, we also recommend that you try the Starting up faster with AWS Lambda SnapStart workshop and watch the Fast cold starts for your Java functions session from AWS re:Invent 2022.