It can be, if you avoid creating unique values during initialization. SnapStart resumes many execution environments from one snapshot, so IDs, secrets or random seeds created at init may be identical across them. Generate them after restore or in the handler, and use a cryptographically secure random generator.
What SnapStart changes
With SnapStart, the initialization phase runs when you publish a function version. Lambda saves a snapshot of the memory and disk state, encrypts it and caches it. When the function is invoked and as it scales, new environments resume from that snapshot rather than initializing from scratch. AWS says that if init code generates unique content included in the snapshot, the content might not be unique when reused across environments.
That is a security problem when the content is a session key, an identifier you rely on being distinct, or entropy for random numbers.
What AWS says about randomness
The AWS documentation explains that the snapshot includes all application and system memory, so the internal state of every random number generator is preserved, along with any random bytes already stored in memory buffers. On restore, Lambda reseeds the kernel random generator from the system random devices with fresh entropy. Software that reads directly from those devices keeps its randomness. Libraries that cache their own state do not automatically.
AWS recommends cryptographically secure generators and lists built in ones for the managed runtimes that support SnapStart: SecureRandom in Java, SystemRandom in Python and RandomNumberGenerator in .NET. For Go, the standard crypto/rand needs no changes.
What to move out of init
| Created at init | Risk | Fix |
|---|---|---|
| Unique IDs for logging or correlation | Duplicate across environments | Generate in the handler or a post restore hook |
| Random seeds | Same sequence in many environments | Use a secure RNG that reads system entropy |
| Per environment secrets or tokens | Shared by every restored copy | Create after restore, never at init |
| Network connections | May be stale after restore | Re open in a runtime hook |
| Buffered random bytes | Reused | Discard in a post restore hook |
Runtime hooks
AWS provides runtime hooks that run code immediately before a snapshot is taken and immediately after restore. The after restore hook is the place to regenerate unique state. Hooks must finish within the restore time limit, which the documentation gives as 10 seconds, otherwise you get a timeout exception.
Custom base images and libraries
If you use your own base image, AWS says to audit your cryptographic libraries and use a post restore hook to discard cached generator state. It gives the example that Rust code using ThreadRng must reseed after restore. For OpenSSL forks it suggests the provided.al2023 base image with the snapshot safe OpenSSL build, or AWS libcrypto, with minimum versions listed in the documentation.
A short checklist
- Search your init code for UUID, random, token and key generation.
- Move each to the handler or an after restore hook.
- Confirm crypto libraries meet the minimum versions AWS lists.
- For Java, run the AWS provided SnapStart scanning tool, a SpotBugs plugin, to find code that assumes uniqueness.
- Test by invoking concurrently and comparing generated values.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how static findings point to a line. Init time random calls are the kind of pattern worth catching this way.
Quick check
Does SnapStart reuse my secrets?
If your init code creates them, they are part of the snapshot and can be shared by restored environments. Create them after restore.
Which languages support SnapStart?
AWS lists Java 11 or later, Python 3.12 or later and .NET 8 or later among the managed runtimes that support it. Check the current page before relying on it.
Safeguard's code and dependency scanning can flag risky patterns and vulnerable crypto libraries in your repository. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
