Amazon Bedrock AgentCore Runtime V2 Hace Predecibles los Arranques en Frío, pero la Factura Aún Necesita Pruebas
Amazon lanzó Amazon Bedrock AgentCore Runtime V2 con una afirmación llamativa: los arranques en frío se mantienen cerca de los dos segundos en imágenes de contenedor que van de 200 MB a 2 GB.
Ese resultado cuestiona una concesión habitual de la computación sin servidor. Los equipos pueden escalar un agente a cero y ahorrar dinero, pero el siguiente usuario suele esperar mientras se inicia su entorno. Mantener las instancias activas reduce esa demora, pero también conserva capacidad que puede permanecer inactiva.
Runtime V2 aborda ambos lados de ese equilibrio. AWS afirma que restaura instantáneas preparadas en lugar de reconstruir cada entorno. También recupera memoria no utilizada mientras una sesión sigue activa, en vez de facturar según el máximo anterior de la sesión.
El anuncio importa porque los agentes de producción se comportan de forma distinta a los manejadores de solicitudes convencionales. Pueden esperar a los modelos, llamar herramientas, procesar archivos y conservar estado de trabajo durante una larga secuencia de solicitudes. Un runtime diseñado para transacciones web breves puede desperdiciar recursos cuando esas pausas dominan la sesión.
AWS posiciona V2 frente a ese desajuste de infraestructura, no simplemente frente a otro framework de agentes. La competencia central es entre una ejecución basada en instantáneas y sensible al uso, y entornos que permanecen activos o retienen asignaciones máximas para lograr un rendimiento predecible.
Microsoft y Google ya ofrecen sus propias respuestas a la latencia de inicio de contenedores. Microsoft utiliza grupos de sesiones precalentados, mientras que Google recomienda instancias mínimas y aceleración de CPU durante el inicio. El nuevo argumento de Amazon es que los equipos no deberían necesitar capacidad permanentemente activa para obtener un comportamiento de inicio consistente.
Las cifras son prometedoras, pero proceden del propio benchmark de AWS. Los compradores aún necesitan pruebas a nivel de carga de trabajo que cubran código de inicialización real, tráfico en ráfagas, presión de memoria, capacidad regional y latencia total de la aplicación.
Qué cambia realmente Amazon Bedrock AgentCore Runtime V2
Runtime V2 cambia cuándo los entornos de agentes realizan la inicialización y durante cuánto tiempo la memoria asignada sigue siendo facturable.
Amazon Bedrock AgentCore Runtime es la capa de cómputo gestionada dentro de AgentCore. Aloja un agente o una herramienta en una microVM aislada, una máquina virtual ligera con recursos separados de CPU, memoria y sistema de archivos.
AWS anunció V2 el 18 de septiembre de 2026. Los desarrolladores pueden seleccionarlo configurando platformVersion en V2 al crear o actualizar un runtime. V1 sigue siendo la opción predeterminada según la arquitectura de runtime actual.
El primer cambio importante se refiere a la inicialización. Cuando un desarrollador crea o actualiza un runtime V2, AgentCore inicia el contenedor y espera su comprobación de estado. Después, la plataforma captura una instantánea preparada de ese entorno en ejecución.
Las instancias futuras restauran la instantánea en lugar de repetir toda la secuencia de inicio. Por tanto, el trabajo de una sola vez, como cargar bibliotecas, recuperar configuración estática o preparar artefactos de modelos, puede realizarse antes de que llegue la primera solicitud real.
La creación de instantáneas no es nueva por sí sola. AWS Lambda SnapStart también restaura entornos de ejecución inicializados para reducir demoras de inicio. AgentCore aplica este enfoque a sesiones de agentes aisladas y de mayor duración, con contenedores personalizados e interacciones con estado.
El segundo cambio se refiere a la contabilidad de memoria. V1 retenía la memoria asignada hasta que terminaba una sesión, incluso cuando el agente liberaba búferes o dejaba de acceder a datos en caché. Por tanto, el uso podía seguir la mayor asignación de memoria alcanzada durante esa sesión.
V2 comienza con una huella residente más pequeña y carga memoria por páginas a medida que la carga de trabajo la utiliza. AWS afirma que la plataforma recupera memoria después de que la aplicación la libere o los datos se enfríen.
Las reglas de uso actuales establecen que la memoria inactiva en V2 se recupera automáticamente después de 120 segundos. Se aplica un mínimo de 128 MB a la facturación de memoria, mientras que la sobrecarga del sistema también cuenta para el uso medido.
La CPU ya seguía un modelo orientado al consumo. Cuando un agente espera a un modelo, una herramienta, una base de datos o una API externa, los cargos de CPU pueden caer a cero si no queda ningún proceso en segundo plano activo. V2 extiende esa elasticidad de forma más significativa a la memoria.
Estos cambios importan sobre todo cuando una sesión atraviesa fases marcadamente distintas. Un agente documental podría asignar memoria al analizar un archivo grande, liberar esos búferes y luego pasar minutos esperando llamadas al modelo.
En un modelo de máximo histórico, la fase de análisis puede determinar el uso de memoria durante el resto de la sesión. Con V2, AWS afirma que el uso posterior puede disminuir una vez que desaparece esa asignación temporal.
Las sesiones de AgentCore aún requieren una gestión cuidadosa del ciclo de vida. Una microVM puede ejecutarse hasta ocho horas, y el tiempo de espera predeterminado por inactividad puede detener antes su cómputo. Las aplicaciones también deben conservar la información duradera fuera de la memoria efímera de la sesión.
Por tanto, el lanzamiento no convierte un contenedor de agente en infraestructura persistente ilimitada. Cambia la eficiencia y el comportamiento de inicio del entorno gestionado, manteniendo los límites de sesión de AgentCore.
Esa distinción genera la tensión real. AWS promete la capacidad de respuesta asociada a la capacidad preparada, manteniendo al mismo tiempo la economía de una ejecución que escala a cero.
Por qué las cargas de trabajo de agentes rompieron el antiguo modelo de memoria
El modelo anterior se volvió ineficiente porque las sesiones de agentes permanecen activas entre ráfagas alternas de cómputo, crecimiento de memoria y espera externa.
Una solicitud web convencional suele tener un ciclo de vida corto y comprensible. Llega, ejecuta código de aplicación, accede a una base de datos, devuelve una respuesta y libera su entorno de ejecución.
Un agente puede comportarse más como un trabajador temporal. Recibe un objetivo, llama a un modelo, invoca varias herramientas, descarga material, crea archivos intermedios, espera aprobaciones y se reanuda más tarde.
Esas etapas plantean demandas distintas al runtime. Las llamadas a herramientas pueden dejar la CPU casi inactiva. El procesamiento de documentos puede generar picos breves de memoria. Las conversaciones interactivas penalizan los retrasos de inicio, mientras que las tareas desatendidas priorizan el coste frente a la respuesta inmediata.
V1 ya ofrecía aislamiento de sesiones, comportamiento de escalado a cero y cobro de CPU basado en el consumo. Sin embargo, su gestión de memoria retenía asignaciones después de que hubiera pasado su fase útil.
Consideremos un agente de programación que revisa un repositorio grande. Podría cargar un índice, inspeccionar la salida de compilación, conservar varias respuestas de herramientas y luego liberar la mayor parte de esos datos antes de esperar al modelo.
El pico de memoria seguía afectando al uso posterior con el runtime original. Las sesiones más largas amplificaban la consecuencia porque una asignación temprana podía permanecer asociada a la huella de la sesión.
AWS afirma haber estudiado patrones de asignación en miles de millones de sesiones al ajustar V2. Esa afirmación indica una amplia telemetría interna, pero la empresa no ha publicado la distribución, la metodología ni la combinación representativa de cargas de trabajo detrás del análisis.
Recuperar memoria fría alinea el medidor más estrechamente con la carga de trabajo cambiante de un agente. También plantea una nueva pregunta operativa: ¿con qué rapidez pueden volver los datos paginados cuando un agente necesita inesperadamente utilizarlos de nuevo?
AWS describe la memoria como cargada bajo demanda, recuperada cuando se libera y recuperada cuando se enfría. El anuncio público no proporciona latencia detallada de fallos de página ni umbrales para cada patrón de carga de trabajo.
Esa omisión importa para los agentes con grandes cachés reutilizables. Recuperar una caché puede reducir la memoria medida, pero reconstruirla más tarde podría consumir CPU, aumentar la latencia o repetir transferencias de red.
Los desarrolladores tendrán que distinguir las asignaciones realmente prescindibles de los datos que mejoran turnos posteriores. Un gráfico de memoria más bajo no significa automáticamente un flujo de trabajo completo más rápido o barato.
La arquitectura también da mayor importancia al comportamiento de la aplicación. El software que libera búferes temporales ofrece a la plataforma la oportunidad de recuperar memoria. Un proceso que retiene referencias indefinidamente no puede esperar que el runtime deduzca que los datos son innecesarios.
Las sesiones largas de agentes hacen valiosa esta disciplina. La documentación de AWS indica que cada sesión de microVM recibe recursos aislados de cómputo, memoria y sistema de archivos. Una sesión detenida puede recibir cómputo nuevo más adelante, pero el estado efímero desaparece a menos que la aplicación utilice almacenamiento persistente de sesiones u otro servicio duradero.
Ese diseño protege la separación entre usuarios, pero evita que los desarrolladores traten la memoria en proceso como un almacén de conocimiento permanente. Los registros de conversaciones, las preferencias aprendidas y los datos reutilizables requieren almacenamiento duradero fuera de la microVM.
La distinción es especialmente importante para los agentes con mucho conocimiento. Los equipos también necesitan un registro operativo consultable que cubra prompts, documentos fuente, resultados de pruebas y cambios del runtime. Una base de conocimiento de ingeniería mantenida puede preservar ese contexto más allá de una sesión de ejecución individual.
Runtime V2 no elimina esas responsabilidades arquitectónicas. Hace que la capa de cómputo temporal sea más elástica, lo que aumenta el valor de separar los datos de trabajo transitorios del conocimiento organizacional duradero.
La restauración de instantáneas reescribe el equilibrio de los arranques en frío
La mejora principal proviene de restaurar una instantánea inicializada y depurada cuyo tamaño permanece relativamente estable a medida que crece la imagen del contenedor.
Un arranque en frío es el período previo a que un entorno recién creado esté listo para gestionar el trabajo de la aplicación. Puede incluir extraer una imagen, aprovisionar cómputo, iniciar el proceso, cargar dependencias y ejecutar código de inicialización.
Los arranques en frío se hacen especialmente visibles cuando llega tráfico después de que un servicio se ha escalado a cero. También aparecen durante ráfagas repentinas cuando los entornos existentes no pueden gestionar cada nueva sesión.
Los contenedores de agentes grandes pueden agravar el problema. Pueden incluir runtimes de lenguajes, dependencias de navegador, frameworks de agentes, analizadores de documentos, bibliotecas de aprendizaje automático y herramientas internas.
Runtime V2 cambia esta ruta. AgentCore inicializa el entorno cuando se prepara una versión del runtime, captura su estado y restaura ese estado para instancias futuras.
AWS afirma que la plataforma también elimina cachés y memoria transitoria que una instancia restaurada no necesita. Esta depuración busca evitar que el tamaño de la instantánea crezca con la huella residente completa de un contenedor más grande.
El benchmark de lanzamiento de la empresa envió 5.000 invocaciones en frío por agente en V1 y V2. La prueba cubrió cinco tamaños de imagen bajo las cuotas predeterminadas de la cuenta.
V2 registró una latencia de arranque en frío P75 de aproximadamente dos segundos, desde una imagen de 200 MB hasta una de 2 GB. P75 significa que el 75 por ciento de los arranques medidos se completó en el tiempo informado o por debajo de él.
V1 se comportó de forma diferente en la misma prueba de AWS. Su resultado P75 aumentó de aproximadamente 5,4 segundos para la imagen más pequeña a casi 30 segundos para la más grande.
Estas cifras hacen que el mecanismo resulte más interesante que una simple mejora porcentual. AWS afirma que el tamaño de la imagen deja de ser un factor significativo de la latencia de restauración dentro del rango probado.
El benchmark también utilizó una aplicación de eco cuyo código se ejecutaba en unos 34 milisegundos en P75. Esa configuración aísla el arranque de la infraestructura, pero no se parece a la ruta de ejecución completa de un agente sofisticado.
Los agentes reales suelen dedicar varios segundos a cada llamada al modelo. También pueden contactar herramientas remotas, recuperar contexto, autenticar usuarios o establecer conexiones de red después de que el entorno esté listo.
Un arranque de plataforma de dos segundos no implica una respuesta de dos segundos. Significa que la infraestructura aporta una demora menor y más predecible antes de que el código del agente reciba su primera solicitud.
Esa previsibilidad puede importar más que el promedio. Los equipos de producto pueden diseñar estados de carga, tiempos de espera y expectativas sobre el primer token con mayor confianza cuando la latencia de arranque se mantiene dentro de un rango estrecho.
AWS sugiere iniciar una sesión cuando un usuario abre una interfaz, antes de que esa persona envíe el primer prompt. El texto de bienvenida y el tiempo de escritura pueden ocultar gran parte del intervalo de arranque restante.
La táctica es práctica, pero también cambia la demanda. Abrir una interfaz podría crear sesiones que nunca reciben un mensaje, por lo que los equipos deberían medir las sesiones abandonadas y la creación innecesaria de entornos.
Las instantáneas también introducen consideraciones de despliegue. La inicialización capturada antes de la instantánea no debería incorporar credenciales caducadas, aleatoriedad insegura ni estado específico del usuario.
La configuración estática puede encajar bien. Los secretos sensibles al tiempo y la identidad por sesión deberían obtenerse mediante mecanismos seguros para la restauración. Las comprobaciones de estado también deben representar un entorno realmente preparado, no simplemente un puerto de red en escucha.
Por tanto, el modelo de instantáneas traslada parte del trabajo del momento de la solicitud al momento del despliegue. Los equipos obtienen una creación de instancias más rápida, pero deben auditar qué pasa a formar parte del estado capturado.
AWS está presionando al modelo de pools precalentados
La afirmación competitiva de Amazon no consiste simplemente en contenedores más rápidos; consiste en un arranque consistente sin exigir a todos los equipos financiar capacidad permanentemente caliente.
Los proveedores cloud ya ofrecen varias formas de reducir la latencia de arranque en frío. La mayoría de los enfoques intercambian recursos inactivos, ajuste operativo o restricciones de aplicación por respuestas más rápidas.
Azure Container Apps de Microsoft ofrece sesiones dinámicas. Estas utilizan pools de entornos precalentados que pueden asignar sesiones aisladas en milisegundos.
Ese modelo es adecuado para intérpretes de código y cargas de trabajo que necesitan sandboxes desechables. Su velocidad proviene de disponer de entornos listos antes de que llegue una solicitud.
Google Cloud Run adopta un enfoque más amplio basado en contenedores. Los desarrolladores pueden configurar instancias mínimas para mantener contenedores calientes, y el aumento de CPU durante el arranque puede acelerar la inicialización.
Mantener instancias mínimas reduce la exposición a los arranques en frío, pero las instancias inactivas pueden añadir costes. El aumento de CPU durante el arranque mejora la ruta de inicialización sin eliminar la necesidad de cargar e iniciar una aplicación.
El diseño V2 de Amazon ocupa un punto diferente. Prepara una instantánea del runtime una vez, elimina el estado innecesario y restaura instancias aisladas conforme llegan las sesiones.
La comparación no es absoluta. Los pools precalentados pueden ofrecer una latencia de asignación menor que el resultado aproximado de dos segundos en P75 reportado por AWS. También pueden proporcionar un umbral de capacidad más claro durante una demanda predecible.
Las instantáneas preservan una economía de escalado a cero más sólida cuando el tráfico es intermitente. Su valor aumenta cuando un equipo tiene muchos agentes que permanecen sin usarse durante largos periodos, pero deben responder de forma consistente al ser invocados.
Esta competencia refleja una cuestión persistente de la computación serverless. ¿Deberían los clientes pagar por mantener la capacidad lista o debería la plataforma hacer que la creación justo a tiempo sea lo bastante predecible como para que la capacidad caliente sea opcional?
Las cargas de trabajo de agentes hacen la cuestión más apremiante. Una empresa podría operar cientos de agentes especializados, mientras solo una pequeña parte gestiona trabajo en un momento dado. Mantener caliente cada entorno desperdiciaría capacidad.
El tráfico en ráfagas plantea la preocupación opuesta. Si muchas sesiones se inician a la vez, la plataforma debe restaurar instantáneas rápidamente sin introducir una penalización de concurrencia.
AWS afirma que V2 mantiene consistente la latencia de arranque en frío independientemente de la concurrencia. Sin embargo, la descripción publicada del benchmark enfatiza los tamaños de imagen y las cuotas predeterminadas. No divulga todos los niveles de concurrencia ni las condiciones regionales.
Los equipos que evalúen AgentCore deberían comparar objetivos completos de nivel de servicio, no una sola cifra de arranque. Entre las métricas útiles se incluyen la latencia de cola, el tiempo hasta el primer token del modelo, el comportamiento de la caché restaurada, los arranques fallidos y el rendimiento durante picos bruscos de tráfico.
También deberían comparar el consumo total de recursos. Un pool precalentado tiene capacidad inactiva visible, mientras que un servicio basado en instantáneas puede ocultar costes en la restauración, la paginación de memoria, las redes o la reinicialización repetida tras cambios de despliegue.
La portabilidad sigue siendo otro factor. AgentCore acepta aplicaciones en contenedores y admite frameworks como LangGraph, CrewAI y Strands Agents. Sin embargo, sus controles de runtime, API de sesiones, capa de identidad y modelo de facturación son específicos de AWS.
Microsoft y Google también fomentan la integración con sus servicios circundantes de identidad, monitorización, almacenamiento e IA. Por tanto, la decisión competitiva va más allá de los arranques en frío.
Una empresa ya estandarizada en una nube puede valorar la coherencia operativa más que una ventaja de benchmark. En cambio, un equipo que construya una plataforma de agentes sensible a la latencia podría probar directamente cada runtime.
AWS sigue obteniendo un argumento comercial importante. V2 le permite afirmar que escalar a cero ya no exige que la latencia de arranque crezca con la imagen del contenedor.
Si cargas de trabajo independientes reproducen ese resultado, los compradores cloud esperarán que las plataformas rivales expliquen por qué los pools calientes o las instancias mínimas siguen siendo necesarios para aplicaciones comparables.
El benchmark es sólido, pero limitado
AWS ha mostrado una mejora creíble de infraestructura, pero aún no ha establecido un menor coste total ni una latencia de aplicación predecible para todos los agentes de producción.
La primera limitación es la independencia de la fuente. AWS diseñó el runtime, seleccionó la configuración de prueba, ejecutó el benchmark y publicó los resultados.
El código de prueba adjunto permite a los clientes reproducir el experimento en sus cuentas. Eso es útil, aunque la reproducibilidad sigue dependiendo de la región, las cuotas, el diseño del contenedor, el patrón de tráfico y el momento de cada ejecución.
La segunda limitación es la elección del percentil. P75 ofrece una mejor visión que un promedio, pero los servicios sensibles a la latencia suelen planificarse en torno a resultados P95 o P99.
Un P75 estable de dos segundos puede coexistir con eventos de cola más lentos. El anuncio no proporciona la distribución completa necesaria para evaluar objetivos estrictos orientados al usuario.
La tercera limitación es la simplicidad de la carga de trabajo. Una prueba de eco ayuda a aislar el arranque de la plataforma, pero los contenedores de producción realizan más inicialización y establecen más conexiones externas.
La captura de instantáneas puede incorporar parte de la inicialización. No puede garantizar que todas las conexiones de base de datos, intercambios de credenciales, rutas de red o dependencias externas estén utilizables de inmediato tras la restauración.
La cuarta cuestión es la interpretación de costes. AWS afirma que V2 cobra una tarifa de recursos mayor que V1, aunque la mayoría de los agentes debería consumir suficiente menos memoria como para reducir su factura total.
Esa es una proyección de la empresa, no un resultado universal. Un agente con memoria estable que rara vez libera asignaciones puede obtener ahorros limitados mientras paga la tarifa más alta de V2.
Un agente con picos temporales de memoria tiene un caso más sólido. Los ahorros deberían mejorar cuando los grandes buffers desaparecen pronto y la sesión restante pasa un tiempo considerable con una huella pequeña.
Los equipos deberían probar ambas versiones con trazas idénticas. Deberían registrar el uso de memoria por segundo, el consumo de CPU, la duración de la sesión, la latencia de restauración, los costes de modelo, los costes de almacenamiento y la transferencia de red.
La telemetría de facturación también exige cautela. AWS afirma que los datos de monitorización pueden retrasarse y diferir de los registros de facturación autorizados debido a la agregación y conciliación.
La quinta preocupación es la rotación de caché. Si V2 reclama datos que un agente necesita poco después, la carga de trabajo puede dedicar tiempo adicional a reconstruirlos.
La regla de recuperación tras 120 segundos de inactividad de AWS proporciona un umbral visible, pero no explica por completo cómo se comporta cada categoría de memoria. Los desarrolladores deberían probar intervalos entre turnos que crucen ese umbral.
La sexta preocupación implica la corrección de las instantáneas. Las aplicaciones suelen inicializar generadores de números aleatorios, credenciales, clientes de red, archivos temporales e hilos en segundo plano durante el arranque.
Un proceso restaurado no debe reutilizar estado inseguro entre sesiones aisladas. Los equipos deberían verificar cómo se comportan sus bibliotecas tras la restauración y garantizar que la identidad por sesión llegue después del límite de la instantánea.
AgentCore proporciona microVM aisladas, pero la aplicación sigue siendo propietaria de la asignación entre usuarios y sesiones. Un backend de cliente debe impedir que un usuario proporcione o reutilice el identificador de sesión de otro usuario.
Los fallos operativos también siguen siendo posibles. Las cuotas, la capacidad regional, los contenedores no saludables, las comprobaciones de estado defectuosas y los límites de servicios posteriores pueden dominar la experiencia de usuario.
Ninguna de estas cuestiones invalida el benchmark de V2. Definen la brecha entre un resultado de plataforma prometedor y una decisión de producción.
La conclusión correcta es condicional. V2 parece especialmente atractivo para agentes con tráfico en ráfagas, imágenes grandes, inicialización costosa, picos temporales de memoria y largos periodos de espera del modelo o de herramientas.
Los agentes con memoria estable, demanda permanentemente activa, procesadores especializados o requisitos estrictos de menos de un segundo necesitan una comparación más amplia. AWS está preparando opciones de computación más grandes y compromisos de capacidad base para algunas de esas cargas de trabajo.
Tres señales que decidirán si V2 gana
La siguiente prueba es si las mediciones de clientes confirman una latencia de arranque estable, facturas totales más bajas y un comportamiento seguro de las instantáneas fuera del benchmark controlado de AWS.
La primera señal es la forma de los resultados independientes de latencia. Los desarrolladores deberían publicar arranques en frío P50, P75, P95 y P99 en varias regiones y patrones de tráfico.
El tamaño de imagen debería seguir formando parte de esas pruebas, pero la concurrencia importa igual de mucho. Una evaluación útil lanzaría oleadas repentinas de sesiones aisladas después de que un runtime hubiera escalado a cero.
Si la latencia de cola se mantiene estable a medida que crecen el tamaño de imagen y la concurrencia, la afirmación central de AWS se vuelve mucho más sólida. Los contenedores grandes ya no obligarían a los equipos a mantener entornos de reserva en ejecución.
Si los resultados P95 y P99 varían ampliamente, el titular de dos segundos en P75 tendrá menos valor operativo. Los equipos con agentes interactivos seguirían necesitando capacidad caliente o una creación anticipada agresiva de sesiones.
La segunda señal es el coste medido de sesiones completas. La mayor tarifa de recursos de V2 implica que el resultado económico depende de cuánta memoria recupere realmente el runtime.
Los equipos deberían reproducir cargas de trabajo con fases conocidas. Una prueba representativa podría analizar un documento grande, liberar sus buffers, realizar varias llamadas al modelo, esperar más de 120 segundos y luego reanudar.
Si la memoria medida baja después de la fase de análisis y se mantiene baja, V2 respalda el argumento de costes de AWS. Si el consumo permanece cerca del pico anterior, los ahorros esperados se debilitan.
La comparación debería incluir más que los cargos de Runtime. La inferencia de modelos, la observabilidad, el almacenamiento, la transferencia de red, el almacenamiento de contenedores, las sesiones de navegador y los servicios de herramientas pueden dominar la factura final.
Esa visión más amplia evita que un pequeño ahorro de runtime se presente como una reducción dramática a nivel de aplicación. También revela si un arranque más rápido anima a los equipos a crear sesiones innecesarias.
La tercera señal es la entrega por parte de AWS de las capacidades indicadas como próximas. La hoja de ruta incluye descuentos por capacidad base comprometida, mayor capacidad de computación y almacenamiento, compatibilidad con microVM x86, mayor control del ciclo de vida e identidad con alcance de sesión.
Cada elemento aborda un límite actual. Los entornos más grandes amplían las cargas de trabajo elegibles. La compatibilidad con x86 reduce la fricción de migración para dependencias que no pueden trasladarse fácilmente a otra arquitectura.
Los controles de suspensión y reanudación ayudarían a los agentes a continuar más allá de un único ciclo de cómputo. La identidad con alcance definido aclararía a qué pueden acceder los agentes desatendidos cuando ninguna persona los supervisa activamente.
Si AWS ofrece estas capacidades con documentación clara y un comportamiento estable, Runtime V2 se convierte en una plataforma más amplia en lugar de una optimización específica para los arranques en frío.
Los retrasos dejarían al descubierto los límites de la versión actual. Algunas cargas de trabajo persistentes, especializadas o desatendidas seguirían requiriendo otras opciones de cómputo de AgentCore o infraestructura externa.
Los desarrolladores pueden comenzar con una prueba controlada de V1 a V2. Deben mantener constantes el código del agente, las llamadas al modelo, el rastro de tráfico, la región y los ajustes de observabilidad.
La decisión debe basarse en cinco resultados: percentiles de arranque, tasa de fallos de sesión, uso de memoria a lo largo del tiempo, latencia completa del flujo de trabajo y la factura final de la nube.
Los productos interactivos también deberían probar la táctica de AWS para el inicio de sesión. Iniciar el entorno cuando un usuario abre un chat puede ocultar el tiempo de arranque, pero las sesiones abandonadas deben seguir siendo visibles en el análisis.
Los agentes de producción dedican cada vez más tiempo a esperar, conservar el estado y coordinar herramientas que a ejecutar trabajo continuo de CPU. Eso hace que la economía convencional de los contenedores no encaje bien con muchas cargas de trabajo.
Amazon Bedrock AgentCore Runtime V2 ofrece una respuesta técnicamente coherente. Prepara el trabajo una vez, restaura una instantánea más pequeña y libera memoria a medida que disminuyen las necesidades de la sesión.
La pregunta restante es empírica: ¿Amazon Bedrock AgentCore Runtime V2 conserva esas ventajas con sus contenedores, picos de tráfico, dependencias y controles de seguridad?
Ejecute la misma carga de trabajo en ambas versiones de la plataforma, conserve la distribución completa de latencia e inspeccione la factura tras la conciliación. Esa evidencia debe decidir la migración, no el titular del lanzamiento.
