AWS Lambda MicroVMs: rode código não confiável com isolamento de VM (sem gerenciar infra)

🇺🇸 Leia em inglês.

Deixa eu te colocar numa situação. Você precisa rodar um código que não foi você que escreveu. Pode ser o script que o seu usuário colou na plataforma, pode ser o trecho que um agente de IA gerou na hora e quer executar. E aí bate a pergunta que tira o sono de quem trabalha com multi-tenant: como eu rodo isso sem entregar a chave da casa para um estranho?

Até semana passada você tinha três caminhos, e todos com um porém. VM dá isolamento forte, mas leva minutos para subir. Container sobe em segundos, mas compartilha kernel, então rodar código não confiável ali exige um trabalhão de hardening. E a Lambda Function foi feita para request-response de vida curta, não para uma sessão que precisa guardar estado vivo entre uma interação e outra (externalizar num DynamoDB resolve o dado, não o runtime em memória, o processo rodando, os pacotes carregados). No fim, você escolhia entre performance e isolamento. Não tem para onde fugir, ou tinha.

Container, VM ou Lambda: o trade-off que nenhum resolvia sozinho

Esse padrão virou comum: assistente de código com IA, ambiente de código interativo, analytics, scanner de vulnerabilidade, game server com script do jogador. Todos precisam da mesma coisa: dar a cada usuário um ambiente próprio para executar código que o time não escreveu, com segurança e sem lentidão.

O nó é que isolamento de verdade e baixa latência puxavam para lados opostos. Pela ótica de segurança, você quer uma fronteira dura entre os tenants (o pilar de Security do Well-Architected: isolar o que não é confiável). Pela ótica de experiência, você quer o ambiente de pé na hora. Conciliar os dois era o trabalho caro.

E tem uma ironia boa nessa história. A gente passou anos aprendendo a construir aplicação stateless, e agora o estado voltou a ser requisito. Outro dia, numa conversa com uns amigos, alguém soltou uma frase que não saiu mais da minha cabeça:

A solução do futuro estava no passado.

Já se sentiu assim? Pois é, eu também. É mais ou menos isso que o Lambda MicroVMs faz: traz o estado de volta, sem te devolver o peso da VM.

O que é o Lambda MicroVMs

O Lambda MicroVMs é um primitivo novo dentro do Lambda, feito exatamente para esse buraco. Cada MicroVM dá a um único usuário ou sessão um ambiente isolado, que sobe rápido, retém memória e disco pela sessão inteira, e pausa para um custo baixo quando o usuário some.

A mágica vem do Firecracker, a mesma virtualização leve que já roda mais de 15 trilhões de invocações de Lambda por mês. Não é tecnologia crua, é a fundação madura do próprio Lambda exposta de um jeito novo.

O modelo é image-then-launch:

Você cria a imagem uma vez (a AWS roda o seu Dockerfile, inicializa a app e tira um snapshot da memória e do disco). Depois, toda MicroVM que você lança parte desse snapshot, em vez de bootar do zero. Por isso o launch e o resume são quase instantâneos, mesmo numa sessão de vários gigabytes.

Para que serve (com exemplos que você reconhece)

A deixa principal: isso só entra em cena se você está construindo uma plataforma que roda código de terceiros. Se o seu app não executa código de fora, você não precisa disso. É um tijolo para quem constrói esse tipo de produto:

• Replit, CodeSandbox, "VS Code no browser": o usuário digita código no navegador e ele roda isolado, por usuário, segurando estado enquanto a aba está aberta. Esse "roda isolado" é a MicroVM.

• Code interpreter (tipo o do ChatGPT ou do Claude): você pede "faz um gráfico desse CSV", a IA escreve um Python e roda para te responder. O runtime que executa esse código gerado, isolado por conversa, é o caso.

• Runner de CI/CD (e parentes): um job roda o código de um Pull Request que pode vir do fork de qualquer estranho, código não confiável por definição, então você quer um runner isolado e descartável por job. Na mesma família: scanner que executa um binário suspeito, plataforma de entrevista de código (o código do candidato roda isolado) e agente de IA que roda comandos de shell.

O fio que une tudo: cada usuário, sessão ou job precisa do próprio ambiente isolado, e o código que roda ali não foi você que escreveu. É essa a deixa para usar MicroVM em vez de Lambda Function.

Lambda Function ou Lambda MicroVM?

Os dois não competem, eles se completam. A comparação oficial:

	Lambda Function	Lambda MicroVM
Melhor para	request-response ou event-driven (APIs, processamento, automação)	ambiente persistente rodando código não confiável de usuário ou de IA
Modelo de programação	function handler num runtime suportado	qualquer aplicação: seus binários, escutando em portas, com capabilities do Linux
Duração	até 15 min por invocação; workflow multi-step de até um ano com Lambda Durable Functions	até 8 horas por sessão; suspend e resume entre sessões
Runtime	runtimes do serviço (ou customizado)	imagem de MicroVM provida por você
Rede de entrada	invocação direta ou event source; response streaming	qualquer porta, protocolos OSI camada 7
Concorrência	uma request por ambiente por vez	múltiplas conexões simultâneas por MicroVM
Estado do ambiente	warm start pode reusar o ambiente, mas o estado não persiste	memória e disco preservados no suspend, restaurados no resume
Escala	automática: o Lambda cria e destrói ambientes conforme o tráfego	você controla: cria, suspende, resume e termina via API
Ciclo de vida	totalmente gerenciado pelo Lambda	você controla, com idle policies opcionais
Preço	por request + GB-segundos	por segundo de compute rodando + storage do snapshot enquanto suspensa

A confusão mais comum: muita gente assume que o tempo é igual ao do Lambda. O startup até é parecido (os dois resumem de snapshot), mas a Function morre em 15 minutos e a MicroVM segura uma sessão por até 8 horas com o estado intacto. O desenho real: a sua app continua com Lambda Functions no backbone event-driven, e chama o MicroVMs só nos passos que precisam rodar código não confiável isolado.

Como funciona na prática: do endpoint à orquestração

Três coisas que confundem no começo, juntas.

O endpoint tem status. Quando você chama run-microvm, vem um ID e um endpoint HTTPS dedicado daquela MicroVM. Mas ela não nasce pronta: passa por status, do launch até RUNNING (uns 2 segundos), e no ocioso vai para suspensa, voltando no resume. O endpoint é por MicroVM, por sessão.

Uma imagem, muitas MicroVMs. Você builda a imagem uma vez (create-microvm-image) e cada MicroVM é um run-microvm. Quer duas? Chama duas vezes, e vêm duas instâncias independentes. O ocioso é governado pela idle-policy: maxIdleDurationSeconds (suspende após X ocioso) e autoResumeEnabled (a próxima request acorda a MicroVM sozinha em ~1s, sem você ligar na mão). No fim, terminate-microvm libera tudo.

Você vira o orquestrador. Como o endpoint é por sessão, alguém precisa decidir quando lançar e para quem rotear. Tipicamente uma Lambda Function no backbone faz isso: mantém um mapa sessão → MicroVM (em produção um store, tipo DynamoDB), lança com run-microvm no primeiro acesso do usuário, gera um token com CreateMicrovmAuthToken e faz proxy da request para o endpoint da MicroVM. Se ela estiver suspensa e o autoResume estiver ligado, a própria request acorda ela. Some a isso uma rotina para terminar MicroVMs órfãs e você tem o esqueleto. O código desse backbone fica no próximo post da série. E não confunda com Step Functions: MicroVM é o ambiente de execução, Step Functions é orquestrador, são camadas diferentes.

Custo, limites e o que ainda falta

Custo é decisão, não detalhe. O Werner Vogels martela no Frugal Architect que custo é requisito de arquitetura, não número que você descobre na fatura. O suspend é isso na prática: você paga caro pelo isolamento de VM, mas só enquanto o usuário está ativo. Quando ele some, a MicroVM suspende e o custo cai, sem perder o estado. Desenhar a idle-policy com intenção é uma decisão de custo. O modelo, pela tabela oficial: você paga por segundo de compute enquanto a MicroVM roda, e só o storage do snapshot enquanto ela está suspensa. Os valores unitários estão na página de pricing do Lambda.

Limites: ARM64, até 16 vCPUs, 32 GB de memória e 32 GB de disco por MicroVM, e até 8 horas de runtime total. Provisionamento flexível: você define um baseline e escala até 4x no pico, pagando o baseline enquanto roda.

IaC: dá para usar console, CloudFormation e CDK.

Por que Dockerfile + zip, e não uma imagem ECR pronta? O Aidan Steele cavou: a Lambda builda duas cópias, uma para Graviton 3 e outra para Graviton 4, então precisa do fonte para recompilar. A base sai do ECR Public, mas empurrar a sua imagem pronta de um ECR privado como artefato não é o caminho. Um detalhe que confunde: ECR não some, dentro da MicroVM você roda Docker e dá docker pull do seu ECR em runtime. ECR é para consumo dentro, não para entregar a imagem.

Rede e região: tráfego de entrada em portas configuráveis (HTTP/2, gRPC, WebSockets), auth JWE do serviço, saída para internet ou VPC. E o aviso BR: por enquanto só em US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) e Asia Pacific (Tokyo). Sem sa-east-1 ainda.

Quando NÃO usar

Se o workload é request-response curtinho e sem estado, continua sendo Lambda Function. MicroVM ali é matar mosquito com canhão. E se você só precisa de mais de 15 minutos com o seu próprio código (confiável), MicroVM também é overkill: para job longo, olhe Fargate; para workflow multi-step, Lambda Durable Functions (até um ano, como a tabela mostra). MicroVM é para quando o diferencial é o isolamento de código não confiável, não só passar dos 15 minutos.

E tem uma pegadinha que a própria AWS avisa, e que lembra muito o papo de determinismo: como a MicroVM sobe de um snapshot pré-inicializado (o equivalente ao SnapStart da Lambda, como o Aidan Steele confirmou testando), aplicações que geram conteúdo único, abrem conexões ou carregam dados efêmeros na inicialização podem divergir. O snapshot congelou um momento; o que precisa ser fresco a cada sessão não pode estar congelado junto. O conserto tem nome: lifecycle hooks para reinicializar a aleatoriedade na criação de cada MicroVM. Mapeie isso antes de assumir que vai funcionar de primeira.

Mata o container? Não, e o motivo é até melhor.

O hype de plantão é "containers ficaram obsoletos". Não ficaram. Pelo contrário: o Aidan Steele testou e você roda Docker dentro de uma MicroVM, com as capabilities de OS liberadas. Ou seja, o MicroVM não mata o container, ele é mais isolado e ainda roda container por dentro. O recorte honesto é outro: tem um lugar específico, rodar código não confiável isolado, onde você não vai mais querer endurecer container na mão. Ali o MicroVM ganha. No resto, container segue rei.

Os detalhes que a doc deixou de fora

O Aidan Steele passou o dia do lançamento cutucando o serviço e achou coisas bem interessantes que não estão na doc oficial.
Eu li e achei importante trazer para cá:

• Você consegue um shell na MicroVM, via API CreateMicrovmShellAuthToken, com pty como cidadão de primeira classe (a Lambda Function não tem). Ouro para IDE e coding agent.

• UDP de saída é bloqueado por padrão e o DNS é um stub local, então DNS dentro de container cai no 8.8.8.8 e falha. O fix é rodar com o DNS da Lambda: docker run --dns 169.254.169.253, ou ir de VPC.

• Lambda network connectors: config de VPC reificada (subnets, security groups, IAM role para ENI) com ciclo de vida próprio. O time de rede cria, o dev só consome.

• Performance (testes dele): build da imagem 2-3 min; RunMicrovm até RUNNING ~2s, mais ~2s para servir; suspend e resume ~1s cada.

O que você leva

• O Lambda MicroVMs preenche um buraco real: isolamento de VM com launch quase instantâneo e estado por sessão, que nenhum serviço entregava junto.

• Não substitui a Lambda Function, complementa. Function no backbone, MicroVM para o código não confiável.

• O suspend ocioso é uma alavanca de custo consciente, desenhe a idle-policy de propósito.

• Antes de cravar arquitetura: confira região (sem sa-east-1 ainda), os limites (ARM64, 16 vCPU, 32 GB, 8h) e o caveat do snapshot.

Esse post foi o mapa. No próximo da série eu subo o MicroVMs de verdade e a gente prova o isolamento na prática, lançando duas MicroVMs e testando se uma alcança a outra, com o repo no GitHub para você rodar junto.

Comenta aí: você tem um caso de rodar código de usuário ou de IA que hoje gambiarra em container ou em VM na mão?
Manda aquele joinha, compartilha com quem está montando plataforma multi-tenant, e bora trocar ideia. Valeu demais! =D

Publicado originalmente em willpeixoto.dev.