"Java is too slow for Lambda" was true for a long time. A Spring Boot function could spend many seconds on a cold start — booting the JVM, building the Spring context, creating SDK clients — before handling a single request. In 2026 there are four real options for running Java on AWS Lambda, and they trade off very differently.

In July 2026, AWS published a benchmark comparing all four with identical Spring Boot 4.0.6 applications on Java 25, across CPU-bound, mixed and I/O-bound workloads. Its numbers give a useful, vendor-measured starting point.

6–14 s
Standard Lambda
cold start
2–7 s
With
SnapStart
None
Lambda Managed
Instances

Option 1: standard Lambda

No changes, simplest operations, and the worst cold starts — 6 to 14 seconds in AWS's benchmark. Fine for low-traffic or asynchronous workloads where an occasional slow start doesn't matter. The Java 25 managed runtime (available since November 2025) also uses the JDK's new ahead-of-time caches to trim startup.

Option 2: SnapStart — the default choice

SnapStart initializes your function once when you publish a version, snapshots the whole execution environment, and restores from that snapshot on cold starts. AWS's benchmark measured cold starts of 2 to 7 seconds, and AWS recommends it as the default for Java functions. On Java 25, Lambda also no longer stops JIT compilation at the C1 tier for SnapStart and Provisioned Concurrency, so warm performance improves too.

Two things matter in code. First, anything created during initialization is shared by every restored environment — random seeds, unique IDs, cached credentials, open connections. Second, you can make restores faster by priming: exercising your code paths before the snapshot so classes are loaded and code is compiled. Both are handled with CRaC runtime hooks:

PrimingResource.java
@Component public class PrimingResource implements Resource { private final LoanService loanService; public PrimingResource(LoanService loanService) { this.loanService = loanService; Core.getGlobalContext().register(this); } @Override public void beforeCheckpoint(Context<? extends Resource> context) { loanService.validate(LoanRequest.sample()); // warm up hot paths before the snapshot } @Override public void afterRestore(Context<? extends Resource> context) { // re-create anything that must be unique per environment } }

SnapStart only works on published versions, not $LATEST, so point your aliases and API Gateway integrations at versions.

Option 3: GraalVM native image

Compiling ahead of time into a native binary skips JVM startup entirely: AWS measured cold starts of roughly 0.8 to 2 seconds and the smallest memory footprint. The cost is a more complex build, reflection configuration, and compatibility testing — AWS's benchmark also saw a higher error rate from SDK compatibility issues. Worth it for bursty traffic with strict latency needs, if the team can invest in the toolchain. Note that Spring Boot 4 requires GraalVM 25 or later for native images.

Option 4: Lambda Managed Instances — no cold starts

Lambda Managed Instances run your functions on managed EC2 instances in your account and keep the JVM alive across invocations. That removes cold starts and lets the JIT compiler fully optimize hot code. In AWS's benchmark, median latency improved 18–30% over standard Lambda and worst-case latency improved dramatically — the slowest request on a CPU-bound workload was 489 ms instead of over 13 seconds. Pricing is per instance rather than per request, which AWS says becomes cheaper than standard Lambda for steady traffic above roughly 9 requests per second.

Choosing between them
Low or spiky traffic, cold starts acceptable: standard Lambda. Variable traffic, cold starts matter: SnapStart, with priming — the sensible default. Bursty traffic, sub-second cold starts required, team willing to own a native build: GraalVM native image. Steady traffic (roughly 5+ requests per second) with a tight p99 SLA: Lambda Managed Instances. And if a service is really a long-running API with steady load, compare against plain containers on ECS or EKS too.

Whatever you choose, keep initialization lean — the same principle behind faster Spring Boot startup with the Java AOT cache.

Frequently asked questions

How do I reduce Java cold starts on AWS Lambda?

Enable SnapStart and prime your code with CRaC hooks, use the Java 25 runtime, keep initialization lean, or remove cold starts entirely with Lambda Managed Instances. GraalVM native images give the fastest cold starts at the cost of a more complex build.

Does AWS Lambda support Java 25?

Yes. AWS Lambda has supported Java 25 as a managed runtime and container base image since November 2025, including runtime changes that use Java's ahead-of-time caches to improve cold starts.

What are AWS Lambda Managed Instances?

A Lambda capability that runs functions on managed EC2 instances in your account and keeps the execution environment alive across invocations, which removes cold starts and lets the JVM's JIT compiler fully optimize. It uses instance-based pricing.

Four options: standard, SnapStart, native image, Managed Instances.
SnapStart + priming is the sensible default for Java functions.
Beware state captured in snapshots; use CRaC afterRestore hooks.
Managed Instances remove cold starts for steady, latency-sensitive traffic.