Executando sandboxes de agentes de IA auto-hospedados com AWS Lambda MicroVMs

Por Brian Krygsman, Josh Rodgers e David Lamb, Arquitetos de Soluções na Amazon Web Services.

As organizações estão construindo agentes de IA que escrevem código, consultam bancos de dados e interagem com sistemas internos de forma autônoma em nome de suas equipes. Esses agentes lidam com casos de uso como revisão automatizada de código, otimização de pipelines de dados e solução de problemas de infraestrutura. Quando seu agente de IA gera um comando shell, consulta um banco de dados ou grava em um sistema de arquivos, esse código precisa de um ambiente seguro para ser executado. Sem isolamento, as chamadas de ferramenta de uma sessão podem contaminar o estado de outra sessão, expor inadvertidamente dados sensíveis entre locatários ou permitir involuntariamente que código não confiável chegue a recursos de produção. Sandboxes auto-hospedados resolvem isso mantendo a execução do agente dentro da sua própria conta da AWS, dando a você controle total sobre rede, segredos e governança.

Suponha que você esteja construindo um agente de IA interno que otimiza consultas de banco de dados para sua equipe de engenharia. Um desenvolvedor pede que ele encontre as dez consultas mais lentas no seu banco de dados de análise, as reescreva com melhor indexação e teste os resultados. São três chamadas de ferramenta em uma única sessão. Uma acessa um banco de dados ativo com credenciais reais. Uma gera código. Uma o executa. Agora multiplique isso por cinquenta desenvolvedores usando o assistente ao mesmo tempo. Cada sessão precisa de suas próprias credenciais, seu próprio sistema de arquivos, seu próprio limite de rede. Se credenciais ou estado cruzarem os limites da sessão, você tem exposição inadvertida de dados.

AWS Lambda MicroVMs é um ambiente de computação Serverless que fornece runtimes de uso geral com o forte isolamento de máquinas virtuais e a escalabilidade rápida do AWS Lambda. Alimentado pela virtualização Firecracker, cada MicroVM executa o Amazon Linux com acesso total ao sistema operacional por até 8 horas. Você inicia, suspende, retoma e encerra MicroVMs de forma programática. Você obtém os benefícios Serverless de infraestrutura gerenciada, escalabilidade responsiva e preços de pagamento por uso. Três recursos tornam o Lambda MicroVMs uma ótima opção para sandboxes de agentes:

Isolamento no nível de VM por ambiente: cada MicroVM é executada em sua própria máquina virtual Firecracker, fornecendo isolamento baseado em virtualização de hardware entre sessões sem a sobrecarga de recursos e o tempo de inicialização necessários para VMs completas. Um desenvolvedor não consegue ver a sessão de um colega de equipe, mesmo quando ambas são executadas ao mesmo tempo.
Inicialização a partir de snapshot: assim como o Lambda SnapStart, as MicroVMs inicializam a partir de um snapshot de memória e disco pré-capturado, ignorando completamente a inicialização do aplicativo. Seu agente obtém um ambiente pronto para uso quase instantâneo.
Escalabilidade vertical de 4x sem reprovisionamento: uma MicroVM em execução pode escalar CPU e memória até 4x sua alocação inicial, que pode variar de 0,25 vCPU/0,5 GB a 4 vCPU/8 GB, sem encerrar ou recriar o ambiente. Se o agente precisar executar uma transformação de dados pesada no meio da sessão, ele pode obter mais recursos sem começar do zero.

Nesta publicação, mostramos como arquitetar e criar um agente de IA auto-hospedado que usa Lambda MicroVMs como sandboxes seguros e isolados para a execução de chamadas de ferramentas. O Lambda MicroVMs pode lidar com o isolamento de computação para a execução de chamadas de ferramentas, enquanto o host para agentes de IA em produção, como o Amazon Bedrock AgentCore, gerencia a lógica do agente, o roteamento de modelos e o estado da sessão. Uma solução de referência completa está disponível em aws-samples.

Como funcionam os sandboxes auto-hospedados

Um desenvolvedor pede ao agente para “encontrar as dez consultas mais lentas no nosso banco de dados de análise e sugerir melhorias de índice”. O sistema de orquestração de agentes inicia uma sessão e, então, divide o objetivo em chamadas de ferramenta e as distribui. Um worker precisa assumir essa sessão, executar as consultas e retornar os resultados.

A maioria dos serviços e frameworks de orquestração de agentes de IA usa um modelo de fila de trabalho para distribuir a execução de chamadas de ferramenta. O serviço de orquestração coloca em fila sessões que representam o trabalho de chamada de ferramenta. Um worker, o processo que reivindica uma sessão e executa suas chamadas de ferramenta, é executado dentro de um ambiente de computação, publica resultados e é encerrado. Nesta arquitetura, cada Lambda MicroVM é o ambiente de computação, e o worker é o processo em execução dentro dele. Os sandboxes auto-hospedados do Claude Managed Agents executam esses workers dentro da sua própria infraestrutura, em vez de em um pool de computação compartilhado e multilocatário. Suas credenciais de banco de dados permanecem na sua nuvem privada virtual (VPC). Suas regras de rede, introspecção e governança se aplicam.

Você pode acionar workers de duas maneiras:

Acionado por webhook: o aplicativo de orquestração envia uma notificação quando uma sessão está pronta. Seu plano de controle inicia um worker sob demanda.
Sempre ativo: um processo de longa duração consulta continuamente a fila de trabalho em busca de novas sessões.

O ciclo de vida do Lambda MicroVMs se alinha com o padrão acionado por webhook, em que cada sessão produz um evento de entrada que inicia uma nova MicroVM. O Lambda MicroVMs oferece suporte a políticas de inatividade configuráveis. Após um período de inatividade configurável, uma MicroVM é suspensa automaticamente, preservando o estado do disco e da memória. Ela é retomada quando chega tráfego de entrada ou quando você chama a API de retomada. A MicroVM é executada durante a duração da sessão, o worker é encerrado e a política de inatividade suspende e, finalmente, encerra a VM. Os hooks de ciclo de vida permitem que você execute uma lógica personalizada em etapas-chave do ciclo de vida da MicroVM.

Em contraste, o padrão sempre ativo corre o risco de interromper o loop de consulta ao suspender a MicroVM quando ociosa, já que não há tráfego de entrada entre as sessões. Você poderia desativar o período de inatividade configurável, mas assim você pagaria por consultas vazias. Use a abordagem acionada por webhook para sandboxes auto-hospedados no Lambda MicroVMs.

Arquitetura

A figura a seguir mostra a arquitetura da solução de referência, com o plano de controle do serviço de orquestração de agentes da Anthropic à esquerda interagindo com um ambiente de sandbox auto-hospedado na AWS à direita.

Figura 1: Arquitetura de referência para sandboxes de agentes de IA auto-hospedados no Lambda MicroVMs

A arquitetura de exemplo é orientada por eventos. O único tráfego de entrada é a chamada do webhook. Quando o evento chega, o manipulador inicia uma MicroVM. Uma vez iniciada, a MicroVM extrai sua sessão atribuída da fila de trabalho do sistema de orquestração e executa a tarefa. No nosso exemplo, a solicitação do desenvolvedor para “encontrar consultas lentas” foi colocada em fila como uma sessão. O agente agora precisa acessar sua infraestrutura, iniciar um ambiente isolado e transferir o trabalho. A sequência a seguir mostra como cada componente interage para concluir uma única sessão.

O serviço de orquestração coloca o trabalho em fila como sessões. Uma MicroVM é iniciada para atender a cada sessão, e o worker é o processo em execução dentro dessa MicroVM que reivindica a sessão, executa chamadas de ferramenta e retorna resultados.

Depois que o serviço de orquestração marca uma sessão como pronta para execução, ele envia um webhook session.status_run_started para um endpoint do Amazon API Gateway, acionando o início de uma MicroVM.
O iniciador (launcher) verifica a assinatura do webhook usando um segredo de assinatura do AWS Systems Manager Parameter Store, rejeitando entregas inválidas ou obsoletas antes de gastar recursos de computação.
O iniciador chama RunMicrovm, passando o ID da sessão e uma referência de segredo por meio de runHookPayload. Ele elimina duplicatas com base no ID do evento do webhook (com suporte do Amazon DynamoDB), de modo que novas tentativas não iniciem VMs duplicadas.
A MicroVM inicializa a partir de um snapshot Firecracker pré-capturado e recebe o despacho em seu hook de ciclo de vida /run. O worker busca a chave do ambiente no Parameter Store usando sua função de execução. Ele extrai a sessão correspondente da fila de trabalho, a reivindica e executa chamadas de ferramenta em um diretório /workspace isolado. Quando termina, publica os resultados e é encerrado. A política de inatividade suspende e, então, encerra a VM.

Deduplicação. O ID do evento do webhook serve como chave de idempotência. O iniciador usa o Powertools for AWS Lambda (Python) com uma camada de persistência do DynamoDB para verificar o processamento único exato. Se o aplicativo de orquestração tentar novamente uma entrega com o mesmo ID de evento, o Powertools protege o sistema contra o início de MicroVMs extras e trabalho extra.

Limites de credenciais. Cada componente acessa apenas o único segredo de que precisa. O iniciador lê apenas o segredo de assinatura do webhook para verificar eventos de entrada. Ele passa apenas uma referência de ARN para a chave do ambiente no payload da MicroVM. A função de execução da MicroVM recupera apenas essa chave de ambiente em tempo de execução. Nenhum componente isolado detém ambos os segredos.

Componente	Tem acesso a
Lambda de iniciação (launcher)	Segredo de assinatura do webhook (verificar eventos de entrada)
Worker da MicroVM	Chave do ambiente (por meio da função de execução, para consultar e reivindicar sessões)

Modelo de custo. Você paga pelo tempo de execução da MicroVM por sessão, além das cobranças padrão para solicitações do API Gateway, chamadas de API do Parameter Store e invocações do Lambda para o iniciador. Quando nenhuma sessão está ativa, nenhuma MicroVM é executada. O custo escala com as sessões simultâneas e sua duração, evitando cobranças de computação ociosa.

Implementação

As seções a seguir exploram a arquitetura de referência em mais profundidade.

Estrutura do projeto

A solução de referência usa o AWS Serverless Application Model (AWS SAM) para infraestrutura como código. Alternativamente, se você usar um agente de codificação de IA como Claude Code, Kiro ou Cursor, o Agent Toolkit for AWS inclui uma skill de Lambda MicroVMs que fornece ao seu agente os procedimentos para provisionar, configurar e implantar ambientes de sandbox baseados em MicroVM em seu nome.

├── template.yaml                    # SAM: launcher, API, WAF, secrets, roles
├── src/
│   ├── functions/launcher.py        # Verify signature, RunMicrovm
│   ├── microvm-image/
│   │   ├── Dockerfile               # AL2023 + Node.js worker
│   │   └── worker/worker.mjs        # Lifecycle hook server
│   └── scripts/build-image.sh       # Package + create MicroVM image

Iniciador (launcher): verifique o webhook antes de iniciar a computação

Quando o webhook chega informando que a sessão de um desenvolvedor está pronta, a primeira ação do iniciador é a verificação da assinatura. Se falhar, a função retorna 401 imediatamente. Nenhuma MicroVM é iniciada. Nenhuma escrita no DynamoDB é feita. Você não paga por solicitações fraudulentas ou repetidas.

signing_secret=[REDACTED_PASSWORD]  # Verify webhook before spending compute
if not verify_signature(raw_body, headers, signing_secret):
    return {"statusCode": 401, "body": "invalid signature"}

Após a verificação, o iniciador cria um payload de despacho contendo o ID da sessão, o ID do ambiente, a região e uma referência de ARN para o segredo da chave do ambiente. Ele passa isso para RunMicrovm por meio de runHookPayload:

launched = microvm_client.run_microvm(
    image_identifier="arn:aws:lambda:us-east-1:123456789012:microvm-image:worker",
    run_hook_payload=json.dumps({"session": dispatch}),
    execution_role_arn=config.execution_role_arn,
    maximum_duration_in_seconds=28800,
    ingress_network_connectors=["arn:aws:lambda:::network-connector:aws-network-connector:ALL_INGRESS"],
    egress_network_connectors=["arn:aws:lambda:::network-connector:aws-network-connector:INTERNET_EGRESS"],
)

Worker da MicroVM: reivindique uma sessão, execute e encerre

A imagem da MicroVM é criada a partir de um snapshot do Firecracker. O processo do worker é iniciado durante a criação da imagem e é capturado no snapshot, portanto, não há inicialização de aplicativo em tempo de execução. O hook de ciclo de vida /run entrega o payload de despacho:

// POST /aws/lambda-microvms/runtime/v1/run
case "run": {
    const envelope = JSON.parse(rawBody);
    const dispatch = JSON.parse(envelope.runHookPayload);
    res.writeHead(200); // Acknowledge hook immediately
    res.end();
    const key = await fetchParameter(dispatch.session.ENVIRONMENT_KEY_PARAM_NAME);
    await pollAndHandleSession(dispatch.session.ANTHROPIC_SESSION_ID, key);
    // Session complete; terminate this MicroVM to release all resources
    await terminateMicroVm(envelope.microvmId);
}

O worker confirma o recebimento do hook dentro do seu tempo limite, busca a chave do ambiente e reivindica a sessão. É aqui que o trabalho solicitado começa. O worker se conecta ao banco de dados de análise, executa EXPLAIN ANALYZE nas consultas marcadas, grava alternativas otimizadas em /workspace/suggestions.sql e publica os resultados de volta para o desenvolvedor. Tudo isso acontece dentro dessa única VM. Quando a sessão é concluída, o worker chama terminate-microvm para liberar todos os recursos de computação.

Implantação

Para instruções completas de implantação, consulte o README da solução de referência. Antes de implantar, certifique-se de que você tenha estes pré-requisitos.

Pré-requisitos

Uma conta da AWS com permissões para Amazon Simple Storage Service (Amazon S3), AWS Identity and Access Management (IAM), AWS Systems Manager Parameter Store, Amazon API Gateway, AWS Lambda, AWS WAF, Amazon CloudWatch Logs e AWS Lambda MicroVMs.
AWS Command Line Interface (AWS CLI) v2+.
O AWS SAM CLI.
Um agente Anthropic Claude Managed Agents existente configurado com um ambiente self_hosted (anote o ID do agente e o ID do ambiente).
Um segredo de assinatura de webhook e uma chave de ambiente, ambos gerados no Anthropic Claude Console.

Quatro etapas

Implante o plano de controle. Compile e implante a pilha SAM, que cria o Lambda de iniciação, o endpoint do API Gateway, a WebACL do WAF, a tabela de idempotência do DynamoDB, as entradas do Parameter Store e a função de execução da MicroVM.
```
sam build
sam deploy --guided --capabilities CAPABILITY_NAMED_IAM
```
Registre o webhook e preencha os segredos. No Claude Console, registre a saída WebhookUrl da pilha como um endpoint de webhook inscrito em session.status_run_started. Armazene o segredo de assinatura e a chave do ambiente nos recursos do Parameter Store criados pela pilha.
Crie a imagem da MicroVM. Empacote o Dockerfile e o código do worker, faça o upload para o Amazon S3 e crie a imagem. O serviço executa seu Dockerfile, inicia o worker e captura um snapshot do Firecracker. Monitore o progresso da criação no Amazon CloudWatch em /aws/lambda/microvms/<image-name>.
```
./src/scripts/build-image.sh
```
Verifique. Crie uma sessão de teste e confirme que uma MicroVM é iniciada e concluída de ponta a ponta. A solução de referência inclui um script de verificação que cria uma sessão, aciona o webhook e valida o fluxo completo.

Usando o Claude Platform on AWS (CPOA)

A arquitetura anterior funciona de forma semelhante quando você acessa o Claude por meio do Claude Platform on AWS, em vez da API própria. Três coisas mudam no worker:

Inicialização do cliente. Substitua o cliente próprio pelo cliente da AWS e forneça o ID do seu workspace:

from anthropic import AnthropicAWS

client = AnthropicAWS(aws_region="us-east-1")

# Workspace ID is required on every request
# Set via ANTHROPIC_AWS_WORKSPACE_ID env var or pass per-call

Opções de autenticação. O CPOA oferece suporte a dois modos:
1. Chave de API do CPOA (aws-external-anthropic-api-key-...): armazene-a no Parameter Store da mesma forma que a chave de ambiente própria. Essas chaves são de curta duração (tokens STS de 12 horas) e devem ser regeneradas quando expirarem.
2. SigV4 (IAM): a função de execução da MicroVM pode assinar solicitações diretamente, portanto, não há segredo para armazenar ou rotacionar. Defina o segredo da chave de ambiente com um valor de espaço reservado (por exemplo, use-sigv4) e o SDK recorrerá automaticamente às credenciais do IAM. Esse é o caminho recomendado para produção.

Em ambos os modos de autenticação, anexe a política gerenciada da AWS AnthropicSelfHostedEnvironmentAccess à função de execução da MicroVM. Essa política concede as ações aws-external-anthropic necessárias para consultar a fila de trabalho, reivindicar sessões e publicar resultados. Consulte Ações do IAM para o Claude Platform on AWS para a referência completa.

Pré-requisito: Ative a federação de identidade web de saída uma vez por conta da AWS:

aws iam enable-outbound-web-identity-federation

Todo o resto, incluindo verificação de webhook, deduplicação, separação de credenciais e política de inatividade, permanece o mesmo.

Segurança

Anteriormente, falamos sobre o que dá errado sem isolamento. Credenciais expostas entre sessões. Scripts alcançando a produção sem intenção. Agentes escapando de seu sandbox. Essa arquitetura implementa defesa em profundidade para ajudar a evitar isso.

Cada componente acessa um único segredo com escopo definido. O iniciador passa apenas uma referência de ARN para a credencial do worker na MicroVM. A função de execução da MicroVM recupera apenas essa credencial em tempo de execução. A string de conexão do banco de dados de análise não passa pelo iniciador e não deixa seu ambiente.

O AWS WAF aplica conjuntos de regras gerenciadas (OWASP, entradas mal-intencionadas conhecidas, reputação de IP) e limitação de taxa por IP. A validação de solicitação do Amazon API Gateway rejeita corpos malformados. O iniciador realiza a verificação de assinatura HMAC como o verdadeiro limite de autenticação.

Cada sessão é executada em sua própria MicroVM. As sessões não compartilham memória, disco ou namespaces de rede. O Firecracker fornece isolamento baseado em virtualização de hardware. A função do IAM do iniciador lê apenas o segredo de assinatura. A função de execução da MicroVM lê apenas a credencial do worker. Ambas têm escopo definido para ARNs específicos do Parameter Store. O bucket de artefatos do Amazon S3 bloqueia o acesso público, ativa o versionamento e usa criptografia no lado do servidor.

Conclusão

Esta publicação explicou como oferecer ao seu agente de IA interno um local seguro para executar consultas de banco de dados, gerar código e executar scripts em nome de cinquenta desenvolvedores, sem vazar dados entre sessões ou acessar recursos que não deveria.

O AWS Lambda MicroVMs fornece ambientes de computação efêmeros e isolados por VM que se alinham ao modelo de execução por sessão dos sandboxes de agentes de IA. A inicialização baseada em snapshot evita a latência de inicialização do aplicativo. As políticas de inatividade encerram as VMs quando as sessões são concluídas. O isolamento do Firecracker garante que as sessões não compartilhem estado. Você paga apenas pelo tempo de execução ativo e mantém o controle total sobre credenciais, rede e governança dentro do seu limite da AWS.

Você constrói e opera um plano de controle Serverless. Você obtém isolamento de VM por sessão sem custo de computação ociosa e sem locação compartilhada.

Para começar, explore estes recursos:

Leia mais sobre o Lambda MicroVMs na publicação de anúncio de lançamento.
Clone a solução de referência no repositório aws-samples.
Adicione a skill de MicroVMs ao seu agente de codificação.
Saiba mais sobre o AWS Lambda MicroVMs no Guia do desenvolvedor.
Saiba mais sobre a configuração de sandbox auto-hospedado da Anthropic na documentação de sandbox auto-hospedado.
Para mais recursos de aprendizado Serverless, visite Serverless Land.

Este conteúdo foi traduzido a partir da publicação original do blog, que pode ser encontrada aqui.

Biografia do Autores

Brian Krygsman é Especialista em Arquitetura de Soluções Serverless na Amazon Web Services.

Josh Rodgers é Arquiteto de Soluções Sênior na Amazon Web Services.

David Lamb é Arquiteto de Soluções na Amazon Web Services.

Biografia do tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia

O blog da AWS