AWS Lambda SnapStart is a great new feature that can help your team save money and improve performance on time critical workloads. However, before you jump on the bandwagon, there are a few things you need to know. In this blog post, we will talk through the information you need to make an informed decision about whether or not AWS Lambda SnapStart is right for your team. This can be broken down into four topics: Runtime, Compliance and Release Rigor and Validated Design Patterns.
Runtime
The first piece of bad news is that unless your team is using Java, AWS SnapStart isn't supported for your chosen runtime. Java is one of the slower performing runtime environments in Lambda, due to some of the Java frameworks which are amazing for development purposes, but are designed for servers which handle many transactions simultaneously, and where a slower initialization time is not very significant. AWS Lambda SnapStart solves this problem for Lambda, but performing the initialization once, taking a snapshot of the memory, then streaming the memory to the lambda function. This allows the Java Lambda function to perform extremely well, and reduces the cold start time of the Lambda Function dramatically.
If you're not using Java, there's unfortunately not much you can do to take advantage of AWS Lambda SnapStart right now. AWS is working on bringing this feature to other runtime environments, but there's no set release date yet. So for now, you'll just have to drool and wait.
Compliance
AWS Lambda SnapStart images are encrypted at rest, but there isn't a lot documented on its compliance with regulations other than GDPR. It's important to wait for AWS Lambda SnapStart is compliant with your specific regulatory requirements before using this feature. AWS is typically lightning fast when doing these, and so it shouldn't be long before it's compliance has been certified.
Release Rigor
Even if your team is good at automating and validating new code, AWS Lambda SnapStart is going to offer a new wrinkle. Since initialization happens once, a glitch or race condition can bring down your whole system without a chance for recovery. This can be mitigated by having a robust release process in place that includes automated testing and validation in production after release, which not all teams do. By ensuring that your code is always ready to go after it's released through automation, you can minimize the risk of any problems with AWS Lambda SnapStart.
Your operation's run books will also have to change to include steps to initiate the rebuild of the AWS Lambda SnapStart image, which previously would not have been present. This won't be a big lift potentially, but having a plan around this aspect will be critical to maintain stability in your production systems.
Validated Design Patterns
If your team likes stability and well laid paths, there is soon going to be many examples of design patterns on how to optimize AWS Lambda SnapStart, and when it's not applicable. AWS has a fantastic library of design patterns, which are well tested and known to work and come from a variety of sources both inside and outside AWS being leveraged for real production workloads. Innovators are jumping onto AWS Lambda SnapStart right now, digging into it and trying out approaches to best leverage it. So if you're looking for a more stable path with AWS Lambda, wait for the whitepapers, blog articles and stack overflow discussions, and use the patterns that are outlined therein.
Conclusion
AWS Lambda SnapStart is one of the most exciting announcements from AWS re:Invent 2022. I've been talking with innovators at the conference about what they're planning to use it for and there is definitely a buzz. That said, it's not available for all languages yet and the knowledge base of production experience with it is still small. If you are an innovator, this is a great time to jump in, but if your team needs stability, it might not be the right time.