Serverless was great until we looked past the averages. Our Java + Spring Boot Lambda showed a P50 of 50ms — and a P99 of 8,000ms. Cold starts hit roughly one request in a hundred: invisible in the mean, brutal for whoever drew the short straw.

Why ours was slow

  • JVM startup plus Spring's classpath scanning dominated the 8 seconds
  • A 250MB deployment package that had to be fetched and unpacked first
  • Low, spiky traffic, so warm execution environments kept expiring

One thing that was not the problem: the VPC attachment. We nearly re-architected around 2019-era advice that VPC networking adds one to two seconds per cold start. That has been obsolete since AWS moved Lambda to shared Hyperplane ENIs that same year — VPC cold-start overhead is negligible today. If a blog post tells you otherwise, check its date.

What actually worked

  • Lambda SnapStart, first. It targets exactly this workload: it snapshots the initialized JVM after init and restores from the snapshot instead of booting cold. GA for Java since 2022 (Python and .NET followed in 2024). SnapStart plus snapshot-safe initialization cut our cold starts from ~8 seconds to well under one.
  • Shrink the package. Cutting unused dependencies took us from 250MB to 40MB and shaved the fetch-and-unpack time.
  • Provisioned concurrency where it is actually cheap. We had dismissed it as expensive for low traffic. That was wrong: a single provisioned unit on a 1GB function runs roughly $10 a month. We keep one unit on our only hard-latency endpoint and let SnapStart cover the rest.

What we skipped: scheduled keep-warm pings (fragile, and they only keep one environment warm) and a full rewrite to Node.js — SnapStart made it unnecessary, though for a greenfield low-traffic API a lighter runtime remains a sensible default. If you're new to the platform, our primer on how AWS Lambda works covers the execution-environment lifecycle behind all of this.

After

  • P50: unchanged at ~50ms
  • P99: 8,000ms → ~400ms

Lesson: P99 is where your users actually live — measure cold-start frequency and duration before committing to serverless, and make sure the advice you follow is current. We see teams over-engineer around problems AWS fixed years ago; a short cloud architecture review is cheaper than a rewrite.

← Back to Lessons Learned
Tags: #Serverless #AWS #Lambda #Performance