Lambda Java Cold Starts: SnapStart, Provisioned Concurrency, GraalVM

Intermediate·4 min read·

Fast recall

Quick revision

Core answer

Java cold starts on Lambda are 1–3 seconds — the JVM needs to classload, JIT-warm, and initialize Spring context. Mitigations in order of impact: (1) SnapStart — snapshots a warmed JVM; drops cold starts to ~200ms; free; works with Spring. (2) Provisioned Concurrency — keeps N instances always warm; no cold starts but you pay for idle. (3) GraalVM native image — compile to a native binary; ~100ms cold start; build complexity. (4) Right-size memory — more memory = more CPU; often cheaper to use 1024MB than 512MB because it runs faster. (5) Minimize deps — smaller JAR = faster class load.

Interview Answer4 min

Java cold starts on Lambda used to be the biggest pain — 1 to 3 seconds to class-load the JVM, initialize Spring context, create beans, JIT-warm. That made Lambda unsuitable for user-facing APIs in Java for years. SnapStart changed that in late 2022.

SnapStart — the default answer in 2026

AWS takes a snapshot of your Lambda after Spring initialization and restores new invocations from that snapshot instead of cold-booting
Cold starts drop from 1 to 3 seconds down to roughly 200 milliseconds
It's free; works with Spring Boot, Micronaut, Quarkus
Enable via versioned and aliased deployment; without publishing versions it silently doesn't apply

The caveats to plan for

SecureRandom and UUID.randomUUID() return identical values across restored instances if seeded before snapshot; re-seed in a runtime hook
Network connections made before snapshot are dead after restore; lazy-init DB pools, HTTP clients, SDK clients
Spring provides hooks for this; third-party libraries may not — test your specific stack

Provisioned Concurrency — for zero cold starts

Keep N instances always warm; you pay for the provisioned time even when idle (~$13/month per instance at 512MB)
Use when SnapStart's 200ms isn't good enough — critical user-facing endpoints, payment APIs
Combine with auto-scaling: scale up during business hours, down at night
Trade-off: cost of idle time vs value of zero cold starts

GraalVM native image — for strict requirements

Compile Java to a native binary; no JVM, no class loading; cold starts around 100 milliseconds
Build complexity: reflection hints needed for frameworks and third-party libs; 2-5 minute builds vs 30 seconds for JAR
Worth it when SnapStart isn't enough and Provisioned Concurrency gets too expensive at scale
Pairs well with Quarkus or Micronaut (better native support than Spring Boot)

Memory right-sizing is under-used

Lambda CPU scales with memory: 1769MB = 1 full vCPU
A Spring init that takes 3s at 512MB may take 1.5s at 1024MB
You pay GB-seconds; doubling memory while halving duration is cost-neutral or cheaper because Lambda rounds to 1ms
Use AWS Lambda Power Tuning to find the sweet spot empirically

Framework choice matters

Spring Cloud Function is convenient but adds init time vs raw handler
Micronaut and Quarkus are designed for fast startup and low memory; both boot in under 500ms on JVM and under 100ms native
For cold-start-sensitive workloads, picking a lighter framework is more impactful than tuning heavy frameworks

The strategic answer

Start with SnapStart for everything — free, works, good enough for most APIs
Add Provisioned Concurrency for endpoints where 200ms breaks UX
Consider GraalVM or lighter frameworks only if SnapStart isn't enough
Always measure with X-Ray or Datadog APM — distinguish init time from handler time; many teams blame cold starts for problems that are actually in the handler

The architectural answer

Lambda is great for event-driven, spiky, short workloads
For sustained-traffic user-facing APIs, Fargate or App Runner often make more sense — no cold starts, similar or lower cost above a certain RPS
Don't force-fit Java Lambda for workloads it's not designed for

Interview-ready guide

Interview answer