AWS Lambda MicroVMs: o serverless ganha um sandbox isolado e com estado

AWS Lambda MicroVMs são uma nova primitiva de computação serverless que entrega isolamento no nível de máquina virtual, inicialização quase instantânea a partir de um snapshot e execução com estado que você pode suspender e retomar. Roda sobre o Firecracker, a mesma virtualização leve que já dá suporte a mais de 15 trilhões de invocações de Lambda por mês. Em resumo: o Lambda acabou de ganhar a capacidade de entregar a cada sessão seu próprio sandbox dedicado, isolado e de longa duração, e de fazer isso sem que você gerencie qualquer virtualização por conta própria.

Se você já tentou rodar com segurança código que sua própria aplicação não escreveu, execução de código multi-tenant, notebooks interativos, scanners de vulnerabilidade, você já sabe por que isso importa. A resposta honesta até agora era "suba containers ou VMs e construa você mesmo a orquestração, o isolamento e o encanamento de ciclo de vida". As MicroVMs reduzem tudo isso a uma chamada de API.

O que realmente é novo

Funções Lambda comuns são sem estado, de vida curta e orientadas a eventos. São excelentes para isso. Também são a ferramenta errada quando você precisa de uma sessão que dura minutos ou horas, mantém estado em memória e isola código não confiável no nível do kernel. As MicroVMs são uma primitiva diferente dentro do mesmo serviço, mirando exatamente essa lacuna. A AWS apresenta isso como três capacidades que nenhum serviço de computação da AWS oferecia juntas antes de hoje.

1. Isolamento no nível de VM

Cada sessão roda em sua própria MicroVM dedicada, sem kernel compartilhado e sem recursos compartilhados entre usuários. Essa é a garantia do Firecracker: código não confiável de um tenant fica contido em seu próprio ambiente, sem caminho para outros ambientes ou para o host. Containers compartilham um kernel; uma MicroVM não. Para rodar código que você não escreveu, essa fronteira é todo o ponto.

2. Inicialização e retomada rápidas via snapshot

O modelo é image-then-launch. Você constrói uma MicroVM Image a partir de um Dockerfile mais um artefato de código no Amazon S3. O Lambda executa o Dockerfile, inicializa sua aplicação e tira um snapshot do Firecracker do estado de memória e disco em execução. Cada MicroVM lançada a partir dessa imagem retoma a partir do snapshot pré-inicializado em vez de fazer um cold boot. Mesmo uma sessão interativa de vários gigabytes volta rápido o suficiente para parecer ao vivo. É a ideia do SnapStart levada à sua conclusão lógica: você não está iniciando um processo, está restaurando um que já estava em execução.

3. Execução com estado e suspensível

Uma MicroVM em execução mantém sua memória, disco e processos ao longo da sessão. Quando fica ociosa, ela pode ser suspensa com o estado intacto e depois retomada quando o tráfego retorna. Pacotes instalados, dados carregados e arquivos de trabalho continuam todos lá. As MicroVMs suportam até 8 horas de tempo total de execução e fazem auto-suspend após uma janela de ociosidade configurável. Essa é a parte que quebra a velha premissa do serverless sem estado, e de um jeito bom.

Como é operar isso

Duas chamadas de CLI carregam a maior parte do fluxo de trabalho. Primeiro, construa a imagem:

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

Os logs de build vão para o CloudWatch em /aws/lambda/microvms/<image-name>, e a imagem finalizada aparece com seu próprio ARN e versão. Em seguida, lance uma MicroVM a partir dela:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

O Lambda retorna um ID único de MicroVM e uma URL de endpoint dedicada, com a aplicação já em execução porque ela retomou a partir do snapshot. Nenhuma rede para configurar. A idle-policy é onde mora o controle de ciclo de vida: por quanto tempo permanecer ociosa antes de suspender, por quanto tempo permanecer suspensa antes de encerrar e se deve fazer auto-resume na próxima requisição.

Onde se encaixa, e onde não

Recorra às MicroVMs quando	Fique no Lambda comum quando
Você roda código não confiável ou fornecido pelo usuário e precisa de isolamento no nível do kernel	Seu código é confiável e o trabalho é uma transformação curta e sem estado
Uma sessão precisa manter estado em memória por minutos ou horas	Cada invocação é independente e termina em segundos
Você quer ambientes dedicados por usuário sem rodar a frota você mesmo	Você não se importa em compartilhar um ambiente de execução gerenciado
Períodos de ociosidade são normais e você quer suspend-resume em vez de pagar para ficar ocioso	O tráfego é estável e request-response é toda a forma do problema

As MicroVMs não são um substituto para funções, e não são uma forma barata de rodar um servidor 24/7. O teto de 8 horas e o modelo suspend-resume foram feitos para sessões: um sandbox de código que um usuário abre e deixa de lado, um scan que roda por dez minutos, um job de analytics que processa por duas horas e depois fica quieto. Se sua carga de trabalho é um serviço de longa duração constantemente ocupado, isso ainda é território de ECS ou EC2.

A ressalva do snapshot que vale conhecer

Como toda MicroVM retoma a partir de um snapshot pré-inicializado, qualquer coisa que sua aplicação faça durante a inicialização assumindo frescor pode te surpreender. IDs únicos gerados na inicialização, conexões de rede abertas no boot, sementes aleatórias ou dados efêmeros carregados uma única vez podem ser congelados no snapshot e reutilizados entre lançamentos. É a mesma classe de pegadinha que usuários do SnapStart já conhecem: se algo precisa ser único ou novo por sessão, gere-o depois do resume, não durante o init. A AWS expõe hooks para isso, e você vai querer usá-los em qualquer coisa orientada a conexão ou sensível à segurança.

A conclusão

As Lambda MicroVMs são o sinal mais claro até agora de que o serverless deixou de ser apenas sem estado e de vida curta. Agora você tem um sandbox Firecracker gerenciado com isolamento de verdade, inicializações na velocidade de snapshot e estado com suspend-resume, exposto como duas chamadas de API e uma idle policy. Para qualquer um que esteja construindo execução de código multi-tenant, isso remove a parte mais difícil e menos diferenciada do trabalho: o encanamento de isolamento e ciclo de vida. Construa o produto e deixe o Lambda rodar a frota de MicroVMs.

Leia isto a seguir

AWS Monthly (Nov '25): The Stateful Serverless Revolution, para a linha de tendência sobre a qual as MicroVMs se apoiam.
Securing Docker Containers, sobre por que um kernel compartilhado é a fronteira que as MicroVMs foram feitas para remover.

Para o ângulo de IA e agentes sobre o mesmo lançamento, por que as MicroVMs foram feitas para rodar código gerado por IA, veja as anotações de campo em ercan.ai. Para consultoria em AWS, serverless e trabalho de plataforma, ou só para dizer um olá, comece em ercanermis.com.