How does AWS Lambda SnapStart reduce cold starts for Java functions, and what correctness pitfalls does its snapshot-and-restore approach introduce that provisioned concurrency doesn't have?

## How the cache-and-restore mechanism works **SnapStart** is AWS Lambda's cache-and-restore approach to eliminating cold starts, initially launched for Java and later extended to other runtimes, and it takes a fundamentally different mechanism from either standard on-demand cold starts or provisioned concurrency. Instead of re-running the full initialization sequence (runtime bootstrap plus your function's init code) on every cold environment, or continuously paying to keep environments warm and idle, SnapStart runs that expensive initialization exactly once — when you publish a new function version — and then captures a snapshot of the fully initialized execution environment's memory and disk state at the microVM level (Lambda runs on **Firecracker microVMs**, which support this kind of snapshot/restore natively). That snapshot is encrypted and cached. From then on, whenever Lambda needs a new environment for that version, instead of booting the JVM and running your class-loading, static initializers, and DI wiring from scratch, it restores the microVM directly from the cached snapshot — resuming execution from the point right after initialization finished, skipping the expensive work entirely. For Java specifically, this routinely cuts cold starts from the 1-6+ second range down to a few hundred milliseconds or less, because the JVM startup and Spring/framework wiring cost, which dominates Java cold starts, is paid exactly once per deployed version rather than once per cold environment. ## Why the feature is there **Why this exists.** Provisioned concurrency solves the cold-start problem by paying continuously for standby capacity, which is effective but costly and requires capacity planning. SnapStart instead attacks the root cause — redundant, repeated initialization work — directly, and it does so without any continuous billing for idle capacity; you pay only a modest fee for the snapshot cache and normal per-invocation compute, making it attractive for workloads that are latency-sensitive but too spiky or low-traffic to justify continuously reserved provisioned concurrency. It essentially amortizes the one-time init cost across the entire lifetime of a function version instead of across just the invocations served by one warm environment. ## The correctness trade-off: frozen state The trade-off, and where it gets genuinely tricky, is correctness around captured state. Because the snapshot freezes the entire process memory at a specific point in time, anything your init code computed or cached before the snapshot was taken gets baked into every single future restore, identically, unless you explicitly intervene. Concretely: - **(1) Random number generators** — if a cryptographic RNG seeds itself once during init and the snapshot captures that seeded state, every restored environment could, absent mitigation, produce the same sequence of *random* values, a serious security problem for anything generating tokens, nonces, or keys. AWS's Java runtime tooling for SnapStart specifically re-seeds common entropy sources on restore to guard against this, but developers using custom RNGs or unusual libraries must handle it themselves. - **(2) Cached credentials or short-lived tokens** (e.g., an STS token or DB auth token fetched once at init and stored in a static field) will be stale — restored environments keep serving that frozen, possibly-expired credential until something refreshes it, causing intermittent auth failures that only affect restored, not freshly-cold-started, environments. - **(3) Open network connections and file handles** captured in the snapshot (e.g., a database connection pool opened at init) are frozen mid-connection and typically won't actually work after restore, since the underlying TCP connection state on the server side may have moved on, producing connection-reset or similar errors on the first request after restore. - **(4) Timestamps or UUIDs** computed once at init and cached in a static field will be identical (and increasingly stale) across every restored environment, which can violate uniqueness assumptions downstream. ## The mitigation — runtime hooks The mitigation Lambda provides is runtime hooks — `beforeCheckpoint` and `afterRestore` callbacks (via the **CRaC**, Coordinated Restore at Checkpoint, API for Java) that let your code explicitly close things down before the snapshot is taken and reopen/re-derive fresh state right after each individual restore, e.g., - re-seeding RNGs; - re-establishing DB connections; - re-fetching credentials. This shifts correctness responsibility onto the developer in a way provisioned concurrency never requires, since provisioned concurrency environments are fully live, continuously-running processes with no snapshot/restore semantics — their state is always genuinely fresh from a real, uninterrupted init run. ## In the field A concrete scenario: a team enabled SnapStart on a Java Lambda that generated one-time authentication codes using a statically initialized `SecureRandom` instance seeded once at cold start. After enabling SnapStart, they began seeing duplicate codes issued across unrelated user sessions in production — traced to multiple restored environments sharing the exact same post-snapshot RNG state. The fix was implementing an `afterRestore` hook to force re-seeding the RNG with fresh entropy on every individual restore, which eliminated the duplication while keeping the cold-start latency win intact.