AWS Lambda SnapStart
AWS Lambda SnapStart for Python and .NET functions is now generally available. It offers faster function startup performance, ranging from a few seconds to as little as a sub-second, usually requiring little to no code changes in Python, C#, F#, and Powershell.
AWS released Lambda SnapStart for Java functions on November 28, 2022, which can increase startup speed by up to ten times. Without allocating resources or investing time in intricate performance optimizations, Lambda SnapStart allows you to minimize outlier latencies caused by initializing functions.
Any one-time initialization code that is, code that executes only the first time a Lambda function is called can have its snapshotted memory and disk state cached and reused via Lambda SnapStart. Lambda creates a snapshot of the initialized execution environment’s memory and disk state using Firecracker microVM, encrypts it, and caches it for low-latency access.
Lambda improves startup latency by starting fresh execution environments from the cached snapshot rather than initializing them from scratch when you call the function version for the first time and as the invocations scale up. Using AWS Lambda, Lambda SnapStart makes it simple to create responsive and highly scalable Python and.NET applications.
Initialization code can cause a startup lag of several seconds for Python functions. This can happen, for example, while utilizing frameworks like Flask or Django or loading dependencies like LangChain, Numpy, Pandas, and DuckDB. Depending on the size of the model being utilized, loading ML models during initialization can take tens of seconds for many functions that also use Lambda for machine learning (ML) inference. For these situations, starting latency can be lowered from several seconds to as little as a sub-second by using Lambda SnapStart.
Because.NET just-in-time (JIT) compilation can take several seconds, it anticipates that most use cases will benefit from.NET functions. Customers have long been discouraged from using.NET for AWS Lambda due to the latency uncertainty that comes with initializing Lambda services. SnapStart caches a snapshot of a function’s memory and disk state so that it can resume fast. As a result, Lambda SnapStart will significantly reduce latency variability for the majority of.NET functions.
How to begin using Lambda SnapStart for.NET and Python
To begin, you can activate, update, and remove SnapStart for Python and.NET functions using the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDKs.
To use Lambda SnapStart, navigate to the Functions page in the AWS Lambda console and select your function. Choose General Configuration after selecting Configuration, and then select Edit. The Edit basic settings page displays SnapStart options.
Python 3.12 and later, as well as managed runtimes for.NET 8 and later, can be used to activate Lambda functions. After selecting Published versions, select Save.
Lambda initializes your code, takes a snapshot of the initialized execution environment, and caches the snapshot for low-latency access whenever you publish a new version of your function. To verify that SnapStart is activated, you can use the function.
To update the function configuration, use the AWS CLI command update-function-configuration with the –snap-start option.
Use the publish-version command to make a function version public.
Use the get-function-configuration command and enter the version number to verify that SnapStart is enabled for the function version.
A snapshot is available for the designated function version if the response indicates that OptimizationStatus is On and State is Active, indicating that SnapStart is engaged.
Runtime hooks
Code that was executed either before Lambda creates a snapshot or after Lambda resumes a function from a snapshot can be run using runtime hooks. Runtime hooks are helpful for cleaning up or releasing resources, updating configuration or other metadata dynamically, integrating with external systems or services (e.g., updating external state or sending notifications), and optimizing your function’s startup sequence (e.g., by preloading dependencies).
The open source Snapshot Restore for Python library, which is a component of the Python controlled runtime, offers Python runtime hooks. Two decorators, @register_before_snapshot, which execute before Lambda creates a snapshot, and @register_after_restore, which execute when Lambda resumes a function from a snapshot, are provided by this library.
This Python handler example demonstrates how to execute code both before and after checkpointing:
from snapshot_restore_py import register_before_snapshot, register_after_restore
def lambda_handler(event, context):
# handler code
@register_before_snapshot
def before_checkpoint():
# Logic to be executed before taking snapshots
@register_after_restore
def after_restore():
# Logic to be executed after restore
.NET runtime hooks that are included in the Amazon.Lambda.Core package (version 2.5 or later) from NuGet can also be used. This library offers two methods: RegisterAfterRestore(), which runs after a function is resumed from a snapshot, and RegisterBeforeSnapshot(), which runs before to snapshot creation.
Things to be aware of
You should be aware of the following regarding Lambda SnapStart:
- Managing uniqueness: If the content generated by your initialization code is unique and included in the snapshot, it will not be exceptional when it is reused in different execution settings. Suppose your code uses bespoke random number generation that doesn’t rely on built-in libraries or caches any information, such as DNS records, that can expire during startup. In that case, you must produce unique content after initialization to maintain uniqueness when using SnapStart.
- Performance tuning: AWS advises you to initialize resources that cause startup latency and preload dependencies in your initialization code rather than in the function handler to optimize performance. By removing the latency brought on by extensive class loading from the invocation pipeline, SnapStart’s startup performance is improved.
- Networking best practices: When Lambda resumes your function from a snapshot, the connections that your function made during the initialization phase may not be in the same state. Network connections created by an AWS SDK are often automatically reestablished.
- Function monitoring: You can use AWS X-Ray active tracing, Amazon CloudWatch log stream, the Telemetry API, Amazon API Gateway, and function URL metrics to get real-time telemetry data for extensions.
AWS Lambda SnapStart for Python and.NET functions is now accessible in the following AWS regions: Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), US East (N. Virginia), US East (Ohio), and US West (Oregon).
SnapStart pricing
For applications that are sensitive to latency, SnapStart can reduce starting time from many seconds to as little as a sub-second. In order to provide low-latency access, SnapStart takes a snapshot of the initialized memory (and disk) state of your function and caches it. Lambda reduces startup time by starting execution environments from this pre-initialized snapshot rather than starting them from scratch when your function is later called.
Every time you publish a new version of your function with SnapStart enabled, a snapshot is produced. For a minimum of three hours and then every millisecond after that, you will be charged for caching a snapshot while your function version is in use. The cost is determined by how much memory you give your function. Additionally, you pay a fee based on how much memory you devote to your function each time Lambda restores your snapshot to resume an execution environment.
SnapStart charges come in two flavors for the Python and.NET managed runtimes: the cost of caching a snapshot for each function version you publish with SnapStart enabled, and the cost of restoration for each instance of a function that is restored from a snapshot. Therefore, to lower your SnapStart cache expenses, remove any function versions that aren’t being used. For more pricing details Visit the AWS Lambda pricing page.
