AWS Lambda SnapStart for Python to Eliminate Cold Starts

Overview

If you’ve built APIs or data pipelines on AWS Lambda with Python, you’ve felt the pain of cold starts. That first invocation after your function scales up or sits idle can take 2-5 seconds, an eternity when a user is waiting for a response. AWS Lambda SnapStart for Python changes that equation entirely, delivering sub-second startup performance with minimal effort.

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

AWS Lambda SnapStart

AWS Lambda SnapStart is a performance optimization that tackles the root cause of cold starts: initialization time. When you publish a function version with SnapStart enabled, Lambda runs your initialization code, then takes a Firecracker microVM snapshot of the entire memory and disk state of that initialized environment. It encrypts and caches that snapshot.

When invocations arrive, whether it’s the first call or a scale-up event, AWS Lambda resumes execution environments from the cached snapshot rather than initializing from scratch. Your imports, SDK client instantiations, database connection pools, and model loading all happen once during the snapshot phase, not on every cold start.

AWS SnapStart for Python became generally available in late 2024 and expanded to 23 additional AWS regions in June 2025, making it accessible to most production workloads globally.

Enabling SnapStart: It’s Surprisingly Simple

The basic setup requires no code changes. In a SAM template, you add two properties:

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Handler: app.handler
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live

If you're using the AWS CDK:

from aws_cdk import aws_lambda as _lambda
fn = _lambda.Function(self, "MyFunction",
    runtime=_lambda.Runtime.PYTHON_3_12,
    handler="app.handler",
    code=_lambda.Code.from_asset("lambda"),
    snap_start=_lambda.SnapStartConf.ON_PUBLISHED_VERSIONS
)
version = fn.current_version

Resources:

MyFunction:

Type: AWS::Serverless::Function

Properties:

Runtime: python3.12

Handler: app.handler

SnapStart:

ApplyOn: PublishedVersions

AutoPublishAlias: live

If you're using the AWS CDK:

from aws_cdk import aws_lambda as _lambda

fn = _lambda.Function(self, "MyFunction",

runtime=_lambda.Runtime.PYTHON_3_12,

handler="app.handler",

code=_lambda.Code.from_asset("lambda"),

snap_start=_lambda.SnapStartConf.ON_PUBLISHED_VERSIONS

)

version = fn.current_version

One critical detail: SnapStart only works on published function versions, not $LATEST. You must publish a version (or use AutoPublishAlias) for the snapshot to be created.

Runtime Hooks: The Power Feature

While basic SnapStart requires no code changes, runtime hooks let you control exactly what happens before and after the snapshot. Python provides two decorators from the snapshot_restore_py module:

from snapshot_restore_py import register_before_snapshot, register_after_restore
import psycopg2
import os

db_connection = None

@register_before_snapshot
def before_snapshot():
    global db_connection
    # Establish connection during init — it gets snapshotted
    db_connection = psycopg2.connect(os.environ["DATABASE_URL"])
    # Run a simple query to warm the connection
    db_connection.cursor().execute("SELECT 1")

@register_after_restore
def after_restore():
    global db_connection
    # Old connection is stale after restore — reconnect
    if db_connection:
        db_connection.close()
    db_connection = psycopg2.connect(os.environ["DATABASE_URL"])

def handler(event, context):
    cursor = db_connection.cursor()
    cursor.execute("SELECT * FROM users WHERE id = %s", (event["user_id"],))
    return {"user": cursor.fetchone()}

from snapshot_restore_py import register_before_snapshot, register_after_restore

import psycopg2

import os

db_connection = None

@register_before_snapshot

def before_snapshot():

global db_connection

# Establish connection during init — it gets snapshotted

db_connection = psycopg2.connect(os.environ["DATABASE_URL"])

# Run a simple query to warm the connection

db_connection.cursor().execute("SELECT 1")

@register_after_restore

def after_restore():

global db_connection

# Old connection is stale after restore — reconnect

if db_connection:

db_connection.close()

db_connection = psycopg2.connect(os.environ["DATABASE_URL"])

def handler(event, context):

cursor = db_connection.cursor()

cursor.execute("SELECT * FROM users WHERE id = %s", (event["user_id"],))

return {"user": cursor.fetchone()}

The @register_before_snapshot hook runs during initialization before Lambda captures the snapshot. Use it to pre-warm anything expensive: load ML models, parse configuration, and establish connections. The @register_after_restore hook runs whenever AWS Lambda resumes from a snapshot. Use it to refresh anything that becomes stale: reconnect to databases, re-seed random number generators, fetch fresh credentials.

Important: if you define hooks in a separate module, that module must be imported in your handler file. Lambda ignores hooks in files that aren’t part of the import chain.

The Uniqueness Trap

This is where developers get bitten. When Lambda takes a snapshot, everything in memory gets frozen including any random values, UUIDs, or temporary tokens you generated during initialization. Every execution environment resumed from that snapshot starts with identical values.

Bad pattern:

import uuid
# This UUID is the same across ALL execution environments
REQUEST_ID_PREFIX = str(uuid.uuid4())

def handler(event, context):
    # Every concurrent invocation uses the same prefix
    request_id = f"{REQUEST_ID_PREFIX}-{uuid.uuid4()}"

import uuid

# This UUID is the same across ALL execution environments

REQUEST_ID_PREFIX = str(uuid.uuid4())

def handler(event, context):

# Every concurrent invocation uses the same prefix

request_id = f"{REQUEST_ID_PREFIX}-{uuid.uuid4()}"

Fixed pattern:

import uuid

REQUEST_ID_PREFIX = None

@register_after_restore
def after_restore():
    global REQUEST_ID_PREFIX
    REQUEST_ID_PREFIX = str(uuid.uuid4())

def handler(event, context):
    request_id = f"{REQUEST_ID_PREFIX}-{uuid.uuid4()}"

import uuid

REQUEST_ID_PREFIX = None

@register_after_restore

def after_restore():

global REQUEST_ID_PREFIX

REQUEST_ID_PREFIX = str(uuid.uuid4())

def handler(event, context):

request_id = f"{REQUEST_ID_PREFIX}-{uuid.uuid4()}"

Move any randomness, unique identifiers, or time-sensitive values to @register_after_restore or into the handler itself.

Limitations to Know

AWS Lambda SnapStart has clear boundaries:

Cannot combine with Provisioned Concurrency — choose one or the other
No Amazon EFS or Amazon S3 Files support — if your function mounts a filesystem, SnapStart isn’t an option
Ephemeral storage capped at 512 MB — functions requiring more /tmp space are excluded
Container images not supported — only zip-based deployments with managed runtimes (Python 3.12+)
Infrequently invoked functions may not benefit — AWS Lambda needs to keep snapshots cached; very low traffic means snapshots may expire

Pricing: Not Free, But Usually Worth It

Unlike Java (which gets SnapStart at no extra cost), Python and .NET SnapStart incur two charges:

Caching charge — based on your function’s memory allocation, charged for as long as the version exists (minimum 3 hours)
Restore charge — a small per-invocation fee each time Lambda resumes from the snapshot

For high-traffic APIs, this is almost always cheaper than Provisioned Concurrency. For a function with 256 MB memory handling thousands of requests per hour, the SnapStart cost is negligible compared to keeping provisioned instances warm 24/7. For functions invoked once a day, the caching charge may not justify the latency improvement.

When to Choose SnapStart vs. Alternatives?

Choose SnapStart when you have a latency-sensitive function with heavy initialization (imports, SDK clients, model loading) and moderate-to-high traffic. It’s the best balance of cost and performance for most production APIs.
Choose Provisioned Concurrency when you need guaranteed sub-10ms cold starts with zero variance — financial trading systems, real-time gaming backends, or strict SLA requirements.
Choose neither when your function is lightweight (few dependencies, fast imports) and cold starts are already under 500ms.

Conclusion

AWS Lambda SnapStart for Python removes one of the last major friction points in serverless Python development. The setup is minimal, the improvement is dramatic (often a 3-5x reduction in cold-start latency), and the runtime hooks give you precise control over the snapshot lifecycle.

If you’re running Python Lambdas in production and cold starts are costing you user experience or SLA compliance, AWS Lambda SnapStart should be your first move, not provisioned concurrency, not over-engineering your deployment packages.

Drop a query if you have any questions regarding AWS Lambda SnapStart, and we will get back to you quickly.

Empowering organizations to become ‘data driven’ enterprises with our Cloud experts.

Reduced infrastructure costs
Timely data-driven decisions

Get Started

About CloudThat

CloudThat is an award-winning company and the first in India to offer cloud training and consulting services worldwide. As an AWS Premier Tier Services Partner, AWS Advanced Training Partner, Microsoft Solutions Partner, and Google Cloud Platform Partner, CloudThat has empowered over 1.1 million professionals through 1000+ cloud certifications, winning global recognition for its training excellence, including 20 MCT Trainers in Microsoft’s Global Top 100 and an impressive 14 awards in the last 9 years. CloudThat specializes in Cloud Migration, Data Platforms, DevOps, Security, IoT, and advanced technologies like Gen AI & AI/ML. It has delivered over 750 consulting projects for 850+ organizations in 30+ countries as it continues to empower professionals and enterprises to thrive in the digital-first world.

FAQs

1. Does AWS Lambda SnapStart work with $LATEST?

ANS: – No, it only works on published function versions.

2. Can I use AWS Lambda SnapStart with Provisioned Concurrency?

ANS: – No, they are mutually exclusive, pick one.

3. Do I need to change my code?

ANS: – Usually not, unless you generate unique values (like UUIDs) during initialization.

WRITTEN BY Esther Jelinal J

Esther Jelinal J is a Research Associate at CloudThat, working as a Full Stack Developer with a strong focus on backend development. She is skilled in technologies such as React.js, Node.js, JavaScript, Python, PostgreSQL, and AWS. With a strong passion for cloud technologies, Esther is growing her expertise as a cloud-native developer. She is enthusiastic about exploring emerging technologies and has the potential to build innovative, scalable solutions.