Amazon Bedrock AgentCore muda runtime padrão e chega à região São Paulo

O que mudou

A partir de 12 de novembro de 2026, todo runtime novo criado no Amazon Bedrock AgentCore passa a usar por padrão a nova geração do runtime do serviço. A mudança troca a forma como o AgentCore trata sessões: em vez de manter capacidade fixa reservada, cada sessão é restaurada a partir de um snapshot do agente já inicializado, e o compute e a memória escalam junto com o volume de trabalho.

Cada sessão continua isolada em sua própria microVM Firecracker, isolamento de hardware. A novidade é que, dentro dessa sessão isolada, o agente agora consegue rodar cargas pesadas sem que o desenvolvedor precise provisionar capacidade antecipadamente: compilar uma base de código grande, dirigir um navegador automatizado ou carregar um modelo local dentro da própria sessão.

Os números do anúncio mostram o ganho de partida a frio. Numa imagem de container de 2 GB, as sessões agora iniciam em menos de 2 segundos no P75, contra 29,7 segundos na geração anterior do runtime. Sessões suportam até 8 vCPU e 32 GB de memória, com imagens de container de até 10 GB.

Para quem constrói agentes multi-turno (aquele chat ou copiloto que mantém contexto ao longo de várias interações), a AWS cita redução de até 68% na memória faturada por sessão, porque agentes ociosos escalam a zero e a memória é liberada em minutos após o fim do uso.

Onde está disponível

O novo runtime já é o padrão em 19 regiões, incluindo South America (São Paulo), ou seja, sa-east-1 está na lista desde o lançamento, não depois. As demais regiões contempladas são N. Virginia, Ohio, Oregon, Canada Central, Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand e Tokyo.

Fora dessa lista, o runtime antigo continua sendo o padrão por enquanto, mas pode ser ativado manualmente via parâmetro, como explicado adiante.

Quanto custa

A fonte não traz uma tabela de preço por vCPU-hora ou por GB processado neste anúncio; ela remete à página de pricing do AgentCore para os valores vigentes. O que o anúncio deixa claro é o vetor de economia: como o runtime escala compute e memória sob demanda e zera agentes ociosos, o modelo de cobrança deixa de penalizar capacidade reservada parada.

Na prática, isso significa que um pipeline de agentes que hoje paga por uma instância ou container sempre ativo, mesmo entre uma chamada e outra, passa a pagar só pelo tempo em que o agente de fato processa algo. Para equipes de dados e IA que rodam agentes com picos irregulares (um agente de análise que só é acionado sob demanda, por exemplo), esse é o ponto que vale checar na página de pricing antes de projetar custo em produção.

Como começar

Runtimes criados a partir de hoje em uma das 19 regiões já nascem na nova geração, sem nenhuma ação extra. Para quem quer usar o novo runtime fora dessas regiões, ou migrar um runtime existente, o controle é o parâmetro platformVersion:

• Definir platformVersion como V2 ao criar ou atualizar um runtime ativa a nova geração.
• Definir platformVersion como V1 mantém um runtime novo na versão atual (anterior).

A documentação do AgentCore runtime e o AWS Blog trazem o passo a passo de configuração; o anúncio não lista flags adicionais de CLI além dessa troca de versão de plataforma.

O que muda para quem já usa

Runtimes que já estavam em produção antes de 12 de novembro de 2026 não são migrados automaticamente: eles permanecem na versão atual até que alguém explicitamente defina platformVersion como V2 na atualização do runtime.

Para quem já opera agentes no Bedrock AgentCore com cargas pesadas, como automação de navegador ou compilação de código dentro da sessão, a migração para V2 é o caminho direto para capturar os 68% de redução em memória faturada e a largada mais rápida (sub-2 segundos contra quase 30 segundos). Vale testar em um runtime não crítico antes de trocar produção, já que o comportamento de snapshot e restauração de sessão é diferente do modelo anterior.

Fonte: AWS What's New