CONCEPT Cited by 2 sources

Micro-VM Isolation

Micro-VM isolation is the practice of running each tenant's code inside a minimal hardware-virtualised VM (fast boot, small memory overhead), trading the density of containers for the isolation guarantees of full VMs.

Why multi-tenant FaaS needs it

The 2014 Lambda PR/FAQ made "no two customers share an instance" a non-negotiable launch tenet — enforced at launch by giving every customer their own EC2 instances. That was expensive, and the team knew it: "we knew that long-term that it was a problem we could solve, and we trusted our developers to deliver. These days, we can securely pack thousands of micro VMs onto a single bare metal instance."

(Source: sources/2024-11-15-allthingsdistributed-aws-lambda-prfaq-after-10-years)

This is the canonical "isolation vs density" trade in serverless infrastructure, and the move from single-tenant EC2 → Firecracker micro-VMs is the archetypal resolution: keep the VM-level isolation boundary, shrink the VM.

Properties

• Hardware-virtualisation boundary — stronger than a container; a compromised guest cannot trivially escape to the host.
• Small footprint / fast boot — Firecracker boots in ms and runs in tens of MB, so many VMs can co-exist on a bare-metal host without crippling per-tenant overhead.
• Composable with snapshotting — lets the provider checkpoint an initialised runtime and restore it on demand (Lambda SnapStart), which attacks concepts/cold-start latency directly.

Related use cases

Firecracker was designed for Lambda and Fargate but has since been adopted by Fly.io, Kata Containers, and others as the default "secure multi-tenant function" primitive.

Seen in

• sources/2024-11-15-allthingsdistributed-aws-lambda-prfaq-after-10-years — framed as Lambda's answer to the day-one "single-tenant EC2 is expensive" trade.
• sources/2026-04-21-figma-server-side-sandboxing-virtual-machines — the customer-side view of the same primitive: Figma uses AWS Lambda (→ Firecracker) as its VM-grade sandbox for risky stateless workloads (ImageMagick / link-preview fetching). The post makes explicit the two-question security frame every VM-sandbox choice must answer — (1) can a compromise escape the boundary (concepts/vm-escape)? (2) if not, what can a non-escaping compromise do with the VM's own capabilities (patterns/minimize-vm-permissions)? — and notes that hypervisor-boundary reliance is unavoidable on multi-tenant IaaS unless you stick to bare-metal instances. Also documents Firecracker's boot-time cost as the reason AWS reuses Lambda VMs across requests from the same tenant on synchronous paths — a concrete density-vs-boundary trade-off visible even to Lambda customers.