Lambda has cold starts that frustrate us
Cold start under 100 ms is realistic for Node and Python, under 50 ms with SnapStart or provisioned concurrency. For latency-critical work, a container platform is sometimes simply better than tuning FaaS.
Try this first
- 1Measure first: how often does cold start happen (X-Ray or CloudWatch insights). If < 1 percent, often a UX tweak (skeleton loaders) is fine.
- 2For Java or .NET on Lambda: enable SnapStart. Halves cold start often from seconds to hundreds of ms. Free.
- 3For consistent cold start under 50 ms: provisioned concurrency. Costs money (flat monthly), do the math.
- 4Shrink the deployment package: fewer deps, esbuild for Node, GraalVM native-image for Java. A 5 MB zip starts faster than a 50 MB zip.
- 5For really latency-critical web: consider App Runner, Container Apps or Cloud Run. They keep warm pools and have less dramatic cold starts.
When to bring us in
Going into tens of thousands of requests per day with an SLA on p99 latency, a session covering Lambda tuning, instance type and SnapStart together is worth it.
See also
- Everyone logs in with the AWS root accountRoot is for emergencies and billing. Day-to-day work belongs in IAM users or SSO.
- Every developer has AdministratorAccessAdministratorAccess everywhere is convenient now, painful later. Start with role-based policies.
- Everyone has individual IAM users with their own passwordIdentity Center (formerly AWS SSO) links to your IdP and issues temporary credentials per session.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.