Lambda has been my favorite service for years. When I need to stand up a POC or a pilot, nothing beats it — I can deploy code in minutes, wire it to an event, and pay only for what actually runs. So it always stung a little that the standard architecture review for a real time inference endpoint ended the same way: “Lambda would be perfect for this… except cold starts.” Bursty traffic, event driven triggers, pay per use economics — serverless was the obvious fit on paper, and then someone would pull up a P99 latency chart and the conversation moved to a container platform or a provisioned endpoint instead.

That objection just lost most of its teeth — and the timing could not be better. With frontier AI taking off, the workloads I most want to prototype on Lambda are exactly the ones cold starts punished hardest. With Lambda SnapStart now supporting container image functions, the single biggest reason architects steered AI workloads away from Lambda is largely gone — and the design conversation shifts from “how do we survive cold starts” to “how do we design our init phase to be snapshotted.”

Why cold starts are especially brutal for AI

I learned this the hard way. A cold start is Lambda running your initialization code — loading the function, starting the runtime, and executing everything outside the handler — before it can serve the first request. For the plain CRUD functions I’d been happily shipping for years, that’s tens of milliseconds and nobody notices. The first time I dropped a model into a function, I found out that an AI workload is a different universe.

Three things stack up. First, the container image is large. A model runtime plus its transitive dependency tree — think a framework, a tokenizer library, numeric packages, and a CUDA adjacent stack — routinely produces images in the multi gigabyte range. Second, importing those dependencies is expensive: pulling a large ML framework into memory and resolving its native extensions can burn several seconds on its own, before you’ve touched a model. Third, and worst, you load weights at init. Reading a few hundred megabytes of parameters off disk or out of S3 and deserializing them into memory is the dominant cost, and it happens on every cold start.

Add those together and a “warm” invocation that returns in 80 ms is sitting behind a cold start path that takes five to ten seconds. I’ve watched a demo that flew on my laptop fall apart the moment a few concurrent requests forced Lambda to scale out into fresh environments. For a real time inference or agentic tool call, that is not a tail latency nuisance — it is timeouts, blown SLAs, and a genuinely bad user experience the moment traffic spikes. The cold start tax is levied precisely when you can least afford it.

What SnapStart for container images actually is

SnapStart attacks the problem at the mechanism level rather than asking you to shrink your dependencies. When you publish a function version, Lambda runs your function through the entire Init phase once, then takes a Firecracker microVM snapshot of the memory and disk state of that fully initialized environment, encrypts it, and caches it. On a subsequent cold start, Lambda does not re-run your initialization — it restores the microVM from that snapshot and jumps straight to handling the request.

The strategic point for AI workloads: your model load, your framework imports, your client construction all happen once, at publish time, and get frozen into the snapshot. Every future scale-out event restores from that frozen, ready to serve state instead of paying the multi second init bill again.

SnapStart itself is not new — it has been available for zip packaged functions across Java, Python, and .NET. What changed is that it now works for container image functions, and for me that’s the whole story. Containers are how I actually package these workloads. The 250 MB unzipped limit on zip functions and layers was always a poor fit for the gigabyte scale ML stacks I was building; the 10 GB container image support was the natural home. Until now I had to choose: container packaging or snapshot acceleration. I can finally have both.

How to make it work well

Here’s the mental model I’ve settled on. SnapStart rewards a specific architectural discipline: make the init phase do the expensive work, because init is what gets snapshotted.

Concretely, move model loading, dependency imports, and client/session setup to module scope — outside the handler — so they execute during Init and land in the snapshot:

# Runs at Init -> captured in the snapshot
import torch
from my_runtime import load_model

MODEL = load_model("/opt/ml/model")   # heavy: happens once, at publish
MODEL.eval()

def handler(event, context):
    # Warm path only: no model load here
    return MODEL.infer(event["input"])

The catch is uniqueness, and it’s the one that bit me. When Lambda restores many environments from one snapshot, any state created during init is shared across all of them — seeded random number generators, unique IDs, cached credentials, open connections. Freeze a database connection into the snapshot and you will hand every restored environment a stale, possibly closed socket. Seed a PRNG at init and every environment produces the same “random” sequence. I’ve debugged exactly that, and staring at duplicate “random” IDs across invocations is a humbling afternoon.

The fix is runtime hooks. For container images you implement before-snapshot and after-restore hooks so that the runtime coordinates the lifecycle. Use the before-checkpoint hook to gracefully close connections you don’t want frozen, and the after-restore hook to regenerate anything that must be unique: re-seed entropy, refresh temporary credentials, and re-establish network connections. Note the budget — after-restore work counts against a 10-second restore timeout, so keep it lean.

A few more practical levers:

• Right-size memory. Memory scales CPU on Lambda, and restore plus after-restore work is CPU sensitive. For model serving functions, more memory usually pays for itself in lower restore and inference time.
• Mind the image and layers. Snapshotting doesn’t excuse a sloppy image. Put model weights and heavy dependencies in stable lower layers, keep your handler code in a thin top layer, and you improve both build hygiene and load behavior.
• Verify against real deployments. Restore latency depends on snapshot size, so benchmark P99 with your actual model rather than trusting a hello world number.

When it’s the right call — and when it isn’t

I want to be honest about the boundaries, because I’ve talked myself into using Lambda where I shouldn’t have. SnapStart on containers is a strong fit for bursty, spiky inference: workloads that idle then spike, where you’d otherwise overpay for always on capacity or eat cold starts on every scale-out. It’s excellent for agentic tool calls, where an orchestrator fans out to many short lived, independently scaling functions, and for RAG retrieval endpoints that load an embedding model and query a vector store. These are exactly the prototypes I keep reaching for right now.

It is a weaker fit in two cases. For sustained, high throughput inference that keeps environments warm anyway, provisioned concurrency or a dedicated container platform can still win on steady state cost and predictability — SnapStart’s advantage is amortizing init across intermittent cold starts, which matters less when you rarely have one. And for very large models needing GPU acceleration, Lambda is the wrong tool entirely; those belong on dedicated GPU endpoints such as SageMaker. SnapStart accelerates CPU bound init, not the physics of serving a 70B-parameter model.

The takeaway

Serverless AI just got materially more viable, and my favorite service is back on the table for the workloads I care about most. The reflexive “cold starts kill us” objection — the one that ended so many of my architecture reviews — no longer holds for a large and growing class of inference and agentic workloads. That doesn’t mean the work disappears; it moves. The new discipline is designing your init phase for snapshotting: front load the expensive work, handle uniqueness with runtime hooks, and right-size for restore.

1. Audit your init phase. Everything expensive — model load, imports, client setup — should run outside the handler so it lands in the snapshot.
2. Handle uniqueness explicitly. Use before-snapshot and after-restore hooks to close/reopen connections, refresh credentials, and re-seed entropy.
3. Benchmark P99 with your real model, not a toy function, and right-size memory to the restore path.
4. Pick the fit deliberately — bursty inference and agentic tool calls, yes; sustained high throughput or GPU bound serving, look elsewhere.
5. Revisit dismissed designs. Endpoints you ruled out over cold starts deserve a second look.

The objection didn’t just weaken — it changed shape. I’m already reopening a couple of “we can’t use Lambda for that” calls I made last year. Which of yours are you ready to revisit?