Explore how the latest Lambda SnapStart support for Python dramatically reduces cold start times in AWS Lambda, helping organizations improve application responsiveness, enhance user experience, and deliver faster, more reliable serverless performance.
Learn how reframing modernization as a product strategy, instead of a code exercise, helps teams accelerate value delivery, lower costs, and unlock scale through clear goals, strong leadership, and true product-engineering partnership.
Explore how CPUs execute code—examining elements such as clock cycles, pipelines, instruction decoding, and branch prediction—and how these architectural details influence cost, performance, and energy efficiency.
Explore how we helped a customer modernize their legacy authentication system with Amazon Cognito.
Juan Cavallo is a Cloud Software Architect at Caylent. Based in Córdoba, Argentina, he has over 20 years of experience in building, optimizing, and designing applications for a wide range of enterprises. He enjoys combining deep technical expertise, cloud-native applications, and user-centered design to achieve business objectives. He is also active in his local AWS community by sharing his knowledge and supporting fellow professionals.
View Juan's articlesApplication responsiveness is one of the most important metrics in system performance. Low latency keeps users engaged, while even small delays increase abandonment rates, reduce conversions, and can lead to revenue loss. For organizations running latency-sensitive workloads, performance is more than a technical consideration–it directly influences business outcomes.
While user experience can sometimes feel subjective, it often comes down to measurable factors like latency. In modern applications, even a delay of more than three seconds can feel slow to users and negatively affect engagement.
This is where infrastructure decisions start to matter. The platforms and services that power an application play a critical role in how quickly it responds to user requests. AWS Lambda provides excellent performance and cost efficiency, but applications that rely on popular libraries can still experience noticeable latency during a cold start.
A cold start occurs when a new AWS Lambda instance initializes for the first time, loading dependencies into memory. This can take several seconds. While subsequent invocations reuse the same execution environment, the first user to trigger a new instance may experience a delay. With AWS Lambda SnapStart, these delays can be reduced significantly, leading to faster response times and an improved user experience.
Building on the insights from the blog AWS Lambda Performance Boost with SnapStart, and the latest Lambda SnapStart support for Python and .NET (November 2024), this post explores key considerations, cost and performance implications, and a practical example of how to implement SnapStart effectively.
AWS Lambda SnapStart is a feature that significantly reduces cold start times for AWS Lambda functions. It reduces cold start times by capturing and reusing a snapshot of a Lambda function’s initialized execution environment. When a new instance starts, Lambda restores this snapshot instead of initializing from scratch, improving startup performance.
AWS Lambda SnapStart is especially valuable for latency-sensitive or irregular workloads, such as:
AWS Lambda SnapStart is available for:
If you’re running an earlier runtime (for example, Python 3.11), you’ll need to upgrade and test your Lambda before implementing AWS Lambda SnapStart.
As of today, AWS Lambda SnapStart is available in all Commercial Regions, except Asia Pacific (New Zealand) and Asia Pacific (Taipei).
While Lambda SnapStart offers major performance improvements, some limitations and architectural nuances are important to consider:
Unsupported Features
Handling Unique and Dynamic Data: If your startup code produces distinctive data embedded in the snapshot, such as random numbers or cryptographic processes, this data may lose its uniqueness when reused in different execution environments. To preserve uniqueness when using AWS Lambda SnapStart, you must produce distinctive content after initialization.
Network Connections: Network connections established during initialization are not guaranteed to remain active when Lambda resumes from a snapshot. It is crucial to verify the status of your network connections and reestablish them if necessary. Update your code so that connection variables are defined and initialized after the function starts running, ensuring reliable connectivity.
Temporary Data: Some functions may generate temporary data, such as credentials, during the initialization phase. To improve security and consistency, create this ephemeral data within the function handler instead.
Encryption of Snapshots: By default, the AWS Lambda SnapStart snapshots are encrypted at rest using AWS KMS Key. If you prefer to use a Customer Managed Key, you may need to update or create the function with the following command: --kms-key-arn
For example: update-function-configuration --function-name TestSnapStart --kms-key-arn <key-arn>
Versions and Alias: It's important to understand how function versioning works, as AWS Lambda SnapStart is triggered during the release of a function version. Every time you publish a new version of your Lambda function, AWS initializes the function, captures a snapshot of its execution environment, and caches it for future invocations. Utilizing function aliases can simplify the management of event sources and AWS IAM policies. By pointing an alias to the latest published version, you can manage deployments more effectively and implement traffic shifting strategies.
AWS Lambda SnapStart costs are based on two types:
When you enable AWS Lambda SnapStart, each published function version incurs costs for caching and maintaining the snapshot.
Example:
A 1 GB function active for an entire month (30 days) would cost:
$0.0000015046 × 86,400 seconds × 30 days = $3.90
Each time a function instance is restored from a snapshot, AWS charges a restore fee.
Example:
If a 1 GB function is restored 10,000 times in a month:
$0.0001397998 × 10,000 = $1.40
The minimal additional cost is a worthwhile investment for delivering a faster, more seamless user experience that directly impacts customer satisfaction. Function cost will ultimately vary based on configuration and usage frequency. For many teams, this means assessing it through the lens of a broader business case.
The following scenarios demonstrate where optimizing startup latency can directly influence user experience, efficiency, and revenue:
In summary, for these use cases where user experience is critical and initial delay can significantly impact engagement, sales, or customer satisfaction, Lambda SnapStart offers a significant advantage by minimizing startup latency, enabling efficient scalability, and improving overall application performance.
You can enable this feature using several methods, including the AWS Management Console, AWS CLI, AWS CloudFormation, AWS SAM, or AWS CDK.
For this example, we will use a simple Python-based Lambda to implement a chatbot. The function loads libraries into memory and responds with 'hello world.' This setup allows us to focus on comparing initialization time versus recovery time with Lambda SnapStart to demonstrate its performance benefits.
The Runtime Python 3.12 will use the following libraries:
We will implement the function using only the AWS Management Console for simplicity, with the corresponding code and results shown below.
The zip file will consist of requirements.txt and lambda_function.py, as well as all the libraries required by the application. The libraries are installed with the command below:
Requirements.txt:
lambda_function.py:
Step 1: Create the lambda function by selecting the name and the runtime “Python 3.12”:
Step 2: Upload the zipped file with the library files, requirements.txt, and lambda_function.py
Step 3: Create a Test Event using the template: “API Gateway AWS Proxy”, filling “Event Name” and replacing in the JSON, the method to “GET”, and path to “/”. Click Save.
This is a smaller event that we can use to test:
Step 4: Run the test to verify it’s working as expected.
Step 5: Go to the “Configuration” tab and in “General Configuration” and click Edit. We need to increase the memory size to 256MB and change the Lambda SnapStart option to “Published Versions” and click save.
This will increase memory and enable Lambda SnapStart, allowing us to use it in published versions.
Step 6: In the “Versions” tab, we will publish a new version with the description “Test SnapStart”, which will create version 1 of the Lambda.
It’s important to note that while Version 1 and $LATEST share the same code, executing $LATEST will not use Version 1. Instead, it runs the Lambda function without SnapStart, as SnapStart applies only to published versions.
Instead of manually updating the version after each deployment, create an alias like “Dev” and associate it with Version 1 (which uses Lambda SnapStart). Then, in your API Gateway integration, replace the $LATEST reference to the Dev alias. This way, you ensure that Lambda SnapStart is always used without manual intervention.
Whenever we deploy a new code, we will need to create a New Version and change the Alias to the version that we need to execute.
Step 7: Test the Lambda without SnapStart to see the initialization time. To do this, return to the main function view by selecting the function name to exit the specific version.
In the “Test” tab, execute the test created from Step 3 and check the Init Duration. In this case, it was 4754.89ms. It’s important to check this metric because it represents the time taken for the Lambda function to initialize before processing requests.
A lower initialization duration indicates better performance and reduced latency for end users, which is crucial for applications where quick response times are essential, such as chatbots or real-time data processing.
Step 8: Test the Lambda with SnapStart to see the Init Duration. The expected time should drop to something more effective, with less than 1 second being the target value.
In the “Alias” tab, click on “Dev” to get the latest version.
In the “Test” tab, execute the same test and check the Restore Duration label to see how long it took Lambda to restore from memory. In this case, it is 700ms.
Based on the initial test results, running the function without Lambda SnapStart produced an Init Duration of 4.5 seconds. This means the first call to the Lambda execution will take about 4.5 seconds to initialize, which can negatively impact the user experience.
Executing the alias that points to the Lambda SnapStart-enabled version resulted in a 700 ms restore time from cache, significantly improving performance and reducing the latency perceived by users.
The following executions will be almost the same on each new execution.
Without Lambda SnapStart:
With Lambda SnapStart:
AWS Lambda SnapStart offers a powerful optimization for Python-based AWS Lambda functions, significantly reducing cold start times and improving user experience. By leveraging snapshots of pre-initialized execution environments, Lambda SnapStart transforms high-latency cold starts into near-instantaneous restores, making serverless applications more responsive.
Our implementation example demonstrated that enabling Lambda SnapStart reduced the cold start from approximately 4.5 seconds to just 700ms—a dramatic improvement that enhances performance, particularly for latency-sensitive applications like chatbots, real-time analytics, and financial services.
While there are some compatibility considerations and additional costs associated with Lambda SnapStart, these are generally outweighed by the performance gains, especially for business-critical workloads where responsiveness is key.
By carefully evaluating your application's needs and AWS Lambda configuration, you can determine if Lambda SnapStart is a worthwhile investment. In many cases, the improved user experience and reduced waiting times will justify the minor additional costs, making AWS Lambda SnapStart an essential tool for optimizing serverless applications.
At Caylent, we help organizations optimize performance, cost, and scalability across their serverless architectures. As an AWS Premier Tier Services Partner with deep experience in AI-driven delivery and modern application design, our engineers work closely with customers to assess where features like AWS Lambda SnapStart deliver the most impact. Whether you’re modernizing legacy services or scaling high-traffic applications, our proven accelerators and deep AWS expertise ensure your applications stay performant, secure, and ready to evolve. Contact us today to get started.
Juan Cavallo
pip install -r requirements.txt -t . --upgrade
Flask==3.1.0
aws-wsgi==0.2.7
langchain==0.3.19
langchain_aws==0.2.12
from langchain.chat_models import init_chat_model
from pydantic import BaseModel, Field
from typing import Optional
import awsgi
from flask import (
Flask,
jsonify,
)
llm = init_chat_model(
"anthropic.claude-3-5-sonnet-20240620-v1:0", model_provider="bedrock_converse")
# Pydantic
class Joke(BaseModel):
"""Joke to tell user."""
setup: str = Field(description="The setup of the joke")
punchline: str = Field(description="The punchline to the joke")
rating: Optional[int] = Field(
default=None, description="How funny the joke is, from 1 to 10"
)
structured_llm = llm.with_structured_output(Joke)
app = Flask(__name__)
@app.route('/')
def index():
return jsonify(status=200, message='Hello world!')
def lambda_handler(event, context):
return awsgi.response(app, event, context)
{
"body": "eyJ0ZXN0IjoiYm9keSJ9",
"resource": "/{proxy+}",
"path": "/",
"httpMethod": "GET",
"isBase64Encoded": true,
"queryStringParameters": {
},
"pathParameters": {
"proxy": "/"
}
}
Duration: 47.32 ms Billed Duration: 48 ms Memory Size: 256 MB Max Memory Used: 187 MB Init Duration: 4566.69 ms
Duration: 182.96 ms Billed Duration: 270 ms Memory Size: 256 MB Max Memory Used: 183 MB Restore Duration: 700.61 ms Billed Restore Duration: 87 ms
Duration: 2.03 ms Billed Duration: 3 ms Memory Size: 256 MB Max Memory Used: 187 MB
Duration: 2.25 ms Billed Duration: 3 ms Memory Size: 256 MB Max Memory Used: 187 MB
Duration: 1.97 ms Billed Duration: 2 ms Memory Size: 256 MB Max Memory Used: 187 MB
Duration: 2.10 ms Billed Duration: 3 ms Memory Size: 256 MB Max Memory Used: 184 MB
Duration: 1.80 ms Billed Duration: 2 ms Memory Size: 256 MB Max Memory Used: 184 MB
Duration: 1.99 ms Billed Duration: 2 ms Memory Size: 256 MB Max Memory Used: 184 MB
Caylent Catalysts™
Design new cloud native applications by providing secure, reliable and scalable development foundation and pathway to a minimum viable product (MVP).
Caylent Services
Quickly establish an AWS presence that meets technical security framework guidance by establishing automated guardrails that ensure your environments remain compliant.