Thawing Java on AWS Lambda Reducing Cold Start Times from 11 Seconds to 1
summary
Java Lambda cold starts drop from roughly 11 seconds warm-to-warm to under 1 second by compiling a Spring Cloud Function with GraalVM Native Image (native AOT) — benchmarks show ~200 ms cold starts for Micronaut apps compiled native, versus ~1 s when using Lambda SnapStart snapshots if the full code path is exercised before snapshot. Tradeoffs: native builds take minutes, need reflection metadata and native tests, lose JVM tooling and binary portability; Rust/Go remain faster (~40 ms) but require language switch.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker background
- 2:53Demo setup and Lambda function overview
- 5:19Understanding cold starts and their impact
- 13:29Analyzing cold start causes in Java
- 18:05Just-in-time compilation bottleneck
- 19:30Lambda SnapStart solution explained
- 24:31Rust as an alternative for performance
- 28:48GraalVM native image compilation
- 33:48Drawbacks of GraalVM native compilation
- 42:28Decision flowchart for optimization
- 44:14Q&A and closing remarks
related talks
34mThawing Java on AWS Lambda
51mHow To Reduce Cold Starts for Java Serverless Applications in AWS
53mHigh performance Serverless Java on AWS
19mTen things that improve the performance of your Java based AWS Lambda
56mAfraid of Java cold starts in Serverless? Fear not, Java is fast
44mHow to develop, run and optimize Spring Boot 3 application on AWS Lambda
53mScale up with GraalVM and AWS Lambdas
51mAdapting Java for the Serverless world!