AWS rediseña el tiempo de ejecución Bedrock AgentCore para memoria elástica y arranques en frío rápidos

Amazon Web Services anunció el nuevo tiempo de ejecución AgentCore el 18 de septiembre de 2026, una versión revisada de la capa de cómputo gestionada en Amazon Bedrock AgentCore que la compañía dice recupera la memoria a medida que las sesiones de agentes la liberan y ofrece tiempos de arranque en frío consistentes sin importar el tamaño de la imagen del contenedor o la concurrencia.

El tiempo de ejecución AgentCore es la capa de cómputo gestionada que brinda a los desarrolladores un entorno totalmente administrado para desplegar y ejecutar agentes sin construir o mantener infraestructura. AWS dijo que miles de equipos lo han usado para ejecutar agentes en producción desde su lanzamiento, y que la primera versión estableció una base sin servidor con aislamiento de sesiones, comportamiento de escala a cero y precios de pago por uso. Ese modelo de consumo se mantiene: la facturación sigue el uso de recursos sin cargo por CPU inactiva esperando I/O, y la plataforma escala hasta cero cuando un agente no tiene trabajo.

Los problemas que aborda el lanzamiento

En el tiempo de ejecución original, una sesión mantenía su memoria asignada desde el momento de la asignación hasta que la sesión terminaba, porque nada la recuperaba en el proceso. AWS dijo que eso dejaba a los agentes de larga duración o con picos pagando por su punto máximo de uso las 24 horas, mucho después de que la memoria dejara de usarse, una brecha particular para los agentes que experimentan picos ocasionales pero permanecen inactivos la mayor parte del día.

El comportamiento de inicio fue el segundo desafío. AWS dijo que una sesión que se ejecuta en un entorno ya inicializado arranca en menos de 100 milisegundos, pero mantener los entornos lo suficientemente calientes para garantizar eso implica reservar capacidad de cómputo, de modo que la mayoría de las sesiones comienzan con un arranque en frío que inicia un entorno nuevo, descarga la imagen e inicializa el agente antes de que se procese la primera solicitud. Esa latencia aumenta con el tamaño de la imagen y la concurrencia, y es peor bajo tráfico con picos, cuando llegan la mayor cantidad de sesiones y quedan pocos entornos listos. Según AWS, los clientes mitigaron ambos problemas manteniendo entornos de reserva listos, optimizando la asignación de memoria y reduciendo la capacidad para controlar los costos.

Qué midió AWS

Para aislar lo que la propia plataforma añade a un arranque en frío, AWS probó un agente de eco vacío que devuelve su entrada y no llama a ningún modelo ni a herramientas. Un cliente Python en una instancia Amazon EC2 en us-west-2 invocó agentes en us-east-1 a través de Internet público sin emparejamiento VPC, usando el SDK boto3, por lo que cada medición del lado del cliente incluye el viaje de ida y vuelta entre las dos regiones de AWS además del tiempo de inicio propio de la plataforma. La empresa envió 5 000 invocaciones en frío por agente a través de ambas versiones del tiempo de ejecución y cinco tamaños de imagen, dentro de los límites de cuenta predeterminados.

Medido de esa forma, AWS informó que el nuevo tiempo de ejecución ofreció una latencia de arranque en frío P75 de aproximadamente 2 segundos para una imagen de 200 MB hasta 2 GB, porque el tamaño de la imagen no le afecta, mientras que la latencia del tiempo de ejecución original aumentó con el tamaño de la imagen, pasando de aproximadamente 5,4 segundos a casi 30 segundos. En la prueba de eco, el propio código del agente se ejecutó en unos 34 milisegundos en P75, de modo que casi todo el tiempo medido correspondió al tiempo de inicio de la plataforma. AWS sugiere ocultar el tiempo de inicio para agentes interactivos iniciando la sesión tan pronto como el usuario interactúe, por ejemplo al abrir un chat, de modo que el entorno se caliente mientras escribe la primera solicitud.

Cómo funciona el nuevo tiempo de ejecución

El nuevo tiempo de ejecución inicia cada sesión a partir de un perfil de memoria pequeño en lugar de una huella totalmente provisionada, y luego asigna y carga en memoria adicional bajo demanda a medida que la carga de trabajo la utiliza. Cuando un agente libera buffers por solicitud o permite que los datos en caché expiren entre solicitudes, la plataforma recupera la memoria en lugar de dejarla reservada hasta que la sesión finalice. AWS dijo que ajustó el comportamiento de reclamación basándose en un análisis de los patrones de asignación en miles de millones de sesiones.

Los arranques en frío cambian porque cada agente se carga una sola vez y luego se ejecuta a partir de una instantánea. Cuando se crea o actualiza un tiempo de ejecución, AgentCore lanza el contenedor, espera a que informe que está saludable y captura una instantánea del entorno en ejecución, de modo que la inicialización única, como la carga de artefactos del modelo y la obtención de la configuración estática, ya está realizada. Cada nueva instancia restaura esa instantánea en lugar de iniciar desde cero. AWS dijo que el tiempo de ejecución elimina cachés y memoria transitoria de la instantánea, por lo que su tamaño permanece prácticamente constante a medida que la imagen del contenedor crece, lo que mantiene la latencia de restauración estable en un amplio rango de tamaños de imagen.

La facturación cambia con el modelo de memoria. El nuevo tiempo de ejecución cobra por la memoria que un agente usa activamente, cargada bajo demanda y recuperada cuando está inactiva, en lugar de cobrar por mantener toda la imagen del contenedor en memoria durante la vida de una sesión. AWS describió el cambio como una tarifa más alta aplicada a muchas menos GB‑hora, y afirmó que para la mayoría de los agentes la huella disminuye más de lo que la tarifa aumenta, por lo que la factura se reduce.

Versiones de la plataforma, regiones y límites

Los desarrolladores activan el nuevo runtime estableciendo el campo platformVersion a V2 al crear o actualizar un runtime, según la Guía del desarrollador de AgentCore. V1 es la predeterminada: omitir el campo al crear produce un runtime V1, y omitirlo en una actualización mantiene la versión de plataforma actual del runtime. V2 está disponible en us-east-1, us-east-2, us-west-2, eu-west-1 y ap-northeast-1.

Como la creación o actualización V2 prepara y captura una instantánea del entorno, esas operaciones se ejecutan durante varios minutos antes de que el runtime alcance el estado READY, mientras que un runtime V1 queda listo en segundos. AgentCore toma la instantánea en la primera respuesta saludable del endpoint /ping del contenedor, y si el contenedor no informa un estado saludable dentro de los 120 segundos posteriores al inicio, la creación falla con un error de verificación de salud. La guía también indica que V2 actualmente limita el tamaño total de variables de entorno a 1,5 KB para implementaciones de código directo y a 2,5 KB para agentes en contenedor, en comparación con 4 KB en V1, y que AWS CloudFormation y el AWS CDK no admiten actualmente la configuración de platformVersion.

Las instantáneas siguen las versiones y los endpoints del runtime en lugar de gestionarse directamente. AgentCore prepara una instantánea cuando un endpoint apunta a una versión y elimina una cuando ningún endpoint la referencia, y la eliminación puede tardar hasta 8 horas, que es la vida máxima de la sesión, porque las sesiones que ya se están ejecutando sobre la instantánea continúan hasta que finalizan. Las sesiones se ejecutan en microVMs dedicadas con recursos aislados de CPU, memoria y sistema de archivos, persisten hasta 8 horas y se terminan tras 15 minutos de inactividad, momento en el cual la microVM se finaliza y la memoria se sanea.

Hoja de ruta y primeros pasos

Más allá del lanzamiento, AWS enumeró varias capacidades en camino: descuentos de línea base comprometidos que reservan un piso de memoria por sesión con ráfagas bajo demanda por encima de él, dirigidos a sesiones siempre activas y constantes; mayor RAM, vCPU y almacenamiento de sesión; soporte para microVM x86; suspensión y reanudación con captura de instantáneas de memoria más ganchos de runtime para serializar el estado antes de que una sesión activa termine; y claves de contexto de sesión que otorgan a cada sesión una identidad delimitada para agentes no supervisados.

AWS dirigió a los desarrolladores al AgentCore Developer Guide, al repositorio de ejemplos AgentCore en GitHub y a un ejemplo de prueba de carga adjunto que muestra la latencia de arranque en frío del nuevo runtime dentro de la propia cuenta de AWS del usuario.