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

Atualizado em 08/06/2026

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 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 não faz nada disso.

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. 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 ... (Debian, Ubuntu) ou crw-rw-rw- 1 root kvm ... (Fedora), você tá pronto. O que importa é o dono ser root e o grupo ser kvm. 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

Saída esperada (num processador Intel):

kvm_intel             565248  0
kvm                  1552384  1 kvm_intel
irqbypass              16384  1 kvm

Se seu processador for AMD, no lugar de kvm_intel vai aparecer kvm_amd.

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} (depois faça logout e login)"

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"

Num ambiente saudável, a saída fica assim:

[OK] /dev/kvm encontrado
[OK] Módulos KVM carregados
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.16.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

O tar extrai tudo pra uma pasta chamada release-v1.16.0-x86_64/. O mv pega só o binário do Firecracker lá de dentro e traz pra cá já com o nome firecracker. No fim, o --version mostra:

Firecracker v1.16.0

Se aparecer a versão, sucesso! Essa é a primeira confirmação de que o download veio inteiro.

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, com 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-6.1.155"

# 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"

Confere se os dois vieram inteiros antes de seguir:

ls -lh vmlinux.bin rootfs.ext4

Saída esperada:

-rw-r--r-- 1 voce voce  43M ... vmlinux.bin
-rw-r--r-- 1 voce voce 512M ... rootfs.ext4

Se algum aparecer com poucos KB, o download falhou (o curl -L pode ter baixado uma página de erro do GitHub no lugar do arquivo). Apaga e baixa de novo.

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 (precisa de sudo: o socket pertence ao root)
sudo rm -f /tmp/firecracker.socket

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

Nota: Como o Firecracker roda com sudo, o socket que ele cria em /tmp/firecracker.socket pertence ao root. Por isso os comandos curl dos próximos passos também vão com sudo, senão eles não conseguem se conectar no socket. Em produção, você adicionaria seu usuário ao grupo kvm e rodaria tudo sem root, que é 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
sudo 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
sudo 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)
sudo 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
  }'

Cada um desses comandos não responde nada quando dá certo. A API devolve HTTP 204 No Content, sem corpo, então silêncio aqui é sinal de sucesso. Se aparecer um JSON com fault_message, alguma coisa deu errado, geralmente o caminho do vmlinux.bin ou do rootfs.ext4. Pra ver o código HTTP de cada chamada, adiciona -w '%{http_code}\n' no curl: em sucesso ele imprime 204.

Passo 3: Ligar a máquina!

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

Esse também retorna HTTP 204 em silêncio quando dá certo. Se vier um JSON com fault_message (tipo um erro ao criar o objeto KVM), é sinal de que o /dev/kvm não tá acessível, volta na seção “Preparando o ambiente”.

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 (na nossa validação foram cerca de 3 segundos), a microVM faz login automático como root e te joga direto num shell:

ubuntu-fc-uvm login: root (automatic login)

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.1.155+ x86_64)

root@ubuntu-fc-uvm:~#

Repara que ele nem pediu senha. Esse rootfs já vem configurado pra logar como root automaticamente no console serial, então você cai direto no prompt de comando.

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

Explorando lá dentro

Agora você pode brincar um pouco. Começa vendo qual sistema é esse:

cat /etc/os-release

Saída:

PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION="24.04.2 LTS (Noble Numbat)"
ID=ubuntu
ID_LIKE=debian

Quanta memória a microVM enxerga:

free -m

Saída:

               total        used        free      shared  buff/cache   available
Mem:             104          32          46           1          32          72
Swap:              0           0           0

Repara que o total é 104 MB, não os 128 MB que pedimos no machine-config. A diferença é o próprio kernel, que reserva uma parte da RAM antes de entregar o resto pro sistema. É esperado, e os números das outras colunas variam um pouco a cada boot.

Quantas CPUs ela tem:

nproc

Saída:

1

Bate com o vcpu_count: 1 que configuramos. E as interfaces de rede:

ip addr

Saída:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

Só o loopback por enquanto. A microVM ainda não tem rede de verdade, e é exatamente isso que vamos montar na Parte 03. Se rodar um ps aux, vai ver que o sistema inteiro são umas 70 entradas, e quase todas são threads do kernel (aquelas entre colchetes). De processo de verdade são só uns poucos: o init, o systemd-journald, o systemd-udevd, os getty dos consoles e o seu shell.

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

Desligando

Pra desligar a microVM de forma limpa, rode lá de dentro dela:

reboot

Você vai ver uma linha Failed to connect to bus: No such file or directory e logo em seguida o systemd desligando os serviços. Pode ignorar esse aviso: ele aparece porque esse sistema mínimo não roda o D-Bus, mas o desligamento acontece do mesmo jeito.

O Firecracker não reinicia a microVM de verdade. Quando o sistema lá dentro pede pra reiniciar, ele trata isso como desligamento e encerra o processo. Olha o terminal onde o Firecracker tava rodando, ele vai terminar sozinho com algo assim:

reboot: Restarting system
Firecracker exiting successfully. exit_code=0

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 a microVM em si sobe em milissegundos. O boot completo do Linux por cima leva poucos segundos, 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

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.