Amazon Bedrock AgentCore Runtime V2 rende prevedibili gli avvii a freddo, ma la fattura deve ancora dimostrarlo

Amazon ha lanciato Amazon Bedrock AgentCore Runtime V2 con un'affermazione sorprendente: gli avvii a freddo restano vicini ai due secondi per immagini container che vanno da 200 MB a 2 GB.

Il risultato mette in discussione un compromesso noto nel serverless. I team possono portare un agente a zero per risparmiare, ma il successivo utente spesso deve attendere l'avvio del suo ambiente. Mantenere calde le istanze riduce questo ritardo, ma conserva anche capacità che potrebbe restare inattiva.

Runtime V2 interviene su entrambi i lati di questo compromesso. AWS afferma che ripristina snapshot preparati invece di ricostruire ogni ambiente. Recupera inoltre la memoria inutilizzata mentre una sessione resta attiva, anziché fatturare in base al precedente picco massimo della sessione.

L'annuncio è rilevante perché gli agenti in produzione si comportano diversamente dai tradizionali gestori di richieste. Possono attendere i modelli, chiamare strumenti, elaborare file e mantenere uno stato di lavoro durante una lunga sequenza di richieste. Un runtime progettato attorno a brevi transazioni web può sprecare risorse quando queste pause dominano la sessione.

AWS posiziona V2 contro questa discrepanza infrastrutturale, non semplicemente contro un altro framework per agenti. Il confronto centrale è tra un'esecuzione basata su snapshot e sensibile all'utilizzo, e ambienti che restano caldi o mantengono allocazioni di picco per garantire prestazioni prevedibili.

Microsoft e Google offrono già risposte proprie alla latenza di avvio dei container. Microsoft utilizza pool di sessioni preriscaldati, mentre Google raccomanda istanze minime e accelerazione della CPU in fase di avvio. Il nuovo argomento di Amazon è che i team non dovrebbero aver bisogno di capacità permanentemente calda per ottenere un comportamento di avvio coerente.

I numeri sono promettenti, ma provengono dal benchmark di AWS stessa. Gli acquirenti hanno ancora bisogno di evidenze a livello di carico di lavoro che coprano codice di inizializzazione reale, traffico a raffica, pressione sulla memoria, capacità regionale e latenza totale dell'applicazione.

Cosa cambia realmente Amazon Bedrock AgentCore Runtime V2

Runtime V2 cambia quando gli ambienti degli agenti eseguono l'inizializzazione e per quanto tempo la memoria allocata resta fatturabile.

Amazon Bedrock AgentCore Runtime è il livello di calcolo gestito all'interno di AgentCore. Ospita un agente o uno strumento in una microVM isolata, una macchina virtuale leggera con risorse separate di CPU, memoria e filesystem.

AWS ha annunciato V2 il 18 settembre 2026. Gli sviluppatori possono selezionarla impostando platformVersion su V2 durante la creazione o l'aggiornamento di un runtime. Secondo l'attuale architettura del runtime, V1 resta l'impostazione predefinita.

La prima grande modifica riguarda l'inizializzazione. Quando uno sviluppatore crea o aggiorna un runtime V2, AgentCore avvia il container e attende il relativo health check. La piattaforma acquisisce quindi uno snapshot preparato di quell'ambiente in esecuzione.

Le istanze future ripristinano lo snapshot invece di ripetere l'intera sequenza di avvio. Il lavoro eseguito una sola volta, come il caricamento di librerie, il recupero di configurazioni statiche o la preparazione di artefatti del modello, può quindi avvenire prima dell'arrivo della prima richiesta reale.

Lo snapshotting non è di per sé una novità. Anche AWS Lambda SnapStart ripristina ambienti di esecuzione inizializzati per ridurre i ritardi di avvio. AgentCore applica l'approccio a sessioni di agenti isolate e più durature, con container personalizzati e interazioni con stato.

La seconda modifica riguarda la contabilizzazione della memoria. V1 manteneva la memoria allocata fino alla fine di una sessione, anche quando l'agente rilasciava buffer o smetteva di accedere a dati memorizzati nella cache. L'utilizzo poteva quindi seguire la massima allocazione di memoria raggiunta durante quella sessione.

V2 parte da un footprint residente più ridotto e carica in memoria le pagine man mano che il carico di lavoro le utilizza. AWS afferma che la piattaforma recupera la memoria dopo che l'applicazione la rilascia o quando i dati diventano inattivi.

Le attuali regole di utilizzo indicano che la memoria inattiva in V2 viene recuperata automaticamente dopo 120 secondi. Alla fatturazione della memoria si applica un minimo di 128 MB, mentre anche l'overhead di sistema concorre all'utilizzo misurato.

La CPU seguiva già un modello orientato al consumo. Quando un agente attende un modello, uno strumento, un database o un'API esterna, gli addebiti per la CPU possono scendere a zero se non resta attivo alcun processo in background. V2 estende questa elasticità in modo più significativo alla memoria.

Questi cambiamenti contano soprattutto quando una sessione attraversa fasi molto diverse. Un agente documentale potrebbe allocare memoria durante l'analisi di un file di grandi dimensioni, rilasciare quei buffer e poi trascorrere minuti in attesa di chiamate al modello.

In un modello basato sul watermark massimo, la fase di analisi può determinare l'utilizzo della memoria per il resto della sessione. Con V2, AWS afferma che l'utilizzo successivo può diminuire dopo la scomparsa di quell'allocazione temporanea.

Le sessioni AgentCore richiedono comunque un'attenta gestione del ciclo di vita. Una microVM può essere eseguita fino a otto ore e il timeout predefinito per inattività può interrompere prima il suo calcolo. Le applicazioni devono inoltre conservare le informazioni durevoli al di fuori della memoria effimera della sessione.

Il lancio quindi non trasforma un container per agenti in un'infrastruttura persistente illimitata. Cambia l'efficienza e il comportamento di avvio dell'ambiente gestito, mantenendo al contempo i confini di sessione di AgentCore.

Questa distinzione crea la vera tensione. AWS promette la reattività associata alla capacità preparata, mantenendo al contempo l'economia dell'esecuzione scale-to-zero.

Perché i carichi di lavoro degli agenti hanno messo in crisi il vecchio modello di memoria

Il vecchio modello è diventato inefficiente perché le sessioni degli agenti restano attive tra picchi alternati di calcolo, crescita della memoria e attese esterne.

Una richiesta web convenzionale ha solitamente un ciclo di vita breve e comprensibile. Arriva, esegue il codice applicativo, accede a un database, restituisce una risposta e rilascia il proprio ambiente di esecuzione.

Un agente può comportarsi più come un lavoratore temporaneo. Riceve un obiettivo, chiama un modello, invoca diversi strumenti, scarica materiale, crea file intermedi, attende approvazioni e riprende in seguito.

Queste fasi impongono richieste diverse al runtime. Le chiamate agli strumenti possono lasciare la CPU quasi inattiva. L'elaborazione di documenti può creare brevi picchi di memoria. Le conversazioni interattive penalizzano i ritardi di avvio, mentre le attività non presidiate privilegiano il costo rispetto alla risposta immediata.

V1 offriva già isolamento delle sessioni, comportamento scale-to-zero e fatturazione della CPU basata sul consumo. Tuttavia, la sua gestione della memoria manteneva le allocazioni dopo la fine della loro fase utile.

Si consideri un agente di programmazione che esamina un grande repository. Potrebbe caricare un indice, ispezionare l'output della build, mantenere diverse risposte degli strumenti e poi rilasciare la maggior parte di quei dati prima di attendere il modello.

Il picco di memoria influiva comunque sull'utilizzo successivo con il runtime originale. Le sessioni più lunghe amplificavano la conseguenza, perché un'allocazione iniziale poteva restare associata al footprint della sessione.

AWS afferma di aver studiato modelli di allocazione in miliardi di sessioni durante l'ottimizzazione di V2. Questa dichiarazione indica un'ampia telemetria interna, ma l'azienda non ha pubblicato la distribuzione, la metodologia o il mix rappresentativo dei carichi di lavoro alla base dell'analisi.

Il recupero della memoria inattiva allinea più strettamente il contatore al carico di lavoro variabile di un agente. Crea inoltre una nuova questione operativa: con quale rapidità i dati rimossi dalla memoria possono tornare disponibili quando un agente ne ha improvvisamente bisogno?

AWS descrive la memoria come caricata su richiesta, recuperata quando viene rilasciata e recuperata quando diventa inattiva. L'annuncio pubblico non fornisce una latenza dettagliata per i page fault né soglie per ogni modello di carico di lavoro.

Questa omissione è importante per gli agenti con grandi cache riutilizzabili. Recuperare una cache può ridurre la memoria misurata, ma ricostruirla in seguito può consumare CPU, aumentare la latenza o ripetere trasferimenti di rete.

Gli sviluppatori dovranno distinguere le allocazioni realmente eliminabili dai dati che migliorano i turni successivi. Un grafico della memoria più basso non significa automaticamente un flusso di lavoro completo più rapido o meno costoso.

L'architettura attribuisce inoltre maggiore importanza al comportamento dell'applicazione. Il software che rilascia buffer temporanei offre alla piattaforma l'opportunità di recuperare memoria. Un processo che conserva riferimenti indefinitamente non può aspettarsi che il runtime deduca che i dati non sono necessari.

Le lunghe sessioni degli agenti rendono preziosa questa disciplina. La documentazione AWS afferma che ogni sessione microVM riceve risorse isolate di calcolo, memoria e filesystem. Una sessione interrotta può in seguito ricevere nuovo calcolo, ma lo stato effimero scompare a meno che l'applicazione non utilizzi uno storage di sessione persistente o un altro servizio durevole.

Questo design protegge la separazione tra utenti, ma impedisce agli sviluppatori di trattare la memoria in-process come un archivio permanente di conoscenza. Registri delle conversazioni, preferenze apprese e fatti riutilizzabili richiedono archiviazione durevole al di fuori della microVM.

La distinzione è particolarmente importante per gli agenti ricchi di conoscenza. I team necessitano inoltre di un archivio operativo ricercabile che copra prompt, documenti sorgente, risultati dei test e modifiche al runtime. Una base di conoscenza ingegneristica mantenuta può preservare tale contesto oltre una singola sessione di esecuzione.

Runtime V2 non elimina queste responsabilità architetturali. Rende il livello di calcolo temporaneo più elastico, aumentando il valore della separazione tra dati di lavoro transitori e conoscenza organizzativa durevole.

Il ripristino degli snapshot riscrive il compromesso degli avvii a freddo

Il miglioramento principale deriva dal ripristino di uno snapshot inizializzato e ottimizzato, le cui dimensioni restano relativamente stabili al crescere dell'immagine container.

Un avvio a freddo è il periodo che precede il momento in cui un ambiente appena creato è pronto a gestire il lavoro applicativo. Può includere il download di un'immagine, il provisioning del calcolo, l'avvio del processo, il caricamento delle dipendenze e l'esecuzione del codice di inizializzazione.

Gli avvii a freddo diventano particolarmente visibili quando il traffico arriva dopo che un servizio è stato ridimensionato a zero. Compaiono anche durante picchi improvvisi, quando gli ambienti esistenti non possono gestire ogni nuova sessione.

I container per agenti di grandi dimensioni possono peggiorare il problema. Possono includere runtime di linguaggio, dipendenze del browser, framework per agenti, parser di documenti, librerie di machine learning e strumenti interni.

Runtime V2 modifica questo percorso. AgentCore inizializza l'ambiente quando viene preparata una versione del runtime, acquisisce il suo stato e ripristina quello stato per le istanze future.

AWS afferma che la piattaforma rimuove anche cache e memoria transitoria di cui un'istanza ripristinata non ha bisogno. Questa ottimizzazione mira a evitare che la dimensione dello snapshot aumenti insieme al footprint residente completo di un container più grande.

Il benchmark di lancio dell'azienda ha inviato 5.000 invocazioni a freddo per agente su V1 e V2. Il test ha coperto cinque dimensioni di immagine con le quote predefinite dell'account.

V2 ha registrato una latenza di avvio a freddo P75 di circa due secondi, da un'immagine di 200 MB fino a un'immagine di 2 GB. P75 significa che il 75 percento degli avvii misurati è stato completato entro o al di sotto del tempo riportato.

V1 si è comportato diversamente nello stesso test AWS. Il suo risultato P75 è passato da circa 5,4 secondi per l'immagine più piccola a quasi 30 secondi per quella più grande.

Questi numeri rendono il meccanismo più interessante di un semplice miglioramento percentuale. AWS sostiene che la dimensione dell'immagine smette di essere un fattore significativo della latenza di ripristino nell'intervallo testato.

Il benchmark ha utilizzato anche un'applicazione echo il cui codice veniva eseguito in circa 34 millisecondi al P75. Questa configurazione isola l'avvio dell'infrastruttura, ma non somiglia al percorso di esecuzione completo di un agente sofisticato.

Gli agenti reali spesso trascorrono diversi secondi per ogni chiamata al modello. Possono inoltre contattare strumenti remoti, recuperare contesto, autenticare gli utenti o stabilire connessioni di rete dopo che l'ambiente è pronto.

Un avvio della piattaforma di due secondi non significa una risposta in due secondi. Significa che l'infrastruttura contribuisce con un ritardo minore e più prevedibile prima che il codice dell'agente riceva la sua prima richiesta.

Questa prevedibilità può contare più della media. I team di prodotto possono progettare stati di caricamento, timeout e aspettative sul primo token con maggiore fiducia quando la latenza di avvio rimane entro un intervallo ristretto.

AWS suggerisce di avviare una sessione quando un utente apre un'interfaccia, prima che invii il primo prompt. Il testo di benvenuto e il tempo di digitazione possono quindi nascondere gran parte dell'intervallo di avvio residuo.

Questa tattica è pratica, ma modifica anche la domanda. L'apertura di un'interfaccia potrebbe creare sessioni che non ricevono mai un messaggio, quindi i team dovrebbero misurare le sessioni abbandonate e la creazione non necessaria di ambienti.

Gli snapshot introducono anche considerazioni relative al deployment. L'inizializzazione acquisita prima dello snapshot non dovrebbe incorporare credenziali scadute, casualità non sicura o stato specifico dell'utente.

La configurazione statica può adattarsi bene. I segreti sensibili al tempo e l'identità per sessione dovrebbero essere ottenuti tramite meccanismi sicuri durante il ripristino. Anche gli health check devono rappresentare un ambiente realmente pronto, non semplicemente una porta di rete in ascolto.

Il modello basato sugli snapshot sposta quindi parte del lavoro dal momento della richiesta al momento del deployment. I team ottengono una creazione più rapida delle istanze, ma devono verificare cosa entra a far parte dello stato acquisito.

AWS Sta Mettendo Pressione sul Modello dei Pool Preriscaldati

L'affermazione competitiva di Amazon non riguarda semplicemente container più veloci; riguarda un avvio coerente senza richiedere a ogni team di finanziare capacità permanentemente calda.

I provider cloud offrono già diversi modi per ridurre la latenza dei cold start. La maggior parte degli approcci scambia risorse inattive, ottimizzazione operativa o vincoli applicativi con risposte più rapide.

Azure Container Apps di Microsoft offre sessioni dinamiche. Queste utilizzano pool di ambienti preriscaldati in grado di allocare sessioni isolate in millisecondi.

Questo modello è adatto a interpreti di codice e carichi di lavoro che necessitano di sandbox usa e getta. La sua velocità deriva dalla disponibilità di ambienti pronti prima dell'arrivo di una richiesta.

Google Cloud Run adotta un approccio più ampio basato sui container. Gli sviluppatori possono configurare istanze minime per mantenere caldi i container, e il potenziamento della CPU all'avvio può accelerare l'inizializzazione.

Mantenere istanze minime riduce l'esposizione ai cold start, ma le istanze inattive possono aumentare i costi. Il potenziamento della CPU all'avvio migliora il percorso di inizializzazione senza eliminare la necessità di caricare e avviare un'applicazione.

Il design V2 di Amazon occupa una posizione diversa. Prepara una volta uno snapshot del runtime, rimuove lo stato non necessario e ripristina istanze isolate man mano che arrivano le sessioni.

Il confronto non è assoluto. I pool preriscaldati possono offrire una latenza di allocazione inferiore al risultato P75 di circa due secondi riportato da AWS. Possono inoltre garantire una soglia di capacità più chiara durante una domanda prevedibile.

Gli snapshot preservano una migliore economia di scale-to-zero quando il traffico è intermittente. Il loro valore cresce quando un team dispone di molti agenti che restano inutilizzati per lunghi periodi ma devono rispondere in modo coerente quando vengono invocati.

Questa competizione riflette una questione di lunga data nel serverless. I clienti dovrebbero pagare per mantenere pronta la capacità, oppure la piattaforma dovrebbe rendere la creazione just-in-time sufficientemente prevedibile da rendere opzionale la capacità calda?

I carichi di lavoro degli agenti rendono la questione più netta. Un'azienda potrebbe gestire centinaia di agenti specializzati, mentre solo una piccola parte svolge lavoro in un dato momento. Mantenere caldo ogni ambiente sprecherebbe capacità.

Il traffico a raffica crea la preoccupazione opposta. Se molte sessioni si avviano insieme, la piattaforma deve ripristinare rapidamente gli snapshot senza introdurre una penalità di concorrenza.

AWS afferma che V2 mantiene la latenza di cold start coerente indipendentemente dalla concorrenza. Tuttavia, la descrizione del benchmark pubblicata enfatizza le dimensioni delle immagini e le quote predefinite. Non divulga ogni livello di concorrenza o condizione regionale.

I team che valutano AgentCore dovrebbero confrontare obiettivi di livello di servizio completi, non un singolo valore di avvio. Le misure utili includono latenza di coda, tempo al primo token del modello, comportamento della cache ripristinata, avvii falliti e prestazioni durante picchi di traffico improvvisi.

Dovrebbero inoltre confrontare il consumo totale di risorse. Un pool preriscaldato ha capacità inattiva visibile, mentre un servizio basato su snapshot può nascondere costi nel ripristino, nel paging della memoria, nel networking o nella ripetuta inizializzazione dopo modifiche al deployment.

La portabilità resta un altro fattore. AgentCore accetta applicazioni containerizzate e supporta framework tra cui LangGraph, CrewAI e Strands Agents. Tuttavia, i suoi controlli del runtime, le API di sessione, il livello di identità e il modello di fatturazione sono specifici di AWS.

Anche Microsoft e Google incoraggiano l'integrazione con i rispettivi servizi circostanti di identità, monitoraggio, storage e AI. La decisione competitiva si estende quindi oltre i cold start.

Un'azienda già standardizzata su un cloud può attribuire maggiore valore alla coerenza operativa che a un vantaggio nel benchmark. Un team che costruisce una piattaforma di agenti sensibile alla latenza potrebbe invece testare direttamente ogni runtime.

AWS ottiene comunque un importante argomento di vendita. V2 le consente di affermare che lo scale-to-zero non richiede più che la latenza di avvio cresca con l'immagine del container.

Se carichi di lavoro indipendenti riprodurranno questo risultato, gli acquirenti cloud si aspetteranno che le piattaforme rivali spieghino perché i pool caldi o le istanze minime restino necessari per applicazioni comparabili.

Il Benchmark è Solido, ma Ristretto

AWS ha dimostrato un miglioramento credibile dell'infrastruttura, ma non ha ancora stabilito costi totali inferiori o latenza applicativa prevedibile per ogni agente in produzione.

La prima limitazione è l'indipendenza della fonte. AWS ha progettato il runtime, selezionato la configurazione di test, eseguito il benchmark e pubblicato i risultati.

Il codice di test allegato consente ai clienti di riprodurre l'esperimento nei propri account. È utile, ma la riproducibilità dipende comunque dalla regione, dalle quote, dal design del container, dalla forma del traffico e dalla tempistica di ciascuna esecuzione.

La seconda limitazione è la scelta del percentile. Il P75 offre una visione migliore rispetto a una media, ma i servizi sensibili alla latenza pianificano spesso attorno ai risultati P95 o P99.

Un P75 stabile di due secondi può coesistere con eventi di coda più lenti. L'annuncio non fornisce la distribuzione completa necessaria per valutare obiettivi rigorosi rivolti agli utenti.

La terza limitazione è la semplicità del carico di lavoro. Un test echo aiuta a isolare l'avvio della piattaforma, ma i container di produzione eseguono una maggiore inizializzazione e stabiliscono più connessioni esterne.

L'acquisizione dello snapshot può incorporare parte dell'inizializzazione. Non può garantire che ogni connessione al database, scambio di credenziali, percorso di rete o dipendenza esterna sia immediatamente utilizzabile dopo il ripristino.

Il quarto problema è l'interpretazione dei costi. AWS afferma che V2 applica una tariffa delle risorse più elevata rispetto a V1, mentre la maggior parte degli agenti dovrebbe consumare memoria sufficientemente inferiore da ridurre la bolletta totale.

Si tratta di una previsione dell'azienda, non di un risultato universale. Un agente con memoria stabile che rilascia raramente allocazioni potrebbe ottenere risparmi limitati pagando al contempo la tariffa V2 più elevata.

Un agente con picchi temporanei di memoria ha argomentazioni più solide. I risparmi dovrebbero migliorare quando grandi buffer scompaiono presto e la sessione rimanente trascorre un tempo sostanziale con un footprint ridotto.

I team dovrebbero testare entrambe le versioni rispetto a tracce identiche. Dovrebbero registrare l'uso della memoria secondo per secondo, il consumo della CPU, la durata della sessione, la latenza di ripristino, i costi del modello, i costi di storage e il trasferimento di rete.

Anche la telemetria di fatturazione richiede cautela. AWS afferma che i dati di monitoraggio possono subire ritardi e differire dai record di fatturazione autorevoli a causa di aggregazione e riconciliazione.

La quinta preoccupazione è il churn della cache. Se V2 recupera dati di cui un agente ha presto nuovamente bisogno, il carico di lavoro potrebbe impiegare ulteriore tempo per ricostruirli.

La regola di recupero dopo 120 secondi di inattività di AWS fornisce una soglia visibile, ma non spiega completamente il comportamento di ogni categoria di memoria. Gli sviluppatori dovrebbero testare intervalli tra i turni che superano tale soglia.

La sesta preoccupazione riguarda la correttezza degli snapshot. Le applicazioni inizializzano spesso generatori di numeri casuali, credenziali, client di rete, file temporanei e thread in background durante l'avvio.

Un processo ripristinato non deve riutilizzare stato non sicuro tra sessioni isolate. I team dovrebbero verificare come si comportano le loro librerie dopo il ripristino e assicurarsi che l'identità per sessione arrivi dopo il confine dello snapshot.

AgentCore fornisce microVM isolate, ma l'applicazione continua a gestire la mappatura utente-sessione. Un backend client deve impedire che un utente fornisca o riutilizzi l'identificatore di sessione di un altro utente.

Sono inoltre possibili fallimenti operativi. Quote, capacità regionale, container non integri, health check difettosi e limiti dei servizi downstream possono tutti dominare l'esperienza utente.

Nessuna di queste domande invalida il benchmark di V2. Definiscono il divario tra un promettente risultato di piattaforma e una decisione di produzione.

La conclusione corretta è condizionale. V2 appare particolarmente interessante per agenti con traffico a raffica, immagini di grandi dimensioni, inizializzazione costosa, picchi temporanei di memoria e lunghi periodi di attesa del modello o degli strumenti.

Gli agenti con memoria stabile, domanda permanentemente attiva, processori specializzati o requisiti rigorosi inferiori al secondo necessitano di un confronto più ampio. AWS stessa sta preparando opzioni di calcolo più grandi e impegni di capacità di base per alcuni di questi carichi di lavoro.

Tre Segnali che Decideranno se V2 Vincerà

Il prossimo test sarà verificare se le misurazioni dei clienti confermeranno una latenza di avvio stabile, bollette totali inferiori e un comportamento sicuro degli snapshot al di fuori del benchmark controllato da AWS.

Il primo segnale è la forma dei risultati di latenza indipendenti. Gli sviluppatori dovrebbero pubblicare cold start P50, P75, P95 e P99 in diverse regioni e modelli di traffico.

La dimensione dell'immagine dovrebbe restare parte di questi test, ma la concorrenza conta altrettanto. Una valutazione utile lancerebbe ondate improvvise di sessioni isolate dopo che un runtime è passato allo scale-to-zero.

Se la latenza di coda rimane stabile con la crescita delle dimensioni delle immagini e della concorrenza, l'affermazione centrale di AWS diventa molto più forte. I container di grandi dimensioni non costringerebbero più i team a mantenere in esecuzione ambienti di riserva.

Se i risultati P95 e P99 variano ampiamente, il titolo sul P75 di due secondi avrà minore valore operativo. I team con agenti interattivi avrebbero comunque bisogno di capacità calda o di una creazione anticipata aggressiva delle sessioni.

Il secondo segnale è il costo misurato nell'arco di sessioni complete. La tariffa delle risorse più elevata di V2 implica che il risultato economico dipende dalla quantità di memoria che il runtime riesce effettivamente a recuperare.

I team dovrebbero riprodurre carichi di lavoro con fasi note. Un test rappresentativo potrebbe analizzare un documento di grandi dimensioni, rilasciare i relativi buffer, eseguire diverse chiamate al modello, attendere oltre 120 secondi e poi riprendere.

Se la memoria fatturata diminuisce dopo la fase di analisi e resta bassa, V2 sostiene l'argomento di costo di AWS. Se il consumo resta vicino al precedente picco, i risparmi attesi si indeboliscono.

Il confronto dovrebbe includere più delle tariffe Runtime. L'inferenza del modello, l'osservabilità, lo storage, il trasferimento di rete, lo storage dei container, le sessioni browser e i servizi degli strumenti possono dominare la bolletta finale.

Questa visione più ampia impedisce che un piccolo risparmio sul runtime venga presentato come una drastica riduzione a livello applicativo. Rivela inoltre se un avvio più rapido incoraggia i team a creare sessioni non necessarie.

Il terzo segnale è la consegna da parte di AWS delle funzionalità indicate come in arrivo. La roadmap include sconti per capacità di base impegnata, maggiori risorse di calcolo e storage, supporto per microVM x86, maggiore controllo del ciclo di vita e identità con ambito di sessione.

Ogni elemento affronta un limite attuale. Gli ambienti più ampi ampliano i carichi di lavoro idonei. Il supporto x86 riduce le difficoltà di migrazione per le dipendenze che non possono passare facilmente a un'altra architettura.

I controlli di sospensione e ripresa aiuterebbero gli agenti a proseguire oltre un singolo ciclo di vita del calcolo. Un'identità con ambito definito chiarirebbe a cosa possono accedere gli agenti non presidiati quando nessuna persona li supervisiona attivamente.

Se AWS offrirà queste capacità con documentazione chiara e un comportamento stabile, Runtime V2 diventerà una piattaforma più ampia anziché un'ottimizzazione mirata dell'avvio a freddo.

Eventuali ritardi metterebbero in luce i limiti dell'attuale versione. Alcuni carichi di lavoro persistenti, specializzati o non presidiati richiederebbero comunque altre opzioni di calcolo AgentCore o infrastrutture esterne.

Gli sviluppatori possono iniziare con un test controllato da V1 a V2. Dovrebbero mantenere costanti il codice dell'agente, le chiamate al modello, la traccia del traffico, la regione e le impostazioni di osservabilità.

La decisione dovrebbe basarsi su cinque risultati: percentili di avvio, tasso di errore delle sessioni, utilizzo della memoria nel tempo, latenza completa del flusso di lavoro e fattura cloud finale.

I prodotti interattivi dovrebbero inoltre testare la tattica di AWS per l'avvio della sessione. Avviare l'ambiente quando un utente apre una chat può nascondere il tempo di avvio, ma le sessioni abbandonate devono rimanere visibili nell'analisi.

Gli agenti in produzione trascorrono sempre più tempo in attesa, nel mantenere lo stato e nel coordinare strumenti, anziché eseguire lavoro CPU continuo. Questo rende l'economia convenzionale dei container poco adatta a molti carichi di lavoro.

Amazon Bedrock AgentCore Runtime V2 offre una risposta tecnicamente coerente. Prepara il lavoro una volta, ripristina uno snapshot più piccolo e rilascia memoria man mano che le esigenze della sessione diminuiscono.

La questione restante è empirica: Amazon Bedrock AgentCore Runtime V2 conserva questi vantaggi con i vostri container, picchi di traffico, dipendenze e controlli di sicurezza?

Eseguite lo stesso carico di lavoro su entrambe le versioni della piattaforma, conservate la distribuzione completa della latenza e controllate la fattura dopo la riconciliazione. Dovrebbe essere questa evidenza a decidere la migrazione, non il titolo dell'annuncio.