Bedrock AgentCore runtime V2 reduz o tempo de início de sessão dos agentes

Em números

• 120 segundos é o prazo que o container tem para responder ao primeiro GET /ping antes de a AWS congelar o snapshot da sessão.
• 2 segundos é o tempo típico de uma sessão nova no modo V2, contra cerca de 200 milissegundos de uma sessão já em execução.
• 8 horas é a duração máxima de uma sessão (maxLifetime), com timeout de ociosidade padrão de 15 minutos (idleRuntimeSessionTimeout).
• 33 caracteres é o tamanho mínimo exigido para o runtimeSessionId ao implementar pré-aquecimento de sessão.

O problema

Um agente que processa reclamações ou revisa código pode rodar por horas sem ninguém olhando. Mas boa parte dos agentes construídos com o Amazon Bedrock AgentCore runtime fica atrás de uma interface de chat ou de voz, com uma pessoa esperando a primeira resposta. Nesse cenário, cada milissegundo de inicialização de sessão vira tempo de espera visível, e cada sessão nova custa o início de um microVM do zero.

No modo original do AgentCore runtime (platformVersion V1), toda sessão nova exige puxar a imagem do container do Amazon Elastic Container Registry, iniciar o container e rodar todo o código de inicialização antes de processar a primeira requisição. Quanto maior a imagem, maior o cold start. Para um agente que carrega um modelo local, um binário de browser para automação ou um toolchain de CLI, isso significa repetir, sessão após sessão, um trabalho que não muda entre uma chamada e outra.

O post técnico da AWS que descreve o platformVersion V2 do AgentCore runtime parte desse ponto: como eliminar o trabalho repetido sem abrir mão do isolamento por sessão (cada sessão continua rodando em seu próprio microVM) nem do modelo de cobrança por uso, em que a plataforma escala a zero quando não há trabalho.

A arquitetura

O V2 separa o ciclo de vida do agente em dois momentos: build (uma vez, por create_agent_runtime ou update_agent_runtime) e invoke (toda nova sessão). O fluxo, do deploy até a resposta ao usuário, segue estes passos:

1. Ao criar ou atualizar o runtime, o AgentCore inicia o container numa microVM nova e aguarda o primeiro GET /ping saudável, que precisa chegar em até 120 segundos.
2. Se houver hooksConfiguration, o AgentCore dispara um POST para o endpoint de warmup com o cabeçalho X-Amzn-Bedrock-AgentCore-Runtime-Warmup-Type: memory, ainda na microVM de build, antes do congelamento.
3. O AgentCore limpa o cache de arquivos do sistema operacional (para manter o snapshot pequeno), congela a microVM e grava memória e disco como um snapshot.
4. Numa microVM separada, a AWS restaura esse snapshot para teste e dispara um segundo POST de warmup, agora com o cabeçalho disk, sem que nada dessa chamada vá para o snapshot final.
5. Quando chega uma sessão real, o AgentCore restaura o snapshot numa microVM nova: o processo retoma exatamente de onde foi congelado, com imports, objetos e clientes já prontos.
6. Arquivos da imagem que não estavam em memória são buscados sob demanda, bloco a bloco, na primeira leitura de cada sessão.
7. O handler processa a requisição, busca dados dinâmicos (tokens, feature flags, catálogo de ferramentas) e devolve a resposta; o Amazon CloudWatch registra Latency (tempo até o primeiro byte) e OverheadLatency (a fatia que pertence à plataforma) no namespace AWS/Bedrock-AgentCore.

Essa divisão lembra o AWS Lambda SnapStart para quem já mexeu com Java ou Python no Lambda: o princípio é o mesmo (preparar um snapshot uma vez e restaurá-lo por invocação), mas aqui ele chega a agentes de IA de longa duração, com sessões de até 8 horas.

Os serviços envolvidos

A arquitetura descrita pela AWS usa um conjunto específico de peças do Bedrock, não apenas o runtime isolado:

O cliente bedrock-agentcore-control é quem configura o hook de build, via hooksConfiguration, no momento do create_agent_runtime ou update_agent_runtime.

Trade-offs

Mover trabalho para o init em troca de sessões mais rápidas atravessa pelo menos quatro pilares do Well-Architected Framework, e nenhum deles vem de graça.

• Eficiência de desempenho: tudo que vira objeto em memória durante o init responde na velocidade da RAM em toda sessão restaurada, mas aumenta o tamanho do snapshot e o footprint de memória cobrado por sessão.
• Excelência operacional: todo create ou update do runtime agora leva alguns minutos a mais, porque a AWS precisa terminar de construir o snapshot antes de marcar o runtime como READY; isso muda o ritmo de deploys frequentes.
• Segurança: valores congelados no snapshot são idênticos em toda sessão. Segredos, tokens, nonces e qualquer coisa gerada com o estado do módulo random do Python (ou do NumPy) durante o init saem repetidos em cada sessão nova, e precisam ser gerados no handler, com secrets, os.urandom() ou uuid.uuid4().
• Confiabilidade: um hook de build que responde com status diferente de 2xx, cai a conexão ou estoura o prazo de 120 segundos derruba o create ou o update inteiro, sem retry automático da AWS.

Há ainda uma armadilha sutil: cronômetros e caches com TTL que usam relógio monotônico (time.monotonic()) não percebem o tempo que o snapshot passou armazenado, então timers e rate limiters precisam usar tempo de relógio (time.time()) ou ser reiniciados na primeira requisição da sessão restaurada.

Custo estimado

O post da AWS não publica uma tabela de preço por hora ou por token específica para o AgentCore runtime; quem precisa desse número vai à página de pricing do serviço. O que o material deixa claro é o mecanismo de cobrança: a plataforma escala a zero quando não há sessão ativa, e o V2 recupera memória que as sessões não usam.

A plataforma escala a zero quando não há trabalho, e você só paga pelos recursos que suas sessões consomem.

The platform scales to zero when there's no work, and you only pay for the resources your sessions consume.AWS Machine Learning Blog

Na prática, isso significa que o trade-off da seção anterior vira decisão de custo: manter um modelo local inteiro ou um índice grande em memória durante o init reduz OverheadLatency, mas cada sessão nova paga por carregar aquele footprint maior, mesmo as sessões que nunca tocam naquele dado. Vale medir Latency e OverheadLatency no CloudWatch antes e depois da mudança, porque mover trabalho do handler para o init pode reduzir latência sem reduzir custo, ou até aumentá-lo se o snapshot cresceu mais do que o necessário.

Como adaptar

Para um agente que já roda no Bedrock AgentCore runtime, migrar para V2 por si só já entrega o primeiro ganho: se 2 segundos de início forem aceitáveis, basta trocar o platformVersion e concentrar a inicialização antes de app.run(). Para quem precisa de sub-segundo (chat e voz), a lista de ajustes é concreta:

• Mover imports, criação de clientes boto3 e instanciação do agente para antes de app.run(), incluindo bibliotecas raramente usadas.
• Fechar conexões de rede abertas manualmente antes do freeze; clientes boto3 reconectam sozinhos no primeiro uso, mas outros clientes tentam o socket obsoleto primeiro, adicionando centenas de milissegundos.
• Manter dados estáticos (prompts, configuração, índices pequenos) como objeto em memória, não apenas como leitura de arquivo, porque o cache de arquivos é limpo antes do congelamento.
• Para binários de CLI, browsers ou modelos locais que rodam como processo separado, usar um build hook e, se possível, copiar os arquivos para /dev/shm durante o init, para que as leituras do processo externo venham da RAM.
• Compilar bytecode antecipadamente com UV_COMPILE_BYTECODE=1 ou pip install --compile, para que imports tardios não compilem a partir do código-fonte em toda sessão.
• Carregar dados dinâmicos (catálogo de ferramentas do AgentCore Gateway, feature flags, preços) no handler, com cache de expiração curta, nunca no init.
• Para experiências interativas, disparar uma sessão de prime em background quando o usuário abre o chat, usando um runtimeSessionId com pelo menos 33 caracteres, e reutilizar esse ID no primeiro turno real da conversa.
• Configurar um hook de build via hooksConfiguration apenas quando o init sozinho não resolver, lembrando que a porta escolhida precisa ficar entre 8000 e 12000 e que UpdateAgentRuntime substitui a configuração de hooks inteira a cada chamada.

O exemplo de código do próprio post mostra o padrão mínimo: um agente Strands com BedrockModel(model_id="us.anthropic.claude-haiku-5-5"), prompts carregados de um JSON e um cliente boto3.client("dynamodb"), tudo instanciado antes de app.run(), de modo que toda sessão nova herde esses objetos já prontos.

Fonte: AWS Machine Learning Blog