Accelerate Python and .NET Lambda functions with SnapStart (SVS218-NEW)

Improving Application Performance with AWS Lambda Snap Start

Introduction

  • Leandro Damaso, a senior engineer at AWS, and Sonali, a principal product manager, presented on the new AWS Lambda Snap Start feature.
  • Snap Start is a feature that helps customers reduce the initialization time and cold start latency of their AWS Lambda functions, especially for Python and .NET.

Challenges with AWS Lambda Cold Starts

  • Cold starts occur when a new execution environment needs to be created for a Lambda function, which involves downloading and unpacking the code, bootstrapping the runtime, and initializing the execution environment.
  • This can result in increased latency, especially for Java, .NET, and Python functions.
  • Customers have tried various techniques to mitigate cold starts, such as using only required libraries, keeping the Lambda "warm" through periodic invocations, and leveraging AOT (ahead-of-time) compilation in .NET.

AWS Lambda Snap Start

What is Snap Start?

  • Snap Start is a feature that creates and stores a snapshot of the Lambda execution environment, which can be quickly resumed for subsequent invocations, reducing cold start latency.
  • Snap Start is available for Python 3.12, 3.13, .NET 8, and Java 11, 17, and later versions.

Key Use Cases

  • Latency-sensitive web APIs and applications, where cold start latency is critical.
  • Batch data processing workloads, where outlier functions with longer initialization times can be improved.

How Snap Start Works

  1. When a Lambda function is enabled for Snap Start, the initialization phase is captured and a snapshot of the execution environment is created and stored in a low-latency cache.
  2. Subsequent invocations of the Lambda function can then resume from the stored snapshot, reducing the cold start latency.
  3. The Snap Start state transitions from "pending" to "active" once the snapshot is created and ready for use.

Invocation Model with Snap Start

  • Snap Start uses the Firecracker micro-VM to create and resume the execution environment snapshots, providing both security and low-latency.
  • The initialization phase is captured and stored as a snapshot, while subsequent invocations resume from the stored snapshot.

Specific Use Cases

  1. Large Language Model (LLM) Applications: Snap Start can significantly reduce the cold start latency when using libraries like Langchain, which abstract the complexity of interacting with LLMs.
  2. Data Analysis and Processing: Snap Start can improve the performance of functions that need to load large datasets or complex data processing libraries like DynamoDB, Pandas, and NumPy.

Enabling and Configuring Snap Start

  • Snap Start can be enabled for new or existing Lambda functions, but it only works with published versions or aliases of the function.
  • Snap Start can be enabled through the AWS Console, SDK, CLI, or CloudFormation/SAM.
  • The function state transitions from "pending" to "active" once the snapshot is created and ready for use.

Runtime Hooks for Snap Start

  • Customers can use "before snapshot" and "after restore" hooks to run custom logic before and after the snapshot is created.
  • This allows for tasks like cleanup, initialization, and performance tuning.
  • For Python, the snapshot_restore_for_python project provides decorators and functions to register these hooks.
  • For .NET, the Amazon.Lambda.Core library provides RegisterBeforeSnapshot and RegisterAfterRestore methods.

Considerations when Using Snap Start

  1. Uniqueness: Be careful when dealing with unique values (e.g., cryptographic salts) that should be different across invocations, as the snapshot may cause the same value to be reused.
  2. Version and Alias: Snap Start only works with published versions or aliases of the Lambda function, so ensure you're invoking the correct version.
  3. DNS Caching: Python and .NET runtimes do not cache DNS, unlike Java, so be cautious of libraries that may cache DNS information.
  4. Provisioned Concurrency: Snap Start complements Provisioned Concurrency well, as it can reduce cold start latency for unpredictable spikes in traffic.
  5. Monitoring and Observability: Monitor your Snap Start-enabled functions using CloudWatch, X-Ray, and the Lambda Telemetry API to understand the snapshot creation and restore times.

Best Practices

  • Beware of ephemeral data (e.g., database connections, secrets) that may become invalid after the snapshot is restored.
  • Ensure that your "before snapshot" and "after restore" hooks handle any necessary cleanup or reinitialization.
  • Delete unused function versions to avoid unnecessary snapshot storage and costs.

Pricing

  • Snap Start pricing is based on two dimensions: the amount of caching (GB-seconds) and the number of snapshot restores.
  • The initial snapshot creation carries a minimum charge of 3 hours, after which the pricing is based on the actual duration (per millisecond).
  • The restore charges are based on the number of times the snapshot is used to start a new execution environment.

Your Digital Journey deserves a great story.

Build one with us.

Cookies Icon

These cookies are used to collect information about how you interact with this website and allow us to remember you. We use this information to improve and customize your browsing experience, as well as for analytics.

If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference.

Talk to us