Handling uniqueness with Lambda SnapStart
When invocations scale up on a SnapStart function, Lambda uses a single initialized snapshot to resume multiple execution environments. If your initialization code generates unique content that is included in the snapshot, then the content might not be unique when it is reused across execution environments. To maintain uniqueness when using SnapStart, you must generate unique content after initialization. This includes unique IDs, unique secrets, and entropy that's used to generate pseudorandomness.
We recommend the following best practices to help you maintain uniqueness in your code. For Java functions, Lambda also provides an open-source SnapStart scanning tool to help check for code that assumes uniqueness. If you generate unique data during the initialization phase, then you can use a runtime hook to restore uniqueness. With runtime hooks, you can run specific code immediately before Lambda takes a snapshot or immediately after Lambda resumes a function from a snapshot.
Avoid saving state that depends on uniqueness during initialization
During the initialization phase of your function, avoid caching data that's intended to be unique, such as generating a unique ID for logging or setting seeds for random functions. Instead, we recommend that you generate unique data or set seeds for random functions inside your function handler—or use a runtime hook.
The following examples demonstrate how to generate a UUID in the function handler.
Use cryptographically secure pseudorandom number generators (CSPRNGs)
If your application depends on randomness, we recommend that you use cryptographically secure random number generators (CSPRNGs). In addition to OpenSSL 1.0.2, the Lambda managed runtimes also include the following built-in CSPRNGs:
-
Java:
java.security.SecureRandom
-
Python:
random.SystemRandom
-
.NET:
System.Security.Cryptography.RandomNumberGenerator
Software that always gets random numbers from /dev/random
or /dev/urandom
also maintains randomness with SnapStart.
Amazon cryptography libraries automatically maintain randomness with SnapStart beginning with the minimum versions specified in the following table. If you use these libraries with your Lambda functions, make sure that you use the following minimum versions or later versions:
Library | Minimum supported version (x86) | Minimum supported version (ARM) |
---|---|---|
Amazon libcrypto (Amazon-LC) |
1.16.0 |
1.30.0 |
Amazon libcrypto FIPS |
2.0.13 |
2.0.13 |
If you package the preceding cryptographic libraries with your Lambda functions as transitive dependencies through the following libraries, make sure that you use the following minimum versions or later versions:
Library | Minimum supported version (x86) | Minimum supported version (ARM) |
---|---|---|
Amazon SDK for Java 2.x |
2.23.20 |
2.26.12 |
Amazon Common Runtime for Java |
0.29.8 |
0.29.25 |
Amazon Corretto Crypto Provider |
2.4.1 |
2.4.1 |
Amazon Corretto Crypto Provider FIPS |
2.4.1 |
2.4.1 |
The following examples demonstrate how to use CSPRNGs to guarantee unique number sequences even when the function is restored from a snapshot.
SnapStart scanning tool (Java only)
Lambda provides a scanning tool for Java to help you check for code that assumes uniqueness. The SnapStart scanning
tool is an open-source SpotBugs
To learn more about handling uniqueness with SnapStart, see Starting up faster with Amazon Lambda SnapStart