A look at how Amazon Lambda works. AWS Lambda runs your code on demand without you managing servers, and the architectural feat that makes it economically viable is Firecracker microVMs, a purpose-built VMM that boots a fully-isolated VM in ~125 milliseconds. That single engineering choice is what let AWS offer “pay per 100ms of execution” at planet scale.
How Amazon Lambda Works: The problem at scale
Serverless has two impossible-sounding requirements: infinite scale (every concurrent invocation may need its own runtime) and zero cost when idle (no VMs kept warm for an unused function). Containers can’t deliver the first (the per-container overhead is too high), and traditional VMs can’t deliver the second (a kept-warm VM costs money even when idle). The solution had to be a third thing, and Firecracker, announced in 2018, is it.
The core architecture
When a caller (API Gateway, S3 event, EventBridge, etc.) invokes a Lambda function, the request hits the Frontend (Router). The router checks if there’s a warm worker in the Worker Pool for this function+version: if yes, the request is forwarded to the existing microVM in under 50ms. If no warm worker exists, the router triggers the Cold Start Path: a new Firecracker microVM is booted (~125ms), the runtime (Node.js / Python / Go / Java) is loaded, your function code is mounted, and the handler executes. Subsequent invocations reuse the warm worker until AWS’s garbage collector reaps it (typically 5-15 minutes of idle).
Firecracker is the engineering marvel
Traditional VMs boot in 10-30 seconds: BIOS, kernel init, service startup. Containers start in 100-500ms but offer weaker isolation (shared kernel). Firecracker is purpose-built for one job: boot a minimal VM, with a tiny Linux kernel and just enough virtual devices to run a process, as fast as possible. It strips out everything that isn’t strictly needed (no BIOS, no PCI bus, no graphics, no USB, no filesystem layering beyond the minimum). The result: a fully-isolated VM in 125ms, with a memory footprint of ~5MiB. AWS runs tens of thousands of these per host, and a Lambda function’s cold-start cost is now competitive with container-based platforms.
The isolation guarantee matters: every Lambda function runs in its own kernel. A compromise of one function can’t escape to other functions on the same physical host, unlike container-based platforms, where a kernel exploit escapes to everything. AWS did not invent microVMs (Kata Containers, gVisor exist), but Firecracker is the only one purpose-built for serverless scale.
The warm worker pool is the latency layer
Cold starts aren’t free: 125ms for VM boot plus runtime init (Java’s JVM startup can add 1-3 seconds) plus your code’s initialization (loading libraries, opening DB connections). To minimize this, Lambda keeps recently-used workers warm: each invocation resets a 5-15 minute idle timer, and as long as the function gets traffic within that window, the worker stays alive and serves subsequent requests in milliseconds. The trick is that AWS runs enough traffic at planet scale that almost any function with non-trivial usage has warm workers most of the time. Cold starts are rare in practice for active functions; they’re a problem mainly for sparsely-used functions or sudden traffic spikes.
The one non-obvious insight
Lambda’s billing granularity (1 ms) is what made the whole architecture pay off. Pre-Lambda serverless (and most current competitors) billed per request or per 100ms; Lambda’s per-millisecond pricing forces them to track execution time precisely, but it also means customers see exactly the cost of their code’s actual runtime. A function that runs in 50ms costs half what a 100ms function costs. This creates a feedback loop: customers optimize their code for latency, AWS benefits from the optimization, and the platform’s cost model stays honest. The architecture is the moat; the billing model is the contract.
AWS Lambda is the canonical serverless platform: Firecracker microVMs for fast-cold-start isolation, warm worker pools to amortize the cold start across invocations, and per-millisecond billing that aligns AWS’s incentives with yours. The whole serverless industry converged on this pattern.
Continue learning: