As AWS Lambda MicroVMs são um novo primitivo serverless construído, segundo o próprio enquadramento da AWS, para rodar código gerado por usuários ou por IA em ambientes isolados e com estado. Essa segunda palavra é a que merece atenção. O lançamento não é realmente sobre funções. É sobre dar a um agent de IA um lugar seguro para executar o código que ele acabou de escrever, e o fato de a AWS ter começado por "usuários ou IA" diz a quem isso se destina.

Se você constrói agents, já bateu nessa parede. O modelo escreve código, e então você precisa rodá-lo em algum lugar. Rodar código não confiável gerado por modelo na sua própria infraestrutura é a parte que todo mundo subestima, e é exatamente a parte que as MicroVMs foram projetadas para tirar do seu colo.

O problema de sandbox que os agents realmente têm

Um agent capaz não apenas responde. Ele escreve um script, executa, lê o resultado e itera. Code interpreters, agents de análise de dados e ferramentas autônomas de programação dependem todos de uma única pergunta: onde esse código roda?

As respostas ingênuas são todas ruins. Rode no processo da sua aplicação e uma única geração hostil ou com bug pode derrubar o host ou ler os dados de outro usuário. Rode em um container compartilhado e você está a um exploit de kernel de distância de uma violação entre tenants, porque containers compartilham um kernel. Construa sua própria frota de VMs e você acabou de se comprometer a operar a infraestrutura mais difícil e menos diferenciada da sua stack. Código gerado por modelo é, por definição, código não confiável. Ele precisa de uma fronteira de isolamento de verdade, não de uma fronteira educada.

Por que MicroVMs encaixam no formato agentic

As Lambda MicroVMs se alinham com a forma como os agents realmente se comportam, em três eixos.

Isolamento que aguenta contra saída hostil

Cada sessão roda em sua própria Firecracker MicroVM: sem kernel compartilhado, sem recursos compartilhados, sem caminho de um ambiente para outro ou para o host. Quando o seu agent roda código que um modelo de linguagem produziu a partir do prompt de um usuário, essa é a fronteira que você quer entre "o agent fez algo estranho" e "o agent comprometeu a plataforma". Um agent vítima de prompt injection que decide exfiltrar ou destruir fica contido em uma VM descartável.

Estado que combina com uma tarefa de múltiplos passos

O trabalho de um agent raramente é de uma só tacada. Ele instala um pacote, carrega um dataset, escreve arquivos intermediários e volta a eles três passos depois. Uma MicroVM mantém memória, disco e processos em execução ao longo da sessão, e pode suspender com esse estado intacto durante as longas pausas enquanto o modelo pensa ou o usuário se ausenta, e então retomar quase instantaneamente. Modelos carregados e conjuntos de arquivos em uso simplesmente continuam lá. Isso encaixa muito melhor do que reinicializar um container novo a cada chamada de tool.

Inicialização rápida o suficiente para parecer interativa

Como toda MicroVM retoma a partir de um snapshot pré-inicializado do Firecracker em vez de fazer cold boot, mesmo uma sessão de vários gigabytes volta rapidamente. Para um agent interativo, em que um humano está olhando o cursor piscar, a diferença entre retomar de um snapshot e iniciar um container do zero é a diferença entre usável e abandonado. As sessões podem rodar por até 8 horas, o que cobre confortavelmente uma análise longa ou uma sessão de programação demorada.

A AWS está construindo todo o loop do agent, não apenas o runtime

O lançamento das MicroVMs não chegou sozinho. A AWS também lançou um guia de configuração de agents que conecta agents de programação, Claude Code, Codex, Cursor, Kiro, Copilot, Windsurf, OpenCode, ao desenvolvimento serverless por meio de plugins, agent skills e um MCP Server. Leia os dois juntos e a estratégia fica clara: os agents ajudam você a construir a aplicação serverless, e as MicroVMs são onde o código que esses agents geram pode rodar com segurança. A AWS está tentando dominar as duas pontas do loop, o agent que escreve e o sandbox que executa.

O que isso não resolve

Isolamento é uma fronteira, não um cérebro. Uma MicroVM impede que código gerado por modelo escape do seu sandbox. Ela não faz nada para impedir o agent de fazer algo burro, porém permitido, dentro da caixa, nem de receber credenciais que deixam o raio de impacto se estender para além dela. Se você montar segredos reais ou entregar ao sandbox um IAM role amplo, a fronteira da VM é irrelevante para o estrago que um prompt injetado pode causar por meio de chamadas de API legítimas. Limite o que o sandbox consegue alcançar com o mesmo rigor com que você o isola. O runtime é a metade fácil; least-privilege para o agent ainda é responsabilidade sua.

A conclusão

Durante a maior parte do boom agentic, a pergunta do runtime, onde o código gerado de fato executa, foi respondida com fita adesiva: um container aqui, um processo travado ali, um pool de VMs caseiro para os times que podiam pagar por isso. As Lambda MicroVMs transformam isso em um primitivo gerenciado com isolamento no nível da VM, sessões com estado e retomada na velocidade de snapshot, exposto como uma chamada de API. Isso não torna o seu agent mais inteligente nem mais seguro naquilo que ele decide fazer. Mas dá ao código que ele escreve um lugar para rodar que não consegue derrubar tudo ao redor, e para agents em produção, essa era a peça que faltava.

Leia isto a seguir

Para a análise de serverless e infraestrutura do mesmo lançamento, o ciclo de vida, a CLI e onde ele se encaixa frente ao Lambda comum, veja as field notes em ercan.cloud. Para consultoria em IA, AWS e trabalho de plataforma, ou só para dar um oi, comece por ercanermis.com.

Referências