AWS refaz o runtime Bedrock AgentCore para memória elástica e inicializações a frio rápidas

Amazon Web Services anunciou o novo runtime AgentCore em 18 de setembro de 2026, uma versão reformulada da camada de computação gerenciada em Amazon Bedrock AgentCore que a empresa afirma recuperar a memória à medida que as sessões de agente a liberam e oferece tempos de inicialização a frio consistentes, independentemente do tamanho da imagem do contêiner ou da simultaneidade.

O runtime AgentCore é a camada de computação gerenciada que oferece aos desenvolvedores um ambiente totalmente gerenciado para implantar e executar agentes sem construir ou manter infraestrutura. A AWS disse que milhares de equipes o utilizam para executar agentes em produção desde o lançamento, e que a primeira versão estabeleceu uma base serverless com isolamento de sessão, comportamento de escala para zero e preço por uso. Esse modelo de consumo se mantém: a cobrança segue o uso de recursos sem cobrança por CPU ociosa aguardando I/O, e a plataforma escala até zero quando um agente não tem trabalho.

Os Problemas que o Lançamento Aborda

No runtime original, uma sessão mantinha a memória alocada desde o momento da alocação até o término da sessão, porque nada a recuperava ao longo do caminho. A AWS afirmou que isso deixava agentes de longa duração ou com picos pagando por seu ponto máximo de uso o tempo todo, muito depois de a memória ter deixado de ser usada, uma lacuna específica para agentes que apresentam picos ocasionais mas permanecem ociosos na maior parte do dia.

O comportamento de inicialização foi o segundo desafio. A AWS disse que uma sessão que chega a um ambiente já inicializado inicia em menos de 100 milissegundos, mas manter ambientes aquecidos o suficiente para garantir isso significa reservar capacidade de computação, de modo que a maioria das sessões começa com uma inicialização a frio que inicia um ambiente novo, baixa a imagem e inicializa o agente antes que a primeira solicitação seja processada. Essa latência aumenta com o tamanho da imagem e a simultaneidade e é pior sob tráfego em picos, quando chegam mais sessões e restam menos ambientes prontos. Segundo a AWS, os clientes contornaram ambos os problemas mantendo ambientes de reserva prontos, otimizando a alocação de memória e reduzindo a capacidade para controlar os custos.

O que a AWS Mediu

Para isolar o que a própria plataforma adiciona a uma inicialização a frio, a AWS testou um agente de eco vazio que devolve sua entrada e não chama modelo nem ferramentas. Um cliente Python em uma instância Amazon EC2 em us-west-2 invocou agentes em us-east-1 pela internet pública sem emparelhamento de VPC, usando o SDK boto3, de modo que cada medição do lado do cliente inclui a viagem de ida e volta entre as duas regiões da AWS além do tempo de inicialização da própria plataforma. A empresa enviou 5.000 invocações a frio por agente, abrangendo ambas as versões do runtime e cinco tamanhos de imagem, dentro dos limites padrão da conta.

Medido dessa forma, a AWS relatou que o novo runtime entregou uma latência de inicialização a frio P75 de cerca de 2 segundos para imagens de 200 MB até 2 GB, pois o tamanho da imagem não tem efeito, enquanto a latência do runtime original aumentou com o tamanho da imagem de aproximadamente 5,4 segundos para quase 30 segundos. No teste de eco, o próprio código do agente foi executado em cerca de 34 milissegundos no P75, de modo que quase todo o tempo medido foi o tempo de inicialização da plataforma. A AWS sugere ocultar o tempo de inicialização para agentes interativos iniciando a sessão assim que o usuário interage, como ao abrir um chat, para que o ambiente aqueça enquanto ele digita a primeira solicitação.

Como o Novo Runtime Funciona

O novo runtime inicia cada sessão a partir de um pequeno perfil de memória em vez de uma pegada totalmente provisionada, e então aloca e traz memória adicional sob demanda conforme a carga de trabalho a utiliza. Quando um agente libera buffers por solicitação ou permite que dados em cache expirem entre solicitações, a plataforma recupera a memória em vez de deixá‑la ocupada até o término da sessão. A AWS disse que ajustou o comportamento de recuperação com base em uma análise de padrões de alocação em bilhões de sessões.

As inicializações a frio mudam porque cada agente carrega uma vez e depois executa a partir de um snapshot. Quando um runtime é criado ou atualizado, o AgentCore inicia o contêiner, aguarda que ele reporte saúde e captura um snapshot do ambiente em execução, de modo que inicializações únicas, como o carregamento de artefatos de modelo e a obtenção de configurações estáticas, já estejam concluídas. Cada nova instância restaura esse snapshot em vez de iniciar do zero. A AWS afirmou que o runtime remove caches e memória transitória do snapshot, de modo que seu tamanho permanece aproximadamente constante à medida que a imagem do contêiner cresce, mantendo a latência de restauração estável em uma ampla variedade de tamanhos de imagem.

A cobrança muda com o modelo de memória. O novo runtime cobra pela memória que um agente usa ativamente, carregada sob demanda e recuperada quando ociosa, em vez de cobrar por manter toda a imagem do contêiner em memória durante a vida de uma sessão. A AWS caracterizou a mudança como uma taxa mais alta aplicada a muito menos GB‑hora, e afirmou que, para a maioria dos agentes, a pegada diminui mais do que a taxa aumenta, de modo que a conta reduz.

Versões da Plataforma, Regiões e Limites

Os desenvolvedores ativam o novo runtime definindo o campo platformVersion como V2 ao criar ou atualizar um runtime, conforme o Guia do Desenvolvedor do AgentCore. V1 é o padrão: omitir o campo na criação gera um runtime V1, e omiti‑lo em uma atualização mantém a versão de plataforma atual do runtime. V2 está disponível em us-east-1, us-east-2, us-west-2, eu-west-1 e ap-northeast-1.

Como a criação ou atualização V2 prepara e faz snapshot do ambiente, essas operações levam vários minutos antes que o runtime atinja READY, enquanto um runtime V1 fica pronto em segundos. O AgentCore captura o snapshot na primeira resposta saudável do endpoint /ping do contêiner, e se o contêiner não relatar saúde dentro de 120 segundos após a inicialização, a criação falha com um erro de verificação de saúde. O guia também informa que o V2 atualmente limita o tamanho total de variáveis de ambiente a 1,5 KB para implantações diretas de código e 2,5 KB para agentes em contêiner, comparado a 4 KB no V1, e que o AWS CloudFormation e o AWS CDK ainda não suportam a definição de platformVersion.

Os snapshots acompanham as versões e endpoints do runtime em vez de serem gerenciados diretamente. O AgentCore prepara um snapshot quando um endpoint aponta para uma versão e exclui um quando nenhum endpoint o referencia, e a exclusão pode levar até 8 horas, o tempo máximo de vida da sessão, porque as sessões já em execução no snapshot continuam até seu término. As sessões são executadas em microVMs dedicadas com recursos isolados de CPU, memória e sistema de arquivos, permanecem por até 8 horas e são encerradas após 15 minutos de inatividade, momento em que a microVM é finalizada e a memória é sanitizada.

Roteiro e Começando

Além do lançamento, a AWS enumerou várias funcionalidades em desenvolvimento: descontos de baseline comprometidos que reservam um piso de memória por sessão com burst sob demanda acima dele, voltados para sessões sempre ativas e estáveis; maior RAM, vCPU e armazenamento de sessão; suporte a microVMs x86; suspensão e retomada com snapshot de memória mais hooks de runtime para serializar o estado antes que uma sessão ativa seja encerrada; e chaves de contexto de sessão que fornecem a cada sessão uma identidade delimitada para agentes não supervisionados.

A AWS direcionou os desenvolvedores ao AgentCore Developer Guide, ao repositório de exemplos AgentCore no GitHub e a um exemplo de teste de carga que demonstra a latência de cold start do novo runtime dentro da própria conta AWS do usuário.