What is AWS Lambda and when would you use it?

Lambda is a taxi driver 🚕. You don't own the car or keep it idling in a garage — one shows up when you need a ride (an event), drives, and you pay only for the trip. No passengers, no cost.

Cold start, mechanically: on the first invocation (or after enough idle time that AWS reclaims the environment), Lambda has to provision a fresh execution environment — download the deployment package, start the runtime, run any code outside the handler (imports, SDK client construction, connection pool setup) — before the handler itself runs. That init cost is the cold start; a warm invocation reuses an already-initialized environment and skips straight to the handler. Provisioned concurrency pre-initializes a set number of environments ahead of traffic so requests hit warm environments on demand, at the cost of paying for that reserved capacity whether it's used or not.

Two hard limits shape when Lambda fits: a single invocation can run at most 15 minutes, so anything longer needs Step Functions, Fargate, or a traditional server. And Lambda's memory setting isn't just RAM — CPU and network bandwidth scale proportionally with the memory you allocate, so a CPU-bound function that's slow isn't necessarily under-provisioned on logic, it may just be under-provisioned on memory (raising memory can make a compute-heavy function finish faster and, counterintuitively, cost about the same or less, since you pay for memory × duration and a faster function needs less duration).

Concurrency, not requests-per-second, is the limit that actually throttles Lambda. Every AWS account has a regional concurrent executions ceiling (1,000 by default, raisable by support request) shared across every function in the account unless carved up — one invocation in flight counts as one unit of concurrency for as long as it runs, so a function that takes 5 seconds under sustained load needs roughly 5× the concurrency of one that takes 1 second to sustain the same request rate. Reserved concurrency caps how much of that shared pool one function can consume (protecting other functions from being starved by one noisy neighbor, at the cost of that function throttling once its own reservation is exhausted); provisioned concurrency additionally pre-warms environments within that reservation. Exceeding available concurrency doesn't queue politely — synchronous invocations (API Gateway) return a 429 TooManyRequestsException immediately, while asynchronous invocations (S3, EventBridge) retry automatically and eventually land in a configured dead-letter queue or destination if retries are exhausted.

Java specifically has a worse cold start than Python/Node, and SnapStart is AWS's fix for it. JVM startup plus class loading plus framework initialization (Spring context, DI wiring) routinely pushes Java cold starts into the hundreds of milliseconds to low seconds, versus tens of milliseconds for an interpreted-language runtime with little to no framework overhead. SnapStart takes a different approach than shrinking the package or trimming dependencies: it initializes the function once, takes a Firecracker microVM snapshot of that fully-initialized execution environment (including the already-warmed JVM), and restores from that snapshot on every subsequent cold start instead of re-running initialization from scratch — turning a JVM-startup-sized cold start into essentially a restore-from-snapshot-sized one, at the cost of needing to handle any state that shouldn't be reused across invocations (like a fixed seed used at snapshot time) explicitly via a runtime hook.

Keywords they're listening for: