Juan Cavallo
Caylent Catalysts™
Serverless App
Design new cloud native applications by providing secure, reliable and scalable development foundation and pathway to a minimum viable product (MVP).
Improving User Experience in AWS Lambda Using SnapStart for Python
Infrastructure & DevOps Modernization
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.
Application 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.
What is AWS Lambda SnapStart?
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:
- Chatbots and virtual assistants
- The backend of a mobile banking application
- Event-driven workloads with inconsistent traffic
- Serverless applications requiring fast response times
When and Where to Use AWS Lambda SnapStart
AWS Lambda SnapStart is available for:
- Java (11 and later)
- Python (3.12 and later)
- .NET (8 and later) – If you're using the Lambda Annotations framework for .NET, upgrade to Amazon.Lambda.Annotations version 1.6.0 or later to ensure compatibility with AWS Lambda SnapStart.
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).
Compatibility and Design Considerations
While Lambda SnapStart offers major performance improvements, some limitations and architectural nuances are important to consider:
Unsupported Features
- Provisioned Concurrency
- Amazon Elastic File System (EFS)
- Ephemeral storage greater than 512MB
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.
Costs and Benefits
AWS Lambda SnapStart costs are based on two types:
Caching
When you enable AWS Lambda SnapStart, each published function version incurs costs for caching and maintaining the snapshot.
- Pricing: The cost depends on the memory allocated to the function.
- Minimum charge: You are billed for at least 3 hours of cache duration, with ongoing charges while the function remains active.
- Recommendation: Delete unused function versions to avoid unnecessary charges.
- Rate: $0.0000015046 per GB-second.
Example:
A 1 GB function active for an entire month (30 days) would cost:
$0.0000015046 × 86,400 seconds × 30 days = $3.90
Restoration
Each time a function instance is restored from a snapshot, AWS charges a restore fee.
- Pricing: The price depends on the amount of memory allocated to the function and is charged for each new lambda that is fired, not for subsequent executions once it is initialized.
- Benefits: The main advantage of AWS Lambda SnapStart is that it significantly reduces the initial latency. Functions that previously took around 5 seconds to initialize (e.g., using Flask or similar libraries) can drop to sub-second startup times, improving user experience and making full use of serverless technologies.
- Rate: $0.0001397998 for every GB restored
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:
- AI Generation: Real-time content generation applications, such as language models or recommendation systems, rely on quick responses to keep users engaged. With Lambda SnapStart, initial latency is significantly reduced, allowing for a smoother and more satisfying interaction. This is crucial because users expect immediate responses, especially in interactive applications where delay can lead to frustration and abandonment.
- Chatbots: For chatbots, response speed is fundamental to simulating natural conversation. High latency can make the interaction feel artificial or slow. Lambda SnapStart ensures that the chatbot is ready to respond almost instantly, improving user experience and the effectiveness of customer service.
- Home Banking: In the financial services sector, where security and speed are essential, reducing initial latency can significantly improve the user experience. Customers expect transactions and queries to be processed without delay, and any lag can negatively impact the perception of reliability and efficiency.
- E-commerce: In e-commerce, every millisecond counts. High latency can lead to higher cart abandonment rates and lost sales. Lambda SnapStart helps ensure that pages load quickly, even during traffic spikes like sales events or promotions. This not only improves user experience but can also directly increase revenue by reducing load times and improving conversion rates.
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.
Implementation
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:
- Flask
- aws-wsgi
- LangChain
We will implement the function using only the AWS Management Console for simplicity, with the corresponding code and results shown below.
Code
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:
pip install -r requirements.txt -t . --upgrade
Requirements.txt:
Flask==3.1.0
aws-wsgi==0.2.7
langchain==0.3.19
langchain_aws==0.2.12
lambda_function.py:
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)
Deployment
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:
{
"body": "eyJ0ZXN0IjoiYm9keSJ9",
"resource": "/{proxy+}",
"path": "/",
"httpMethod": "GET",
"isBase64Encoded": true,
"queryStringParameters": {
},
"pathParameters": {
"proxy": "/"
}
}
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.
Results
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.
Duration: 47.32 ms Billed Duration: 48 ms Memory Size: 256 MB Max Memory Used: 187 MB Init Duration: 4566.69 ms
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.
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
The following executions will be almost the same on each new execution.
Without Lambda SnapStart:
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
With Lambda SnapStart:
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 MBConclusion
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.
How Caylent Can Help
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.
Infrastructure & DevOps Modernization
Juan Cavallo
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 articles
Related Blog Posts
Integrating MLOps and DevOps on AWS
From notebooks to frictionless production: learn how to make your ML models update themselves every week (or earlier). Complete an MLOps + DevOps integration on AWS with practical architecture, detailed steps, and a real case in which a Startup transformed its entire process.
Analytical AI & MLOps
Infrastructure & DevOps Modernization
Generative AI & LLMOps
Modernization Isn’t a Technical Decision. It’s the Key to Product Success.
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.
Infrastructure & DevOps Modernization
Why Arm Is Winning in the Cloud and How Your Team Can Profit From It
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.
Infrastructure & DevOps Modernization