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
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
- Supported Regions
- Compatibility considerations
- SnapStart pricing
- Comparing Lambda SnapStart and provisioned concurrency
- Additional resources
- Activating and managing Lambda SnapStart
- Handling uniqueness with Lambda SnapStart
- Implement code before or after Lambda function snapshots
- Monitoring for Lambda SnapStart
- Security model for Lambda SnapStart
- Maximize Lambda SnapStart performance
- Troubleshooting SnapStart errors for Lambda Java functions
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, 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
Regions. Charges apply each time that Lambda re-runs your initialization code in another Region.
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