Firecracker: A tecnologia por trás do AWS Lambda que você pode rodar no seu Linux [pt.1]

Série Firecracker:

• Parte 01: Firecracker (você está aqui)
• Parte 02: Construindo um nano-Lambda
• Parte 03: Redes no Firecracker
• Parte 04: Snapshots
• Parte 05: Firecracker em produção

---

Você já parou pra pensar no que acontece quando você faz deploy de uma função Lambda? Tipo… de verdade?

Você escreve umas 20 linhas de código, faz upload, e de repente aquilo tá rodando em algum lugar. Isolado. Seguro. Escalando pra milhares de execuções simultâneas se precisar. E cada execução demora milissegundos pra iniciar.

Como isso é possível?

Durante anos eu assumi que era “mágica da AWS” e segui com a vida. Até que descobri o Firecracker — e aí as peças começaram a se encaixar.

O problema que ninguém fala

Vamos dar um passo atrás. Quando você precisa isolar código de diferentes usuários ou processos, você tem basicamente duas opções tradicionais:

Containers (Docker e amigos): Rápidos, leves, práticos. Você sobe um container em frações de segundo e ele usa pouquíssima memória. Mas tem um porém: containers compartilham o “cérebro” do sistema (o kernel) com a máquina principal. Todos eles. Se alguém encontra uma brecha pra escapar do container, pode afetar todo mundo rodando na mesma máquina.

Pra muitos casos isso é aceitável. Mas imagina a AWS rodando código de milhões de clientes diferentes. Código que ela não controla. Código que pode ser malicioso. Um escape de container ali seria… catastrófico.

VMs tradicionais (VMware, VirtualBox, QEMU): Isolamento real. Cada VM é como um computador separado dentro do seu computador — tem seu próprio sistema operacional, sua própria memória reservada, completamente separada das outras. Se uma VM for hackeada, as outras continuam seguras. Ótimo!

Mas VMs são pesadas. Levam segundos (às vezes dezenas de segundos) pra iniciar. Consomem centenas de megabytes de RAM só pra existir. Quando você precisa subir milhares delas em paralelo… a conta não fecha.

E aí entra o dilema: segurança ou velocidade?

Firecracker: a resposta da AWS

Em 2018, a AWS abriu o código de uma ferramenta que eles tinham desenvolvido internamente: o Firecracker. E ele resolve exatamente esse dilema.

Firecracker é o programa que cria e gerencia essas máquinas virtuais minúsculas. Diferente das ferramentas tradicionais de VM, ele foi construído com um objetivo muito específico: rodar microVMs.

O que é uma microVM? Pensa assim: é uma VM de verdade, com isolamento real (cada uma tem seu próprio sistema), mas tão enxuta que consegue iniciar em ~125 milissegundos (um piscar de olhos) e usar apenas ~5MB de memória extra.

Parece bom demais pra ser verdade, né? Tem um truque.

O segredo: remover tudo que não precisa

Firecracker não é mágica. Ele é minimalismo radical.

Uma VM tradicional tenta imitar um computador completo. Simula BIOS (aquela tela que aparece quando liga o PC), portas USB, placa de vídeo, leitor de CD… um monte de coisa que existe pra funcionar com sistemas antigos e todo tipo de hardware.

Firecracker simplesmente… não faz isso.

Sem placa de vídeo. Sem USB. Sem boot de CD. Sem aquela BIOS antiga. Sem suporte a Windows. Só o mínimo necessário pra rodar Linux com acesso a disco e rede.

O resultado? Um programa com ~50 mil linhas de código. Pra comparação, o QEMU (que faz VMs tradicionais) tem mais de 1 milhão.

Menos código = menos lugares onde pode ter bugs = mais segurança. E de quebra, muito mais velocidade.

Então Firecracker é uma VM ou não?

Essa pergunta aparece bastante, e a resposta é: sim, é uma VM de verdade.

Firecracker usa o KVM, que é a tecnologia de virtualização que já vem embutida no Linux. Cada microVM tem seu próprio sistema operacional rodando, sua própria memória separada, seus próprios programas. Em termos de segurança, você tem o mesmo isolamento de uma VM tradicional.

A diferença é que Firecracker é uma VM especializada. Ela não tenta fazer tudo — ela faz uma coisa só, e faz muito bem.

Pra deixar mais visual:

Aspecto	Container	VM Tradicional	MicroVM (Firecracker)
Isolamento	Compartilha o sistema	Sistema próprio	Sistema próprio
Tempo pra ligar	~0.1 segundo	~10-30 segundos	~0.1 segundo
Memória extra usada	~1-5MB	~200-500MB	~5MB
Roda Windows?	Depende do host	Sim	Não, só Linux

MicroVM fica ali no meio: isolamento de VM tradicional, velocidade próxima de container.

Mas por que não usar Docker?

Essa é a pergunta que mais aparece. A resposta curta: tipo de isolamento.

Docker/Containers: Isolamento via software. Usa namespaces e cgroups do Linux pra separar os processos, mas todos compartilham o mesmo kernel. É leve e rápido, mas se o kernel cair, tudo cai junto.

Firecracker: Isolamento via hardware. Usa KVM pra criar uma barreira real entre cada microVM. Cada uma tem seu próprio kernel rodando. Se uma microVM travar, as outras nem percebem.

Pensa assim: container é como um apartamento no mesmo prédio — as paredes te separam dos vizinhos, mas o encanamento e a fundação são os mesmos. Se o prédio cair, todo mundo cai junto. MicroVM é como casas separadas: cada uma tem sua própria fundação. Se uma pegar fogo, o vizinho nem sente o cheiro da fumaça.

Onde isso é usado na prática?

Firecracker é a tecnologia por trás do AWS Lambda e do AWS Fargate. Cada vez que sua função Lambda executa, ela roda dentro de uma microVM Firecracker. Cada task do Fargate também.

A AWS reporta que processa trilhões de execuções Lambda por mês. Trilhões. Tudo rodando em microVMs Firecracker.

Mas Firecracker é open source. Você pode baixar e rodar no seu Linux agora. E é isso que vamos fazer.

Preparando o ambiente

Antes de mais nada: Firecracker precisa de uma coisa chamada KVM. KVM é a tecnologia de virtualização que já vem no Linux — é ele que realmente faz a “mágica” de criar máquinas virtuais. Firecracker é só o programa que usa o KVM pra criar as microVMs.

Isso significa que você precisa de:

1. Linux (óbvio)
2. Acesso ao /dev/kvm (um arquivo especial que dá acesso ao KVM)

Se você já usa Linux como sistema principal

Ótimo! Provavelmente já tem tudo que precisa. Vamos verificar:

# Verifica se KVM está disponível
ls -la /dev/kvm

Se aparecer algo como crw-rw---- 1 root kvm ..., você tá pronto. Se der erro de “arquivo não encontrado”, pode ser que:

• Virtualização não está habilitada na BIOS do seu computador (reinicia, entra na BIOS, e procura por “VT-x”, “AMD-V”, “Virtualization Technology” ou algo parecido)
• O Linux não carregou os módulos do KVM automaticamente

Pra carregar os módulos manualmente:

sudo modprobe kvm
sudo modprobe kvm_intel  # ou kvm_amd se seu processador for AMD

E pra verificar se carregou:

lsmod | grep kvm

Se você usa Mac ou Windows

Você vai precisar criar uma VM Linux com nested virtualization (virtualização aninhada) habilitada. Parece complicado, mas é só uma opção que permite uma VM rodar outra VM dentro dela — tipo inception de VMs.

A forma mais simples:

1. Mac com Apple Silicon: Use UTM ou Parallels. Crie uma VM Ubuntu/Debian/Fedora com virtualização nested habilitada.

2. Mac Intel ou Windows: VirtualBox ou VMware. Na configuração da VM, habilite “Nested VT-x/AMD-V” ou similar.

3. Windows com WSL2: Infelizmente não funciona. WSL2 não expõe /dev/kvm.

Depois de criar a VM Linux, siga os passos da seção anterior pra verificar se KVM tá funcionando.

Verificação final

Criei um script pra verificar se tá tudo certo. Versão resumida:

#!/bin/bash
# Verificação rápida do ambiente para Firecracker

[ ! -e /dev/kvm ] && echo "[ERRO] /dev/kvm não encontrado!" && exit 1
echo "[OK] /dev/kvm encontrado"

[ ! -r /dev/kvm ] || [ ! -w /dev/kvm ] && echo "[AVISO] Sem permissão em /dev/kvm. Execute: sudo usermod -aG kvm \${USER}"

lsmod | grep -q "kvm_intel\|kvm_amd" && echo "[OK] Módulos KVM carregados" || echo "[AVISO] Módulos KVM não encontrados"

echo "Verificação concluída"

No repositório do artigo tem uma versão mais completa do script (check-kvm.sh) que detecta sua distribuição e dá instruções específicas pra Fedora, Ubuntu, Debian, etc.

Baixando o Firecracker

Agora sim, vamos baixar o Firecracker. A AWS disponibiliza binários pré-compilados no GitHub:

mkdir -p ~/firecracker-lab && cd ~/firecracker-lab

# Baixa a release mais recente (ajuste a versão se necessário)
FIRECRACKER_VERSION="v1.13.0"
ARCH=$(uname -m)  # x86_64 ou aarch64

curl -L -o firecracker.tgz \
  "https://github.com/firecracker-microvm/firecracker/releases/download/${FIRECRACKER_VERSION}/firecracker-${FIRECRACKER_VERSION}-${ARCH}.tgz"

tar -xzf firecracker.tgz

mv release-${FIRECRACKER_VERSION}-${ARCH}/firecracker-${FIRECRACKER_VERSION}-${ARCH} firecracker
chmod +x firecracker

./firecracker --version

Se aparecer a versão, sucesso!

Kernel e rootfs: os ingredientes da microVM

Uma microVM precisa de duas coisas pra funcionar:

1. Kernel: O “cérebro” do Linux que vai rodar dentro da VM
2. Rootfs: O “disco” da VM — todos os arquivos do sistema (programas, configurações, etc.)

Pra esse Hello World, vamos usar kernel e rootfs prontos. Hospedei eles no repositório do artigo pra garantir que os links não quebrem:

# Baixa o kernel
curl -L -o vmlinux.bin \
  "https://github.com/dklima/firecracker-na-pratica/releases/download/v1.0.0/vmlinux-5.10.239"

# Baixa o rootfs (Ubuntu 24.04 mínimo)
curl -L -o rootfs.ext4 \
  "https://github.com/dklima/firecracker-na-pratica/releases/download/v1.0.0/rootfs.ext4"

Pronto. Você tem tudo que precisa.

Hello World: sua primeira microVM

Firecracker é controlado por comandos que você envia pra ele. Em vez de ter uma interface gráfica ou linha de comando tradicional, ele escuta comandos através de um “socket” — pensa nisso como um canal de comunicação entre programas.

Parece estranho no começo, mas faz sentido: você pode controlar o Firecracker de qualquer linguagem de programação. Nesse tutorial, vamos usar o curl pra enviar os comandos.

Vamos fazer passo a passo.

Passo 1: Inicia o Firecracker

Abre um terminal e roda:

# Remove socket antigo se existir
rm -f /tmp/firecracker.socket

# Inicia o Firecracker (vai ficar esperando comandos)
sudo ./firecracker --api-sock /tmp/firecracker.socket

Nota: Usamos sudo pra simplificar o tutorial. Em produção, você adicionaria seu usuário ao grupo kvm e rodaria sem root — mais seguro.

O terminal vai “travar”. Isso é normal — o Firecracker tá esperando ordens.

Passo 2: Configura a microVM

Abre outro terminal (mantendo o primeiro rodando) e envia as configurações:

cd ~/firecracker-lab

# Configura o kernel
curl --unix-socket /tmp/firecracker.socket -X PUT \
  "http://localhost/boot-source" \
  -H "Content-Type: application/json" \
  -d '{
    "kernel_image_path": "./vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  }'
# pci=off desliga o barramento PCI — não vamos plugar nada mesmo,
# e isso economiza alguns milissegundos no boot. Minimalismo em ação.

# Configura o rootfs
curl --unix-socket /tmp/firecracker.socket -X PUT \
  "http://localhost/drives/rootfs" \
  -H "Content-Type: application/json" \
  -d '{
    "drive_id": "rootfs",
    "path_on_host": "./rootfs.ext4",
    "is_root_device": true,
    "is_read_only": false
  }'

# Configura recursos (1 vCPU, 128MB RAM - mínimo possível)
curl --unix-socket /tmp/firecracker.socket -X PUT \
  "http://localhost/machine-config" \
  -H "Content-Type: application/json" \
  -d '{
    "vcpu_count": 1,
    "mem_size_mib": 128
  }'

Passo 3: Ligar a máquina!

curl --unix-socket /tmp/firecracker.socket -X PUT \
  "http://localhost/actions" \
  -H "Content-Type: application/json" \
  -d '{"action_type": "InstanceStart"}'

Agora volta pro primeiro terminal (onde você iniciou o Firecracker).

Se tudo deu certo, você vai ver o kernel Linux iniciando… e em poucos segundos, um prompt de login!

Welcome to Ubuntu 24.04.2 LTS
Kernel 5.10.239 on an x86_64

ubuntu-fc-uvm login:

Login padrão: root (sem senha).

Parabéns! Você tá dentro de uma microVM Firecracker.

Explorando lá dentro

Agora você pode brincar um pouco:

# Veja que é um sistema mínimo
cat /etc/os-release

# Quanta memória tem?
free -m

# Que processos tão rodando?
ps aux

# Veja as interfaces de rede (só loopback por enquanto)
ip addr

Repare como tudo é mínimo. Esse rootfs Ubuntu tem ~400MB de conteúdo, mas é bem enxuto comparado a uma instalação completa.

Desligando

Pra desligar a microVM de forma limpa:

reboot

Como configuramos reboot=k panic=1 no boot, o reboot na verdade vai parar a VM. O processo do Firecracker no outro terminal vai encerrar.

O que você acabou de fazer

Vamos recapitular:

1. Você baixou o Firecracker — um programa enxuto de ~50 mil linhas de código
2. Baixou um kernel Linux e um rootfs mínimo
3. Iniciou uma microVM com 1 vCPU e 128MB de RAM
4. Entrou na VM pelo terminal e explorou o sistema

Tudo isso com isolamento real de VM. Se você rodar dmesg dentro da microVM, vai ver um boot completo de Linux — igualzinho a ligar um computador de verdade. Não é um container fingindo ser isolado — é uma VM de verdade.

A diferença é que iniciou em milissegundos, não minutos.

E agora?

Isso foi só o Hello World. No próximo artigo, a gente sobe o nível: vamos criar nosso próprio nano-Lambda.

Vamos:

• Customizar o rootfs pra incluir Python
• Escrever um script Python que controla o Firecracker
• Criar uma função que gera QR Codes
• Executar essa função dentro de uma microVM isolada

Basicamente, vamos construir uma versão simplificada do que o AWS Lambda faz por baixo dos panos.

Até lá!

---

Este artigo faz parte da série “Firecracker: MicroVMs na Prática”. Todo o código está disponível em GitHub.