AWS AgentCore Runtime añade sesiones de mayor tamaño y montajes de sistemas de archivos

Amazon Web Services amplió el 12 de noviembre de 2026 su nueva generación de Amazon Bedrock AgentCore Runtime con sesiones de agente de mayor tamaño, facturación basada en una línea base comprometida y montajes dinámicos de sistemas de archivos. AWS informa que las actualizaciones permiten iniciar sesiones hasta 15 veces más rápido, sin dejar de ofrecer aislamiento por hardware.

La versión actualizada del entorno de ejecución está disponible en regiones de AWS de América del Norte, América del Sur, Europa y Asia-Pacífico. AgentCore Runtime es la capa de cómputo administrada de AgentCore, la plataforma de AWS para crear agentes con distintos marcos de trabajo y modelos; la plataforma también abarca autenticación, control de acceso y observabilidad.

El lanzamiento se produce tras la presentación de AgentCore Runtime V2 el 18 de septiembre de 2026, que incorporó inicios basados en instantáneas y recuperación de memoria. En ese momento, AWS había anunciado que pronto estarían disponibles más capacidad de cómputo y almacenamiento, así como precios basados en una línea base comprometida; esas funciones constituyen ahora buena parte de la actualización, junto con el montaje de sistemas de archivos.

Sesiones de mayor tamaño sin grupos de instancias en espera

Ahora cada sesión puede usar hasta 8 vCPU y 32 GB de memoria, y admitir imágenes de contenedor de hasta 10 GB. Según AWS, esto cuadruplica la capacidad de cómputo de la versión anterior y permite iniciar sesiones en menos de dos segundos, independientemente del tamaño de la imagen o del nivel de concurrencia. Así, ya no es necesario que los clientes administren grupos de instancias en espera ni clústeres aprovisionados de antemano para evitar los arranques en frío.

El mecanismo de inicio restaura instantáneas en lugar de repetir la inicialización. AgentCore prepara una vez un entorno de contenedor en buen estado, captura su estado inicializado y restaura esa instantánea para cada instancia nueva. De este modo, tareas como cargar artefactos de modelos y obtener configuraciones estáticas no se repiten en cada arranque en frío.

Siwei Shen, vicepresidente de Ingeniería de Coinbase, describió el resultado en producción: «La migración a la nueva generación de AgentCore Runtime redujo los arranques en frío de nuestras sesiones de agente de casi un minuto a menos de cinco segundos, incluso durante los picos de tráfico. También eliminó los retrasos de inicio superiores a 30 segundos, al tiempo que nuestro volumen semanal de agentes se más que duplicó».

Mission Cloud informó que una comparación inicial de la misma carga de trabajo de consultas en lenguaje natural con ambas versiones del entorno de ejecución dio como resultado arranques en frío un 35 % más rápidos para las solicitudes de inferencia, inicios de comprobaciones de estado un 77 % más rápidos y un costo de ejecución medido por llamada un 17 % menor. Su agente recupera información sobre propiedades y ventas sin que los usuarios tengan que navegar por sistemas de datos complejos.

Recuperación de memoria y facturación basada en una línea base

AWS también está cambiando la forma de facturar la memoria durante los períodos de inactividad. El entorno de ejecución recupera la memoria a los pocos minutos de que un agente la libere y reduce a cero la capacidad asignada a un agente inactivo; según AWS, los agentes que mantienen varias interacciones con pausas naturales pueden consumir hasta un 68 % menos de memoria por sesión. Esto corrige la tendencia del modelo anterior a facturar la asignación máxima de memoria de la sesión incluso cuando ya no se utilizaba.

Para los agentes que funcionan de forma continua, los precios basados en una línea base comprometida establecen una cantidad mínima de memoria por sesión que se factura como mínimo y permiten aumentarla hasta cuatro veces según la demanda. AWS describe la tarifa resultante, predecible para cargas de trabajo estables, como equivalente a las tarifas de AWS Lambda MicroVM; para las cargas de trabajo con picos y capacidad que puede reducirse a cero se mantiene la facturación por consumo.

Zuora informó que, en muchos casos de uso, el nuevo entorno de ejecución redujo alrededor de un 60 % la memoria utilizada por invocación y permitió gestionar más tráfico con una latencia estable.

Almacenamiento, aislamiento y límites de implementación

Cada sesión sigue ejecutándose en su propia microVM Firecracker aislada por hardware, con identidad, política de acceso y registro de auditoría propios. Ahora los agentes pueden montar dinámicamente un sistema de archivos y guardar allí su trabajo, por ejemplo, en un bucket de Amazon S3 con compatibilidad con FUSE. Según AWS, los datos permanecen dentro del límite de confianza de la sesión durante todo el trabajo y bajo un único conjunto de controles, lo que extiende el aislamiento más allá del entorno de cómputo.

La delimitación del almacenamiento a una carpeta por sesión no forma parte de las funciones cuya disponibilidad se anunció. AWS afirma que, para re:Invent, las credenciales etiquetadas por sesión vincularán cada sesión con su propia carpeta de almacenamiento y añadirán un control más granular a la capacidad de montaje.

La documentación actual de V2 también señala diferencias de implementación. V2 sigue siendo opcional, ya que V1 es la opción predeterminada, a menos que platformVersion se establezca en V2; crear o actualizar un entorno de ejecución V2 lleva varios minutos mientras AWS prepara la instantánea, y el contenedor debe indicar que está en buen estado a través de su /ping punto de conexión en un plazo de 120 segundos. Esos tiempos de configuración son independientes de la latencia de inicio en frío de las sesiones.

Las sesiones pueden durar hasta ocho horas, pero terminan tras 15 minutos de inactividad, al alcanzar ese límite de duración o si dejan de estar en buen estado. El estado de la sesión es efímero; al terminar, se destruye la microVM y se limpia la memoria.

Este lanzamiento integra el cómputo de las sesiones, la facturación de la memoria y los datos de los trabajos en un único modelo de entorno de ejecución administrado. El aspecto aún pendiente es el aislamiento granular del almacenamiento: delimitarlo por sesión es el paso que falta para extender la garantía de aislamiento del entorno de ejecución, desde la ejecución hasta el trabajo guardado por los agentes.