AWS AgentCore Runtime adaugă sesiuni mai mari și montări ale sistemului de fișiere

Amazon Web Services și-a extins, la 12 noiembrie 2026, serviciul de generație următoare Amazon Bedrock AgentCore Runtime, adăugând sesiuni mai mari pentru agenți, facturare pe baza unui nivel de bază angajat și montări dinamice ale sistemului de fișiere. Potrivit AWS, actualizările permit pornirea sesiunilor de până la 15 ori mai rapidă, păstrând totodată izolarea hardware.

Runtime-ul actualizat este disponibil în regiunile AWS din America de Nord, America de Sud, Europa și Asia-Pacific. AgentCore Runtime este stratul de calcul gestionat din cadrul AgentCore, platforma AWS pentru crearea de agenți cu cadre de lucru și modele diferite; platforma în ansamblu include și autentificare, controlul accesului și observabilitate.

Lansarea urmează introducerii AgentCore Runtime V2 din 18 septembrie 2026, care a adus pornirea pe baza instantaneelor și recuperarea memoriei. La acel moment, AWS anunțase că extinderea capacităților de calcul și stocare, precum și tarifarea pentru nivelul de bază angajat, urmau să fie disponibile în curând; aceste funcționalități reprezintă acum o mare parte din actualizare, alături de montarea sistemului de fișiere.

Sesiuni mai mari, fără grupuri de instanțe menținute în stare activă

Fiecare sesiune poate folosi acum până la 8 vCPU și 32 GB de memorie și poate accepta imagini de container de până la 10 GB. Potrivit AWS, aceasta înseamnă de patru ori mai multă capacitate de calcul decât în versiunea anterioară, iar sesiunile pornesc în mai puțin de două secunde, indiferent de dimensiunea imaginii sau de concurență. Astfel, pentru a evita pornirile la rece, clienții nu mai au nevoie de grupuri de instanțe menținute în stare activă sau de clustere preconfigurate pe care să le gestioneze singuri.

Mecanismul de pornire se bazează pe restaurarea instantaneelor, nu pe inițializarea repetată. AgentCore pregătește o singură dată un mediu de container funcțional, îi capturează starea inițializată și restaurează acel instantaneu pentru fiecare instanță nouă. Astfel, operațiuni precum încărcarea artefactelor modelului și preluarea configurației statice nu se repetă la fiecare pornire la rece.

Siwei Shen, vicepreședintele departamentului de inginerie de la Coinbase, a descris rezultatul obținut în producție: „Migrarea la următoarea generație de AgentCore Runtime a redus pornirile la rece ale sesiunilor agenților noștri de la aproape un minut la mai puțin de cinci secunde, chiar și în perioadele de vârf ale traficului. De asemenea, a eliminat întârzierile de pornire mai mari de 30 de secunde, în timp ce volumul săptămânal al agenților noștri s-a mai mult decât dublat.”

Mission Cloud a raportat că o comparație inițială, folosind aceeași sarcină de lucru cu interogări în limbaj natural pentru ambele versiuni ale runtime-ului, a indicat porniri la rece cu 35% mai rapide pentru cererile de inferență, porniri ale verificărilor de stare cu 77% mai rapide și un cost măsurat al runtime-ului per apel cu 17% mai mic. Agentul său preia informații despre proprietăți și vânzări fără ca utilizatorii să fie nevoiți să navigheze prin sisteme de date complexe.

Recuperarea memoriei și facturarea pe baza nivelului de bază

AWS schimbă și modul în care este facturată memoria în perioadele de inactivitate. Runtime-ul recuperează memoria în câteva minute după ce agentul o eliberează și reduce la zero resursele alocate unui agent inactiv; potrivit AWS, agenții cu mai multe ture și pauze firești pot consuma cu până la 68% mai puțină memorie per sesiune. Astfel se rezolvă problema modelului anterior, care factura alocarea maximă de memorie a sesiunii chiar și după ce memoria nu mai era folosită.

Pentru agenții care funcționează permanent, tariful bazat pe un nivel de bază angajat stabilește un nivel de memorie per sesiune, facturat ca valoare minimă, și permite creșteri la cerere de până la de patru ori față de acest nivel. AWS descrie tariful previzibil rezultat pentru sarcinile de lucru constante ca fiind echivalent cu tarifele AWS Lambda MicroVM; tarifarea în funcție de consum rămâne disponibilă pentru sarcinile de lucru cu variații bruște și pentru cele care pot ajunge la zero.

Zuora a raportat că, în multe cazuri de utilizare, noul runtime a redus cu aproximativ 60% amprenta de memorie per invocare, gestionând în același timp un volum mai mare de trafic cu o latență constantă.

Stocare, izolare și limite de implementare

Fiecare sesiune continuă să ruleze în propriul microVM Firecracker izolat la nivel hardware, cu identitate, politică de acces și pistă de audit proprii. Agenții pot acum să monteze dinamic un sistem de fișiere și să salveze acolo rezultatele activității, de exemplu într-un compartiment Amazon S3 cu suport FUSE. Potrivit AWS, datele rămân în limitele de încredere ale sesiunii pe întreaga durată a activității, sub un singur set de măsuri de control, extinzând izolarea dincolo de mediul de calcul.

Disponibilitatea anunțată nu include limitarea folderului de stocare la nivel de sesiune. AWS afirmă că, până la re:Invent, acreditările etichetate pentru sesiune vor asocia fiecare sesiune propriului folder de stocare, oferind un control mai granular asupra funcționalității de montare.

Documentația actuală pentru V2 prezintă și câteva diferențe de implementare. V2 rămâne opțională, deoarece V1 este versiunea implicită, cu excepția cazului în care platformVersion este setat la V2; crearea sau actualizarea unui runtime V2 durează câteva minute, cât timp AWS pregătește instantaneul, iar containerul trebuie să raporteze o stare de funcționare normală prin intermediul propriului său /ping endpoint în decurs de 120 de secunde. Aceste durate de configurare sunt distincte de latența pornirii la rece a sesiunii.

Sesiunile pot persista până la opt ore, dar se încheie după 15 minute de inactivitate, la atingerea limitei de durată sau dacă sesiunea devine instabilă. Starea sesiunii este efemeră, iar încheierea acesteia distruge microVM-ul și curăță memoria.

Lansarea reunește calculul sesiunilor, facturarea memoriei și datele activităților într-un singur model de runtime gestionat. Elementul încă nefinalizat este izolarea granulară a stocării: limitarea stocării la nivel de sesiune este pasul rămas pentru extinderea garanției de izolare a runtime-ului de la execuție la rezultatele activității agenților salvate.