AWS rielabora il runtime Bedrock AgentCore per memoria elastica e avvii a freddo rapidi

Amazon Web Services ha annunciato il nuovo runtime AgentCore il 18 settembre 2026, una versione rielaborata del livello di calcolo gestito in Amazon Bedrock AgentCore che, secondo l’azienda, recupera la memoria quando le sessioni degli agenti la rilasciano e garantisce tempi di avvio a freddo coerenti indipendentemente dalla dimensione dell’immagine del contenitore o dalla concorrenza.

Il runtime AgentCore è il livello di calcolo gestito che offre agli sviluppatori un ambiente completamente gestito per distribuire ed eseguire agenti senza dover costruire o mantenere infrastrutture. AWS ha dichiarato che migliaia di team lo hanno utilizzato per eseguire agenti in produzione sin dal lancio, e che la prima versione ha stabilito una base serverless con isolamento delle sessioni, comportamento di scalabilità a zero e prezzi basati sul consumo. Questo modello di consumo si mantiene: la fatturazione segue l’utilizzo delle risorse senza costi per CPU inattiva in attesa di I/O, e la piattaforma si riduce completamente a zero quando un agente non ha lavoro.

I problemi che il lancio risolve

Nel runtime originale, una sessione manteneva la memoria assegnata dal momento dell’allocazione fino alla fine della sessione, perché nulla la recuperava nel frattempo. AWS ha affermato che ciò lasciava gli agenti a lungo termine o con picchi a pagare per il loro livello massimo di memoria 24 ore su 24, molto tempo dopo che la memoria non era più utilizzata, una lacuna particolare per gli agenti che hanno picchi occasionali ma rimangono inattivi per la maggior parte della giornata.

Il comportamento di avvio era la seconda sfida. AWS ha dichiarato che una sessione che atterra su un ambiente già inizializzato parte in meno di 100 millisecondi, ma mantenere gli ambienti sufficientemente caldi per garantire ciò richiede di tenere risorse di calcolo in riserva, così la maggior parte delle sessioni inizia con un avvio a freddo che avvia un nuovo ambiente, scarica l’immagine e inizializza l’agente prima che la prima richiesta venga eseguita. Tale latenza aumenta con la dimensione dell’immagine e la concorrenza ed è peggiore sotto traffico a picchi, quando arrivano più sessioni e rimangono meno ambienti pronti. Secondo AWS, i clienti hanno aggirato entrambi i problemi mantenendo ambienti di riserva pronti, ottimizzando l’allocazione della memoria e riducendo la capacità per contenere i costi.

Cosa ha misurato AWS

Per isolare ciò che la piattaforma stessa aggiunge a un avvio a freddo, AWS ha testato un agente echo vuoto che restituisce il suo input e non chiama né modelli né strumenti. Un client Python su un’istanza Amazon EC2 in us-west-2 ha invocato agenti in us-east-1 tramite Internet pubblico senza peering VPC, utilizzando l’SDK boto3, così ogni misurazione lato client include il round‑trip tra le due regioni AWS oltre al tempo di avvio della piattaforma. L’azienda ha inviato 5.000 invocazioni a freddo per agente attraverso entrambe le versioni del runtime e cinque dimensioni di immagine, entro i limiti di quota predefiniti dell’account.

Misurato in questo modo, AWS ha riportato che il nuovo runtime ha fornito una latenza di avvio a freddo al P75 di circa 2 secondi da un’immagine da 200 MB fino a 2 GB, poiché la dimensione dell’immagine non influisce, mentre la latenza del runtime originale aumentava con la dimensione dell’immagine da circa 5,4 secondi a quasi 30 secondi. Nel test echo, il codice dell’agente è stato eseguito in circa 34 millisecondi al P75, quindi quasi tutto il tempo misurato era il tempo di avvio della piattaforma. AWS suggerisce di nascondere il tempo di avvio per gli agenti interattivi avviando la sessione non appena l’utente interagisce, ad esempio quando apre una chat, in modo che l’ambiente si riscaldi mentre digita la prima richiesta.

Come funziona il nuovo runtime

Il nuovo runtime avvia ogni sessione da un piccolo profilo di memoria anziché da un’impronta completamente provisionata, quindi allocca e carica in memoria aggiuntiva su richiesta man mano che il carico di lavoro la utilizza. Quando un agente rilascia buffer per richiesta o lascia scadere i dati nella cache tra le richieste, la piattaforma recupera la memoria invece di lasciarla occupata fino alla fine della sessione. AWS ha dichiarato di aver ottimizzato il comportamento di reclamazione basandosi su un’analisi dei pattern di allocazione su miliardi di sessioni.

Gli avvii a freddo cambiano perché ogni agente viene caricato una sola volta e poi eseguito da uno snapshot. Quando un runtime viene creato o aggiornato, AgentCore avvia il contenitore, attende che segnali lo stato di salute e cattura uno snapshot dell’ambiente in esecuzione, così l’inizializzazione una tantum, come il caricamento di artefatti del modello e il recupero della configurazione statica, è già completata. Ogni nuova istanza ripristina quello snapshot invece di inizializzare da zero. AWS ha affermato che il runtime rimuove cache e memoria transitoria dallo snapshot, così la sua dimensione rimane sostanzialmente costante man mano che l’immagine del contenitore cresce, mantenendo stabile la latenza di ripristino su un’ampia gamma di dimensioni di immagine.

La fatturazione cambia con il modello di memoria. Il nuovo runtime addebita la memoria effettivamente utilizzata dall’agente, caricata su richiesta e recuperata quando inattiva, anziché per il mantenimento dell’intera immagine del contenitore in memoria per tutta la durata della sessione. AWS ha descritto il cambiamento come una tariffa più alta applicata a un numero molto minore di GB‑ora, e ha affermato che per la maggior parte degli agenti l’impronta diminuisce più di quanto aumenti la tariffa, quindi la bolletta si riduce.

Versioni della piattaforma, regioni e limiti

Gli sviluppatori attivano il nuovo runtime impostando il campo platformVersion su V2 durante la creazione o l’aggiornamento di un runtime, secondo la Guida per sviluppatori di AgentCore. V1 è il valore predefinito: omettere il campo durante la creazione genera un runtime V1, e ometterlo durante un aggiornamento mantiene la versione della piattaforma corrente del runtime. V2 è disponibile in us-east-1, us-east-2, us-west-2, eu-west-1 e ap-northeast-1.

Poiché una creazione o aggiornamento V2 prepara e cattura lo snapshot dell’ambiente, tali operazioni richiedono diversi minuti prima che il runtime raggiunga lo stato READY, mentre un runtime V1 diventa pronto in pochi secondi. AgentCore effettua lo snapshot alla prima risposta sana dal endpoint /ping del container e, se il container non segnala stato sano entro 120 secondi dall’avvio, la creazione fallisce con un errore di controllo salute. La guida indica inoltre che V2 attualmente limita la dimensione totale delle variabili d’ambiente a 1,5 KB per distribuzioni di codice diretto e a 2,5 KB per agenti container, rispetto a 4 KB su V1, e che AWS CloudFormation e l’AWS CDK non supportano ancora la configurazione di platformVersion.

Gli snapshot seguono le versioni e gli endpoint del runtime anziché essere gestiti direttamente. AgentCore prepara uno snapshot quando un endpoint punta a una versione e ne elimina uno quando nessun endpoint vi punta, e l’eliminazione può richiedere fino a 8 ore, la durata massima della sessione, perché le sessioni già in esecuzione sullo snapshot continuano fino al loro termine. Le sessioni vengono eseguite in microVM dedicate con risorse CPU, memoria e filesystem isolate, persistono fino a 8 ore e terminano dopo 15 minuti di inattività, dopodiché la microVM viene terminata e la memoria viene sanificata.

Roadmap e avvio

Oltre al lancio, AWS ha elencato diverse funzionalità in arrivo: sconti di base impegnati che riservano un livello minimo di memoria per sessione con burst on‑demand al di sopra, destinati a sessioni sempre attive e costanti; RAM, vCPU e storage di sessione più ampi; supporto microVM x86; sospensione e ripresa con snapshot della memoria più hook di runtime per serializzare lo stato prima che una sessione attiva termini; e chiavi di contesto di sessione che forniscono a ciascuna sessione un’identità limitata per agenti non supervisionati.

AWS ha indirizzato gli sviluppatori alla Guida per sviluppatori di AgentCore, al repository di esempi AgentCore su GitHub e a un esempio di test di carico che dimostra la latenza di avvio a freddo del nuovo runtime all’interno dell’account AWS personale dell’utente.