Introduction: Firecracker & The MicroVM

It's Not Just a Script

Think of a traditional server like a restaurant kitchen that's always staffed and heated, ready to cook whether or not customers are present. AWS Lambda is more like a food truck that materializes in seconds exactly when someone orders, cooks the meal, and then vanishes — you only pay for the cooking time. The technology that makes this possible is called Firecracker.

When you invoke an AWS Lambda function, AWS doesn't run your code on a shared server alongside other customers' code. Instead, it boots a Firecracker MicroVM — a lightweight virtual machine that provides hardware-level isolation between tenants. Firecracker was open-sourced by AWS in 2018 and is purpose-built for serverless workloads. It strips away everything a traditional hypervisor (like KVM or Xen) provides that serverless doesn't need — no BIOS, no device emulation, no legacy hardware support — and boots in under 125 milliseconds while consuming less than 5 MB of memory overhead per VM. This is what allows AWS to run millions of Lambda functions simultaneously across its fleet without customers interfering with each other.

Each Firecracker MicroVM runs inside what Lambda calls an Execution Environment. This environment contains your function code, the language runtime (e.g., Python 3.12, Node.js 20, Java 21), and a small Linux kernel. The execution environment is the unit of isolation, scaling, and lifecycle management in Lambda. Understanding it is the foundation for understanding everything else in this lesson.

The Trade-offs That Define Lambda

Because Lambda creates and destroys these MicroVMs on demand, you face a unique set of challenges that don't exist with always-on servers:

• Lifecycle Management: You must understand when the VM is created, when it stays alive, and when it is destroyed — because your code behaves differently in each phase.
• Cold Starts: The time penalty for creating a new VM from scratch. This is the most discussed Lambda performance problem.
• Statelessness: Since the VM can vanish between requests, any local state (in-memory variables, open file handles) is temporary and unreliable across invocations.
• Concurrency as scaling: Lambda doesn't scale by adding CPU to one instance — it scales by adding more instances. 1,000 concurrent requests means 1,000 separate MicroVMs.