AWS SnapStart improves Lambda functions and cold start times

AWS SnapStart is a new feature that can significantly reduce cold start times for Java-based Lambda functions, leading to faster and more responsive applications. This feature enables initialization ahead of time, which ensures quick access to resources and improved application performance, resulting in better user experiences. 

This article delves into the details of how to get started with SnapStart and explore the benefits it can bring to serverless computing environments. By optimizing Java-based Lambda functions with SnapStart, you can unlock the full potential of serverless computing and streamline operations workflow.

Put simply, SnapStart is designed to improve the startup times of Java-based Lambda functions. 

Every function goes through an initialization stage when it's invoked for the first time. This requires downloading the function's code and initializing any external frameworks or libraries. Depending on the size and complexity of the function as well as the dependencies it uses, the process can take several seconds from start to finish. This is known as a cold start.

In the case of Java apps built with frameworks, cold starts on Lambda are significant. For developers building user-facing APIs or synchronous apps with Java, these numbers are not a good fit for some below-latency requirements. Even though latency during cold starts isn't a Java-specific problem, when paired with one of the many popular frameworks, Java functions on Lambda can be a headache for developers. This is one reason why AWS created SnapStart. 

With SnapStart, AWS handles initialization ahead of time in a way that speeds up Java functions considerably. The feature also requires minimal code changes by developers. 

One key benefit of using AWS Lambda functions is the ease with which developers can build and deploy powerful serverless applications. With a simple programming model and seamless integration with other AWS services, developers can quickly and easily create applications that are scalable and secure.

On the operations side, Lambda also offers significant benefits, particularly when it comes to managing evolving usage patterns. Because Lambda functions are fully managed by AWS, organizations can easily scale their applications up or down in response to demands, without worrying about managing infrastructure or provisioning new resources. This ensures an organization's applications are always available and responsive, even during peak usage times.

Another unique benefit of SnapStart is that developers no longer need to choose between the tools they prefer and good performance. Before SnapStart, if these developers wanted to implement serverless Lambda functions, they faced a dilemma: Suffer the slow cold starts of their Java functions or refactor their code in another language. Now, these devs no longer have to choose. 

Enabling Lambda SnapStart for a Lambda function triggers an optimization process that can significantly improve invocation times and predictability. After SnapStart is enabled, publishing a new version of the function will launch the function and run it through the entire initialization phase. During this process, an immutable and encrypted snapshot of the memory and disk state is taken and cached for future use within a Firecracker microVM by AWS Lambda. 

When the function is invoked, Lambda uses this cached state to populate the execution environment instead of stepping through the full initialization process. This approach eliminates the need for a dedicated initialization phase during subsequent invocations, making invocation times faster and more predictable. However, there are a few noteworthy specifics you'll want to know ahead of time.

Since Lambda uses a snapshot of a function for repeated environments, it's important to be aware of some considerations relative to a function's initialization phase. If a function relies on certain elements during initialization, you may need to make some adjustments before implementing SnapStart.

• Uniqueness 

Since AWS Lambda initializes a function's execution environments from the same snapshot image, data generated during the initialization phase will not be unique following restoration. This means anything like a unique ID that's used to generate pseudo-randomness requires placement outside of the initializer function. You can read more about handling Lambda uniqueness in the AWS Lambda docs.

• Network connections

In most instances, network connections established by the AWS SDK are resumed automatically. With SnapStart, there's no guarantee the state of connections will carry over from the snapshot when it's initialized across environments. This requires validating and reestablishing any connections needed during initialization.

• Temporary data

If the function initializes any temporary credentials or timestamps, refresh it within the function handler before using this ephemeral data. This is a good practice even when it's not within a SnapStart-enabled function.

SnapStart requires the Java 11 or Java 17 Lambda runtime. To get started, use Amazon Coretto 11 to build your application code and create a Lambda function with SnapStart enabled using the Lambda console, AWS CLI, or AWS APIs. You can also declare SnapStart functions in infrastructure-as-code using CloudFormation, SAM or CDK. Complete instructions for each method can be found on the activation page of the SnapStart documentation. 

Capital One tested SnapStart during the beta period with Java-based applications across a variety of use cases and Java frameworks, including Spring. Once SnapStart was implemented, these cold start times dropped to under a second. Measured across these functions, cold start times were reduced by an average of 88%. Even Java applications without Spring saw a 15% gain in start times. 

There are a few details to know when implementing SnapStart for Java functions:

• All snapshots are deleted after 14 days of inactivity. With that said, Lambda refreshes this cache if it depends on a patched or updated runtime.
• SnapStart cannot be used with provisioned concurrency. The same goes for Graviton2, elastic file systems or any ephemeral storage. 
• SnapStart is currently available in the following AWS regions. 

1. Is there any environment variable to indicate whether the current invocation is resumed from a snapshot?

If the AWS_LAMBDA_INITIALIZATION_TYPE Lambda environment variable equals "snap-start," the function was initiated using SnapStart. You can also monitor SnapStart functions from your Amazon CloudWatch stream using the Lambda Telemetry API.

2. How does the snapshot work with database connections?  

Since SnapStart restores function state from a previously initialized function, you'll need to think about the way you write functions that use database connections. You might opt for one-time data access during the initialization phase, which can then be reused. If there's a chance the database credentials could change, you'll need error handling in your function to account for that.

SnapStart is a powerful feature that offers an improvement in startup latency and cold start times of serverless functions. By using SnapStart, users can see faster cold start times, improved scalability, and reduced costs. Give it a try for yourself and see how it can benefit your own Java-based Lambda functions. With the right setup and a few code changes, SnapStart can help you take full advantage of serverless computing.

To get started with SnapStart, check out the AWS News launch blog or the AWS Lambda Developer Guide.