Is AWS Lambda SnapStart Right for Your Workload?

AWS Lambda SnapStart replaces the Init Duration with a Restore Duration.

One could argue that this is merely a name change and that cold starts remain an issue.

In this post, let's explore whether this is true, under what circumstances, and when you should consider Lambda SnapStart for your AWS Functions.

Thanks to AWS for sponsoring this article in my AWS Lambda Series.

What is AWS Lambda SnapStart?

If you are entirely new to AWS Lambda SnapStart, I highly recommend checking out the blog post below to get you up to speed.

Getting Started with AWS Lambda SnapStart: A Beginner’s Guide

AWS Lambda SnapStart is a performance optimization that speeds up startup times for Lambda Functions, typically with no changes to your function code. Let’s learn how to enable it on your existing functions, how it works under the hood and make sure your Lambda Functions are SnapStart ready.

Rahul NathRahul Pulikkot Nath

AWS Lambda SnapStart is a performance optimization that speeds up startup times for Lambda Functions, typically with no changes to your function code.

AWS Lambda creates the VM snapshot and sets up everything when you publish a Lambda version with SnapStart enabled.

When the published Lambda version with SnapStart enabled is invoked, the logs no longer have the initialization phase, so they do not show the Init Duration.

However, it does show a 'Restore Duration' now, which we will explore shortly.

Restore Duration is the time Lambda requires to resume an execution environment from a cached snapshot. It includes:

Restore Duration vs Init Duration - AWS Lambda SnapStart

One could argue that the Restore Duration replaces the Init Duration with AWS Lambda SnapStart.

This is true.

If the cold start times/init duration are already in the range of milliseconds, the Restore Duration could be equal to or even greater than the Init Duration, meaning SnapStart's benefits may not be as noticeable.

In such cases, the overhead introduced by restoring the execution state might not justify using SnapStart.

However, when the Init Duration is in seconds, the benefit of using SnapStart becomes more apparent.

In these cases, the Restore Duration offers a significantly faster startup time because it skips much of the initialization process by resuming from a pre-warmed, serialized state.

This drastically reduces cold start latency, especially for workloads highly sensitive to startup times.

Comparing Init vs Restore Duration for different workloads

The impact of SnapStart varies depending on the function’s Init Duration.

Let's compare two workloads—one with an Init Duration in milliseconds and another in seconds—to see how SnapStart affects startup performance in each case.

Below are the CloudWatch LogInsights logs showing the Restore Duration and Init Duration for the function we built in the Getting Started with AWS Lambda SnapStart.

Before enabling SnapStart, the function has an average Init duration of ~550ms.

After enabling SnapStart, the Restore Duration averages around the same and sometimes even more.

Enabling SnapStart in these scenarios where the Init duration is already in the milliseconds does not yield much gain to us.

I modified the same function to introduce a further delay in the constructor to simulate a more significant Init Duration.

It now has a 5-second delay, which could be the case for some of your production workloads, especially if you are hosting a full ASP.NET API or similar workloads.

public Function()
{
    _configuration = ReadConfigFromS3();

    SnapshotRestore.RegisterAfterRestore(() =>
    {
        _constructorId = Guid.NewGuid();
        return ValueTask.CompletedTask;
    });

    Task.Delay(TimeSpan.FromSeconds(5)).Wait();
}

In this case, before enabling SnapStart, the Init Duration shows 5550ms in the logs below.

However, with Lambda SnapStart enabled, the Restore Duration averages ~350m,s, significantly lower than the Init Duration.

Enabling SnapStart is beneficial in scenarios like this, where the Init Duration is significant (in seconds).

How Lambda SnapStart Improves Scalability

By improving startup times, SnapStart helps reduce the number of execution environments (and thus cold starts) required as your function scales.

For example, imagine your function handles 10 requests over 3 seconds, and without SnapStart, it has a 6-second cold start. This would require Lambda to create 10 concurrent execution environments, resulting in 10 cold starts.

With SnapStart, if the cold start is reduced to 1 second, Lambda would only need to create four concurrent execution environments capable of handling four requests in the first second.

These same four environments would then be reused to handle the remaining requests over the next two seconds, reducing the overall cold start impact and improving scalability.

The complete source code and the Powershell scripts are available here.