AWS AgentCore Runtime aggiunge sessioni più grandi e mount di filesystem

Amazon Web Services ha ampliato il 12 novembre 2026 la nuova generazione di Amazon Bedrock AgentCore Runtime, introducendo sessioni degli agenti più grandi, una tariffazione basata su una baseline impegnata e mount dinamici di filesystem. AWS riferisce che gli aggiornamenti consentono di avviare le sessioni fino a 15 volte più velocemente, mantenendo l’isolamento hardware.

Il runtime aggiornato è disponibile nelle regioni AWS di Nord America, Sud America, Europa e Asia-Pacifico. AgentCore Runtime è il livello di calcolo gestito all’interno di AgentCore, la piattaforma AWS per creare agenti con framework e modelli diversi; la piattaforma nel suo complesso comprende anche autenticazione, controllo degli accessi e osservabilità.

Il rilascio segue l’introduzione di AgentCore Runtime V2 del 18 settembre 2026, che ha portato l’avvio basato su snapshot e il recupero della memoria. All’epoca AWS aveva indicato che l’aumento delle risorse di calcolo e dello spazio di archiviazione, insieme alla tariffazione con baseline impegnata, sarebbe arrivato in seguito; queste funzionalità costituiscono ora gran parte dell’aggiornamento, insieme al montaggio dei filesystem.

Sessioni più grandi senza pool di istanze già avviate

Ogni sessione può ora utilizzare fino a 8 vCPU e 32 GB di memoria e supportare immagini di container fino a 10 GB. AWS afferma che la capacità di calcolo è quattro volte superiore a quella della versione precedente e che le sessioni si avviano in meno di due secondi, indipendentemente dalle dimensioni dell’immagine o dal livello di concorrenza. In questo modo, per ridurre i ritardi di avvio a freddo, non sono più necessari pool di istanze già avviate o cluster preconfigurati gestiti dai clienti.

Il meccanismo di avvio si basa sul ripristino di snapshot, anziché sulla ripetizione dell’inizializzazione. AgentCore prepara una volta un ambiente container integro, ne acquisisce lo stato inizializzato e ripristina lo snapshot per ogni nuova istanza: operazioni come il caricamento degli artefatti del modello e il recupero della configurazione statica non vengono quindi ripetute a ogni avvio a freddo.

Siwei Shen, vicepresidente dell’ingegneria di Coinbase, ha descritto il risultato ottenuto in produzione: «Il passaggio alla nuova generazione di AgentCore Runtime ha ridotto da quasi un minuto a meno di cinque secondi i tempi di avvio a freddo delle sessioni dei nostri agenti, anche durante i picchi di traffico. Ha inoltre eliminato i ritardi di avvio superiori a 30 secondi, mentre il volume settimanale dei nostri agenti è più che raddoppiato».

Mission Cloud ha riferito che un confronto iniziale, condotto con lo stesso carico di query in linguaggio naturale su entrambe le versioni del runtime, ha registrato avvii a freddo più rapidi del 35% per le richieste di inferenza, avvii dei controlli di integrità più rapidi del 77% e un costo del runtime misurato per chiamata inferiore del 17%. Il suo agente recupera informazioni sugli immobili e sulle vendite senza che gli utenti debbano esplorare sistemi di dati complessi.

Recupero della memoria e tariffazione con baseline

AWS sta modificando anche il modo in cui viene fatturata la memoria durante i periodi di inattività. Il runtime recupera la memoria entro pochi minuti dal momento in cui un agente la rilascia e riduce a zero le risorse di un agente inattivo; secondo AWS, gli agenti che gestiscono più turni con pause naturali possono consumare fino al 68% di memoria in meno per sessione. La modifica risolve il problema del modello precedente, che tendeva a fatturare l’allocazione massima di memoria della sessione anche quando la memoria non era più in uso.

Per gli agenti sempre attivi, la tariffazione con baseline impegnata stabilisce una quantità di memoria di base per sessione, fatturata come minimo, e consente di raggiungere su richiesta un picco pari a quattro volte tale quantità. AWS descrive la tariffa risultante, prevedibile per i carichi di lavoro costanti, come basata sulle tariffe AWS Lambda MicroVM; per i carichi di lavoro variabili e con scalabilità fino a zero continua ad applicarsi la tariffazione a consumo.

Zuora ha riferito che, in molti casi d’uso, il nuovo runtime ha ridotto di circa il 60% l’impronta di memoria per invocazione, gestendo al contempo più traffico con una latenza costante.

Archiviazione, isolamento e limiti di distribuzione

Ogni sessione continua a essere eseguita nella propria microVM Firecracker isolata a livello hardware, con identità, criteri di accesso e traccia di audit distinti. Gli agenti possono ora montare dinamicamente un filesystem e salvare i risultati del proprio lavoro al suo interno, per esempio in un bucket Amazon S3 con supporto FUSE. AWS afferma che, per l’intera durata del processo, i dati restano entro il perimetro di attendibilità della sessione e sono soggetti a un unico insieme di controlli; l’isolamento si estende così oltre l’ambiente di calcolo.

La disponibilità annunciata non include l’ambito delle cartelle di archiviazione per singola sessione. AWS afferma che, entro re:Invent, le credenziali associate alla sessione collegheranno ciascuna sessione alla propria cartella di archiviazione, aggiungendo un controllo più granulare alla funzionalità di montaggio.

Anche nella documentazione V2 attuale sono indicate alcune differenze di distribuzione. V2 resta un’opzione da attivare, poiché V1 è la versione predefinita, a meno che platformVersion non sia impostato su V2; la creazione o l’aggiornamento di un runtime V2 richiede diversi minuti mentre AWS prepara lo snapshot, e il container deve risultare integro tramite il proprio /ping endpoint entro 120 secondi. Questi tempi di configurazione sono distinti dalla latenza di avvio a freddo delle sessioni.

Le sessioni possono durare fino a otto ore, ma vengono terminate dopo 15 minuti di inattività, al raggiungimento del limite di durata o se risultano non integre. Lo stato della sessione è effimero: alla terminazione, la microVM viene distrutta e la memoria sanificata.

Il rilascio riunisce il calcolo delle sessioni, la fatturazione della memoria e i dati dei processi in un unico modello di runtime gestito. L’aspetto ancora da completare è l’isolamento granulare dell’archiviazione: la definizione dell’ambito di archiviazione per sessione è il passaggio che resta da compiere per estendere la garanzia di isolamento del runtime dall’esecuzione ai risultati salvati dagli agenti.