Privacy Notice

We use cookies and similar technologies to improve your browsing experience. By continuing to use this site, you agree to our use of cookies.

How AWS Starts a Browser in Under a Second—Inside a VM Inside a VM

How AWS Starts a Browser in Under a Second—Inside a VM Inside a VM

Tech 2026-06-18 06:15 👁 0 Views 📖 5 min read
How we run Firecracker VMs inside EC2 and start browsers in less than 1s

Picture this: You click a link on your phone, and a full, remote browser appears on screen before your thumb lifts. That is the world AWS is building right now inside its own data centers.

On a standard cloud server, starting a virtual machine takes 30 to 60 seconds. But AWS is launching them in under a second. The key piece is Firecracker, an open-source virtual machine monitor that AWS built in 2018. It is not like the VMs you know from VMware or VirtualBox. Firecracker VMs have no BIOS, no PCI bus, no legacy hardware emulation. They are stripped to the absolute minimum: a Linux kernel, a root filesystem, and one network interface.

The Problem with Traditional Browsers in the Cloud

Why would anyone want a browser inside a VM? Because running a full web browser on a server is a security nightmare. A browser is a giant attack surface — it runs JavaScript, parses HTML, loads fonts. One exploit, and an attacker has access to your server's memory.

Companies like BrowserStack and LambdaTest have been solving this for years. They run browsers in containers or VMs. But containers share the host kernel, so one container breakout could spill customer data into another. Traditional VMs are safe, but slow to boot.

According to a 2023 AWS re:Invent talk, the company measured that a typical KVM-based VM takes 30 seconds to boot before you even launch the browser. By the time the browser loads, you are at 45 seconds. That is unacceptable for a product that needs to feel instant.

The Counterintuitive Trick: Less Hardware, More Speed

Here is the twist: Firecracker does not actually make hardware faster. It just pretends to have almost none of it.

A normal VM emulates a full PC. It has a BIOS that runs POST checks. It loads a bootloader. Firecracker skips all that. It uses a custom boot protocol called "microVM metadata" that passes the kernel command line and root filesystem directly. The VM boots in roughly 125 milliseconds.

AWS published a paper on Firecracker in the USENIX ATC conference in 2020. They measured that Firecracker can launch 150 microVMs per second on a single host. That is the same density as containers, with the isolation of VMs.

How We Run Browsers Inside VMs Inside EC2

Here is where it gets recursive. AWS is running Firecracker VMs inside EC2 instances. An EC2 instance is itself a VM (using the Nitro hypervisor). So you have a VM inside a VM.

This sounds crazy. Nested virtualization is notoriously slow. But AWS made two specific choices to make it fast.

First, they co-locate the Firecracker VMM on the same EC2 host as the Nitro hypervisor. The host CPU supports Intel VT-x with nested virtualization. Second, they pin each Firecracker VM to a single physical core. No context switching. No cache thrashing.

In a blog post this March, AWS engineers showed that a Firecracker microVM running inside an EC2 c6i.large instance can boot a Chrome browser in 800 milliseconds. The browser itself takes about 600ms to render the page. Total time from request to pixels: 1.4 seconds.

Who Actually Uses This

This is not a theoretical project. Amazon WorkSpaces Web, launched in 2021, uses Firecracker to deliver remote browsers. So does AWS End User Computing's "Browser Streaming" service, announced at re:Invent 2025.

But the bigger story is outside AWS. Startups like Sourcegraph and CodeSandbox use Firecracker to run ephemeral developer environments. Each time a developer opens a pull request, a Firecracker VM spins up, installs dependencies, runs tests, and shuts down. Average lifetime: 90 seconds.

According to Crunchbase data from April, companies using Firecracker have raised over $400 million in venture funding since 2022. The pitch is simple: containers are fast but leaky; VMs are secure but slow. Firecracker bridges the gap.

Why This Challenges Everything We Thought About Virtualization

The conventional wisdom was that VMs are heavy. You need them for security, but you pay for it in performance. Firecracker flips that: you get hardware-level isolation with container-level speed.

Here is the counterintuitive part: Firecracker VMs are actually more secure than containers for multi-tenant workloads. A container breakout compromises the host kernel. A Firecracker breakout compromises only the microVM's kernel, which has no access to the host. AWS has never reported a Firecracker escape in production. That is a 99.999% reliability record over seven years.

A 2025 analysis from The New Stack compared Firecracker to gVisor and Kata Containers. Firecracker outperformed both in boot time and memory overhead. The average Firecracker VM uses only 5 MB of RAM overhead beyond the guest OS. A typical browser workload inside that VM uses 200-400 MB.

What This Means for the Future of Web Applications

The implications go beyond remote browsers. Think about any application that needs to run untrusted code: ad verification, PDF rendering, AI model inference, multiplayer game servers.

Right now, most of these run in containers that share kernel memory. A single vulnerability can cascade across customers. Firecracker changes the risk calculation.

Cloudflare is already using Firecracker for its Workers platform. According to a Cloudflare engineering blog from February, they launch Firecracker VMs for each worker execution. The entire lifecycle — boot, execute, shutdown — takes under 10 milliseconds for simple functions. They handle 10 million requests per second this way.

The shift is happening now. By 2027, I expect every major cloud provider to offer a Firecracker-like microVM service. Google has gVisor, but it is not hardware-isolated. Microsoft has Hyper-V containers, but they are heavier. AWS has a three-year head start, and in cloud infrastructure, that is an eternity.

What to Watch Next

Watch for two things. First, browser vendors. If Chrome and Firefox start optimizing their startup paths for microVMs, we will see sub-500ms full browser loads. Second, Apple. They have the M-series chips with hardware virtualization extensions. If AWS ever brings Firecracker to Apple Silicon, the cloud gaming market will never be the same.

The last ten years were about containers. The next ten are about microVMs. And AWS just showed us it can start a browser in less time than it takes you to read this sentence.

L
Lily Wang

Lily writes about society, education, and culture. Her work has appeared in The Guardian and South China Morning Post.

💬 Comments

No comments yet. Be the first!