A AWS anunciou AWS Lambda MicroVMs em 22 de junho de 2026. O serviço adiciona um novo recurso do Lambda para ambientes de execução dedicados, baseados em Firecracker, capazes de rodar código fornecido por usuários ou gerado por IA com isolamento em nível de máquina virtual, estado preservado durante a sessão, endpoints HTTPS exclusivos e controle direto do ciclo de vida.
A pergunta útil não é se MicroVMs são interessantes. São. A pergunta útil é se elas resolvem uma carga de trabalho específica melhor do que Lambda Functions, um interpretador de código gerenciado, contêineres ou uma plataforma própria de VMs.
A lacuna é real: VMs oferecem isolamento forte, mas normalmente demoram demais para iniciar em experiências interativas; contêineres iniciam rápido, mas compartilham kernel; Lambda Functions oferecem isolamento maduro com Firecracker, mas o modelo de requisição/resposta e o limite de 15 minutos não combinam com ambientes de usuário de longa duração. Lambda MicroVMs juntam uma fronteira dedicada de execução, inicialização baseada em snapshot e sessões com estado que podem ser suspensas e retomadas.
Em poucas palavras
AWS Lambda MicroVMs devem ser avaliadas como uma fronteira serverless de execução para sessões interativas e com estado persistente: sandboxes de agentes de IA, ambientes de código por usuário, notebooks, análise de segurança e ferramentas que precisam de runtime próprio e isolamento mais forte do que uma fronteira compartilhada de contêiner. Elas não são um modelo completo de segurança e não substituem Lambda Functions comuns.
| Pergunta | Resposta curta |
|---|---|
| Onde faz mais sentido? | Sessões dedicadas em que um usuário, agente, tarefa ou tenant precisa de ambiente isolado e endpoint próprio. |
| Onde provavelmente é exagero? | Execuções curtas, sem estado e orientadas a eventos, onde Lambda Functions continuam sendo mais simples. |
| O que pode bloquear um piloto? | Regiões disponíveis, suporte a ARM64, quotas, duração da sessão, rede, ciclo de vida da imagem e custo por sessão. |
| O que o isolamento não resolve? | Isolamento em nível de VM melhora a fronteira de execução. Identidade, permissões, saída de rede, autorização de ferramentas, logs e descarte de estado continuam sob sua responsabilidade. |
A mudança principal: sessões, não invocações
Lambda MicroVMs não funcionam como uma Lambda Function comum com um handler esperando eventos. Sua aplicação chama run-microvm quando precisa de um ambiente isolado para um usuário, tarefa, agente ou sandbox. O Lambda inicia essa MicroVM a partir de um snapshot de imagem e retorna um endpoint HTTPS dedicado para aquela sessão.
Clientes então se conectam à aplicação em execução por protocolos como HTTP/2, gRPC ou WebSockets. Quando a sessão fica ociosa, a MicroVM pode ser suspensa e depois retomada com memória e disco preservados. A unidade prática passa a ser a sessão, não a invocação.
Isso também muda o trabalho de plataforma que fica com sua equipe. O Lambda pode escalar verticalmente uma MicroVM em execução acima da base configurada, mas não cria automaticamente uma frota de MicroVMs atrás de um único endpoint compartilhado. Se você precisa de mais ambientes isolados, sua aplicação cria as sessões, rastreia endpoints, roteia usuários ou tarefas para a sessão certa e encerra o que não deve continuar rodando.
A AWS deixou esse padrão mais concreto com o guia de Lambda MicroVMs para sandboxes self-hosted de Claude Managed Agents e a implementação de referência no GitHub. O exemplo inicia uma MicroVM por sessão do Claude a partir de um plano de controle na sua conta AWS. Isso valida o padrão, mas também deixa clara a fronteira de responsabilidade: verificação de webhooks, segredos, builds de imagem, política de rede, monitoramento e limpeza continuam sendo trabalho de plataforma.
Antes de escolher a primeira carga para piloto
Uma carga pode parecer boa para MicroVMs e ainda ser uma escolha ruim para o primeiro piloto se Região, runtime, ciclo de vida ou rede não se encaixarem.
| Área | Fato atual de lançamento | O que isso muda no planejamento |
|---|---|---|
| Região | US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo) | Sem São Paulo no lançamento. Valide residência de dados, latência, transferência e política interna antes de escolher a primeira carga. |
| Arquitetura | ARM64 | Verifique pacotes nativos, binários, agentes, scanners e dependências de runtime. |
| Tamanho da sessão | Até 16 vCPUs, 32 GB de memória e 32 GB de disco | Decida se a carga é mesmo um sandbox de sessão ou se precisa de outro padrão de plataforma. |
| Modelo de escala | Escala vertical automática até 4x a base configurada; novas sessões são criadas com run-microvm | Planeje roteamento de sessões, controle de endpoints, quotas, distribuição de carga e limpeza. |
| Ciclo de vida | Suspensão/retomada dentro de uma duração máxima configurada de até 8 horas | Planeje estado externo, mensagem ao usuário, limpeza e comportamento de retry. |
| Rede | Saída pública para a internet por padrão; egress por VPC com Lambda Network Connectors | Desenhe controles de saída antes de executar código sensível. |
Antes de levar para produção, use a documentação de AWS Lambda MicroVMs como fonte final para Regiões, quotas, preços, APIs, hooks de ciclo de vida e comportamento de versões de imagem.
Quando Lambda MicroVMs fazem sentido
O padrão é mais forte quando isolamento, estado de sessão e runtime próprio são centrais para a experiência do produto. Ele perde força quando a carga é apenas uma tarefa curta ou quando as restrições de lançamento eliminam o desenho.
| Aderência | Use MicroVMs quando... | Cuidado quando... |
|---|---|---|
| Forte | Cada usuário, tarefa, tenant ou agente precisa de ambiente dedicado com arquivos, processos, dependências e endpoint HTTPS próprios. | A sessão também precisa de acesso amplo a dados ou ferramentas; isolamento não substitui autorização. |
| Condicional | A carga é um notebook, sessão de analytics, scanner de segurança ou ferramenta interna em que isolamento ajuda, mas não resolve o desenho inteiro. | Rede privada, evidências de auditoria, limpeza de estado, quotas ou governança de dados ainda estão indefinidas. |
| Fraca | O trabalho é curto, sem estado, orientado a eventos ou já se encaixa bem em Lambda Functions. | A carga exige x86, GPU, sessões mais longas, Região fora do lançamento ou controles de plataforma que ficam fora do modelo de MicroVM. |
Escolha o modelo de execução pela carga
A primeira decisão de arquitetura não é “MicroVMs ou não”. É qual modelo de execução na AWS corresponde à fronteira da carga.
| Se a carga é... | Comece por... | Por quê |
|---|---|---|
| Precisa distribuir requisições automaticamente atrás de um endpoint estável | Lambda Functions, API Gateway, ALB ou um serviço de contêineres | Endpoints de MicroVM pertencem a sessões individuais; sua aplicação precisa rotear usuários e tarefas para a MicroVM certa. |
| Curta, orientada a eventos e quase sempre sem estado | Lambda Functions | Menor sobrecarga operacional para requisições comuns e trabalho em segundo plano. |
| Ainda é uma carga de Function, mas a separação por tenant precisa ser explícita | Padrão de isolamento por tenant no Lambda | Mantém o modelo de Functions com fronteiras de execução separadas por tenant. |
| Um agente de IA só precisa de uma ferramenta gerenciada para executar código | AgentCore Code Interpreter ou sandbox gerenciado semelhante | Reduz o runtime e a infraestrutura de sandbox que sua equipe precisa operar. |
| Uma sessão interativa dedicada com pacotes próprios, estado e endpoint | Lambda MicroVMs | Boa candidata quando Região, ARM64, ciclo de vida, rede e custo se encaixam. |
| Execução longa, com GPU, dependente de x86 ou com controle de host | ECS, EKS, Fargate, EC2 ou outro padrão de plataforma | Esses requisitos normalmente ultrapassam o envelope de lançamento das MicroVMs. |
Como a arquitetura funciona
O ciclo de vida começa com uma imagem de MicroVM. Você empacota a aplicação e o Dockerfile, coloca o artefato no Amazon S3 e chama a API de imagem de Lambda MicroVMs. O Lambda constrói a imagem, inicializa a aplicação e captura um snapshot do ambiente pronto.
Quando o produto precisa de uma sessão, ele chama a API para iniciar a MicroVM. A MicroVM parte do snapshot, recebe um endpoint HTTPS exclusivo e pode atender tráfego interativo, como HTTP/2, gRPC ou WebSockets, dependendo da aplicação exposta. Quando fica ociosa, ela pode ser suspensa preservando memória e disco. Ela retoma quando o tráfego chega ou quando a aplicação chama a API de retomada. Ela termina quando encerrada explicitamente ou quando a duração máxima configurada é atingida.
Esse ciclo de vida é poderoso porque o usuário pode voltar para um estado de trabalho aquecido. Também é fácil errar. Qualquer coisa colocada no snapshot inicializado pode aparecer em mais de uma sessão; por isso, segredos, identificadores únicos, credenciais temporárias, conexões e estado por usuário exigem tratamento deliberado.
O que a AWS gerencia e o que continua com você
| Camada | A AWS fornece | Sua equipe continua responsável por |
|---|---|---|
| Fronteira de execução | Isolamento baseado em Firecracker e APIs de ciclo de vida. | Escolha da carga de trabalho, mapeamento por tenant, conteúdo da imagem e limpeza da sessão. |
| Identidade | Controles IAM para recursos e chamadas de API do Lambda. | Quem pode iniciar sessões, passar roles, acessar dados ou invocar ferramentas. |
| Acesso ao endpoint | Endpoint HTTPS dedicado e autenticação por token. | Emissão de tokens, expiração, portas permitidas, roteamento de clientes e autorização na aplicação. |
| Rede | Saída pública para a internet por padrão e saída por VPC com Lambda Network Connectors. | Política de saída, security groups, network ACLs, acesso a serviços privados e decisões de bloqueio por padrão. |
| Estado | Preservação de memória e disco durante suspensão e retomada. | Qual estado fica dentro da MicroVM, qual estado deve ir para serviços externos e como estado sensível é removido. |
| Evidência | Eventos de serviço e pontos de integração com logs e monitoramento da AWS. | Correlacionar atividade com usuário, tenant, sessão, agente, aprovação, ferramenta, custo e resultado. |
Trate Lambda MicroVMs como a fronteira de execução, não como a arquitetura completa de segurança. Uma sessão ainda pode criar risco material se tiver permissões IAM amplas, saída de rede irrestrita, tokens de endpoint duradouros, ferramentas poderosas demais ou logs insuficientes.
Rede e autenticação de endpoint
A AWS documenta saída pública para a internet como o caminho padrão de egress para Lambda MicroVMs. Se a sessão precisa acessar RDS, ElastiCache, APIs internas, sistemas on-premises ou serviços privados da AWS, desenhe a saída por VPC com um Lambda Network Connector e aplique os security groups e network ACLs adequados.
O tráfego para o endpoint também precisa de desenho próprio. Requisições ao endpoint de uma MicroVM exigem um token de autenticação no header X-aws-proxy-auth. A AWS descreve esses tokens como JWEs criptografados, com escopo para uma MicroVM específica, portas permitidas e tempo de expiração. Isso transforma duração do token e escopo de portas em decisões de arquitetura, não detalhes de implementação.
Para cargas sensíveis, a pergunta de revisão é simples: o que esta MicroVM consegue alcançar e sob qual autoridade?
A ilusão serverless: a infraestrutura que ainda fica com você
Lambda MicroVMs removem bastante trabalho indiferenciado de infraestrutura. Elas não removem a responsabilidade da plataforma. O trabalho muda de gerenciar hosts para gerenciar imagens, sessões, estado, permissões, saída de rede, evidências e limpeza.
O problema de drift da imagem
Uma MicroVM parte de uma imagem e de um snapshot inicializado. É isso que ajuda a acelerar o lançamento, mas também significa que o ambiente de sandbox tem seu próprio ciclo de release. Atualizações de dependências, patches do sistema operacional, runtimes, ferramentas do agente, templates de prompt, certificados e scripts de bootstrap precisam de versionamento e rollback.
Se a plataforma não consegue dizer qual versão de imagem iniciou qual tenant ou sessão, o drift fica difícil de investigar. Um usuário pode estar em um sandbox corrigido enquanto outro ainda roda o conjunto de dependências de ontem. Um pipeline de produção deve marcar imagens, testar snapshots, promover versões deliberadamente e registrar a versão da imagem em cada sessão.
O problema do estado obsoleto
Suspender e retomar é poderoso porque o usuário pode voltar para um estado de trabalho aquecido. Também cria uma nova fronteira de falha. Para a MicroVM, memória e disco podem parecer preservados. Fora dela, conexões com banco podem ter sido encerradas, tokens podem ter expirado, serviços remotos podem ter rotacionado credenciais e handles antigos podem não ser mais válidos.
Trate a retomada como um caminho parcial de reinicialização, não como prova de que o mundo ficou parado. O código da aplicação deve validar conexões, renovar credenciais, conferir relógios e leases, recriar clientes quando necessário e falhar com segurança antes de devolver a execução para a carga do usuário.
- Não coloque segredos no snapshot. Gere credenciais por sessão depois da inicialização ou recupere-as em runtime com permissões restritas.
- Registre a versão da imagem por sessão. Investigação e rollback dependem de saber exatamente qual ambiente rodou.
- Trate retomada explicitamente. Recicle sockets mortos, renove tokens e valide estado externo antes de continuar o trabalho.
- Externalize estado durável. Uma sessão de MicroVM não é o sistema de registro.
- Desenhe caminhos de encerramento. O limite de ciclo de vida ainda exige limpeza, checkpoints, mensagem ao usuário e comportamento de retry.
Perguntas de custo e dimensionamento
Não modele custo de MicroVMs como preço clássico por invocação de Lambda. A economia se parece mais com planejamento de capacidade no estilo Fargate: escolha uma base, considere uso ativo acima dessa base e modele uma sessão representativa desde a criação até a suspensão ou encerramento.
| Variável | Por que importa |
|---|---|
| Recursos de base | Você paga pela computação de base configurada enquanto a MicroVM está em execução. Superdimensionar a base aumenta o piso de custo de cada sessão ativa. |
| Recursos de pico | Uma MicroVM em execução pode escalar verticalmente até 4x a base configurada durante picos de atividade. Uso acima da base muda o custo do trabalho pesado. |
| Tempo ocioso e política de suspensão | MicroVMs suspensas não geram cobrança de computação, mas experiência do usuário, retomada e política de ciclo de vida ainda precisam funcionar. |
| Operações de snapshot e armazenamento | Imagens, leituras e gravações de snapshot, arquivos de trabalho e estado preservado afetam inicialização e custo fora da computação ativa. |
| Transferência de dados | Tráfego entre Regiões, internet pública e caminhos privados pode mudar custo e viabilidade da arquitetura. |
| Orquestração de sessões | Escala horizontal significa criar mais MicroVMs, rastrear endpoints, respeitar quotas e encerrar sessões quando elas terminam. |
O que validar em um piloto
Comece com uma carga de trabalho, não com uma reescrita da plataforma. Um piloto crível deve produzir evidências para revisão de arquitetura, segurança e FinOps.
- Comportamento de inicialização e retomada com o tamanho real da imagem e das dependências.
- Política de rede com egress padrão desativado ou restringido quando necessário.
- Escopo, expiração e autorização de aplicação para tokens de endpoint.
- Identidade em runtime, permissões IAM, acesso a ferramentas e fronteiras por tenant.
- Higiene de snapshot para segredos, estado único, arquivos e hooks de inicialização.
- Logs que liguem ações a usuário, tenant, sessão, agente, aprovação e resultado.
- Comportamento em timeout, encerramento, quotas, conexões obsoletas e retries.
- Custo por sessão representativa, incluindo períodos ociosos e estado suspenso.
Metodologia de benchmark que usaríamos
Não publicaremos números de benchmark sem medi-los em um ambiente reproduzível. Uma avaliação útil deve registrar Região, data, tamanho da imagem, configuração de base e pico, número de amostras, latência de inicialização, latência de retomada, comportamento do endpoint, egress padrão versus VPC, preservação de estado, limpeza e premissas de custo. O blog de lançamento da AWS é uma boa referência para o modelo do serviço; evidência de produção ainda precisa de medição específica da carga.
O objetivo desse benchmark não é provar que toda carga deve usar MicroVMs. É decidir se uma carga específica tem caminho defensável para produção.
Perguntas frequentes
Lambda MicroVMs substituem Lambda Functions?
Na maioria dos casos, não. Lambda Functions continuam sendo mais simples para trabalho curto, sem estado e orientado a eventos. Lambda MicroVMs atendem sessões dedicadas que precisam de ambiente próprio, estado, isolamento, endpoint e ciclo de vida interativo mais longo.
As Lambda MicroVMs escalam como Lambda Functions?
Não. Lambda Functions escalam ambientes de execução automaticamente conforme a demanda de invocações. Lambda MicroVMs podem escalar verticalmente dentro de uma sessão em execução, mas escala horizontal fica com a aplicação: criar mais MicroVMs, rotear usuários ou tarefas para seus endpoints dedicados, monitorar quotas e encerrar sessões quando não forem mais necessárias.
Lambda MicroVMs bastam para executar código não confiável com segurança?
Nenhuma fronteira de computação basta sozinha. O isolamento da MicroVM ajuda, mas segurança em produção ainda depende de IAM, controle de saída de rede, tokens de endpoint, permissões de ferramentas, logs, separação por tenant e limpeza de estado.
Todo sandbox de agente de IA deve usar Lambda MicroVMs?
Não. Se um interpretador de código gerenciado entregar isolamento e controle suficientes, use o caminho mais simples. Considere MicroVMs quando precisar de runtime próprio, estado de sessão, endpoint privado ou mais controle sobre o ambiente de execução.
Qual é o maior risco de desenho?
O maior risco é assumir que “estar dentro de uma VM” significa “estar seguro”. A pergunta correta é o que a sessão consegue acessar, alterar, revelar ou autorizar além da tarefa para a qual foi criada.
Como a Elevata pode ajudar
Traga uma carga de trabalho candidata. A Elevata ajuda a decidir se Lambda MicroVMs são o modelo de execução certo e o que um piloto seguro precisa comprovar: aderência da carga, comparação com serviços AWS, fronteiras de IAM e tenant, desenho de rede, ciclo de vida de imagens e snapshots, evidências de log, premissas de custo e critérios de aprovação.
Avaliar um piloto com MicroVMs com a Elevata. Se você ainda está definindo o modelo de controle mais amplo, comece pelo nosso guia de arquitetura para sandboxes governados de agentes de IA.
