AWS redesigner Bedrock AgentCore Runtime for elastisk minne og raske kaldstarter

Amazon Web Services kunngjorde den nye AgentCore-runtime den 18. september 2026, en omarbeidet versjon av det administrerte beregningslaget i Amazon Bedrock AgentCore som selskapet sier gjenvinner minne når agentsesjoner frigir det og leverer konsistente kaldstarttider uavhengig av containerbilde‑størrelse eller samtidighet.

AgentCore-runtime er det administrerte beregningslaget som gir utviklere et fullt administrert miljø for å distribuere og kjøre agenter uten å bygge eller vedlikeholde infrastruktur. AWS oppga at tusenvis av team har brukt den til å kjøre produksjonsagenter siden lanseringen, og at den første versjonen etablerte et serverløst grunnlag med sesjonsisolasjon, skaler‑til‑null‑adferd og betalings‑etter‑bruk‑priser. Denne forbruksmodellen videreføres: fakturering følger ressursbruk uten kostnad for inaktiv CPU som venter på I/O, og plattformen skalerer helt ned til null når en agent ikke har arbeid.

Problemene lanseringen adresserer

I den opprinnelige runtime holdt en sesjon sin tildelte minne fra øyeblikket minnet ble tildelt til sesjonen avsluttet, fordi ingenting gjenvant det underveis. AWS sa at dette førte til at langvarige eller burst‑agenter betalte for sitt høyeste minneforbruk døgnet rundt, lenge etter at minnet hadde sluttet å bli brukt – et spesielt gap for agenter som av og til får en spiss, men som sitter inaktive mesteparten av dagen.

Oppstartsadferd var den andre utfordringen. AWS sa at en sesjon som lander i et allerede initialisert miljø starter på under 100 millisekunder, men å holde miljøer varme nok til å garantere dette innebærer å holde beregning i reserve, så de fleste sesjoner begynner med en kaldstart som starter et nytt miljø, henter bildet og initialiserer agenten før den første forespørselen kjøres. Denne latensen øker med bildestørrelse og samtidighet og er verst under burst‑trafikk, når flest sesjoner ankommer og færrest klare miljøer er igjen. Ifølge AWS løste kunder begge problemene ved å ha reserve‑miljøer klare, optimalisere minnetildeling og redusere kapasiteten for å holde kostnadene i sjakk.

Hva AWS målte

For å isolere hva plattformen selv legger til en kaldstart, testet AWS en tom ekko‑agent som returnerer sin input og ikke kaller noen modell eller verktøy. En Python‑klient på en Amazon EC2‑instans i us-west-2 påkalte agenter i us-east-1 over det offentlige internettet uten VPC‑peering, ved bruk av boto3‑SDK‑en, slik at hver måling på klientsiden inkluderer rundreisen mellom de to AWS‑regionene i tillegg til plattformens egen oppstartstid. Selskapet sendte 5 000 kalde påkallinger per agent over begge runtime‑versjoner og fem bildestørrelser, innenfor standard kontokvoter.

Målt på den måten rapporterte AWS at den nye runtime leverte en P75‑kaldstartlatens på omtrent 2 sekunder fra et 200 MB‑bilde opp til 2 GB, fordi bildestørrelse ikke påvirker den, mens den opprinnelige runtime‑latensen økte med bildestørrelse fra omtrent 5,4 sekunder til nesten 30 sekunder. I ekko‑testen kjørte agentens egen kode på omtrent 34 millisekunder ved P75, så nesten all målt tid var plattformens oppstartstid. AWS foreslår å skjule oppstartstiden for interaktive agenter ved å starte sesjonen så snart en bruker engasjerer seg, for eksempel når de åpner en chat, slik at miljøet varmes opp mens de skriver den første forespørselen.

Hvordan den nye runtime fungerer

Den nye runtime starter hver sesjon fra en liten minneprofil i stedet for et fullt provisionert fotavtrykk, og allokerer og laster inn ekstra minne på forespørsel etter hvert som arbeidsbelastningen berører det. Når en agent frigir per‑forespørsel‑buffere eller lar hurtiglagrede data utløpe mellom forespørsler, tar plattformen minnet tilbake i stedet for å la det forbli reservert til sesjonen avsluttes. AWS oppga at de finjusterte gjenvinningsadferden basert på en analyse av allokeringsmønstre på tvers av milliarder av sesjoner.

Kaldstarter endres fordi hver agent lastes én gang og deretter kjører fra et øyeblikksbilde. Når en runtime opprettes eller oppdateres, starter AgentCore containeren, venter på at den rapporterer helsetilstand, og tar et øyeblikksbilde av det kjørende miljøet, slik at engangsinitiering som lasting av modell‑artefakter og henting av statisk konfigurasjon allerede er gjort. Hver ny instans gjenoppretter dette øyeblikksbildet i stedet for å initialisere fra bunnen av. AWS sa at runtime fjerner cache‑ og midlertidig minne fra øyeblikksbildet slik at størrelsen forblir omtrent konstant etter hvert som container‑bildet vokser, noe som holder gjenopprettingslatensen jevn over et bredt spekter av bildestørrelser.

Faktureringen endres med minnemodellen. Den nye runtime tar betalt for minnet en agent aktivt bruker, lastet på forespørsel og gjenvunnet når den er inaktiv, i stedet for å holde hele container‑bildet i minnet gjennom hele sesjonens levetid. AWS beskrev endringen som en høyere sats anvendt på langt færre GB‑timer, og sa at for de fleste agenter faller fotavtrykket mer enn satsen øker, slik at regningen blir lavere.

Plattformversjoner, regioner og begrensninger

Utviklere slår på den nye runtime ved å sette feltet platformVersion til V2 når du oppretter eller oppdaterer en runtime, i henhold til AgentCore-utviklerguide. V1 er standard: å utelate feltet ved opprettelse gir en V1-runtime, og å utelate det ved oppdatering beholder runtime‑ens nåværende plattformversjon. V2 er tilgjengelig i us-east-1, us-east-2, us-west-2, eu-west-1 og ap-northeast-1.

Fordi en V2‑opprettelse eller -oppdatering forbereder og tar et øyeblikksbilde av miljøet, tar disse operasjonene flere minutter før kjøretiden når READY, mens en V1‑kjøretid blir klar på sekunder. AgentCore tar øyeblikksbildet ved den første sunne responsen fra containerens /ping‑endepunkt, og hvis containeren ikke rapporterer sunn innen 120 sekunder etter oppstart, mislykkes opprettelsen med en helsesjekk‑feil. Veiledningen oppgir også at V2 for tiden begrenser total størrelse på miljøvariabler til 1,5 KB for direkte kode‑distribusjoner og 2,5 KB for container‑agenter, sammenlignet med 4 KB på V1, og at AWS CloudFormation og AWS CDK foreløpig ikke støtter innstilling av platformVersion.

Øyeblikksbilder følger kjøretidens versjoner og endepunkter i stedet for å bli administrert direkte. AgentCore forbereder et øyeblikksbilde når et endepunkt peker på en versjon, og sletter et øyeblikksbilde når ingen endepunkt peker på det, og sletting kan ta opptil 8 timer, den maksimale øktlevetiden, fordi økter som allerede kjører på øyeblikksbildet fortsetter til de avsluttes. Økter kjører i dedikerte microVM‑er med isolerte CPU‑, minne‑ og filsystemressurser, vedvarer i opptil 8 timer, og termineres etter 15 minutters inaktivitet, hvoretter microVM‑en avsluttes og minnet renses.

Veikart og komme i gang

Utover lanseringen listet AWS opp flere funksjoner som er på vei: forpliktede basisrabatter som reserverer et minnegulv per økt med on‑demand‑bursting over dette, rettet mot stabile, alltid‑aktive økter; større RAM, vCPU og øktlagring; støtte for x86‑microVM; suspend‑og‑resume med minne‑øyeblikksbilder pluss kjøretids‑hooks for serialisering av tilstand før en aktiv økt avsluttes; og økt‑kontekstnøkler som gir hver økt en avgrenset identitet for ubemannede agenter.

AWS henviste utviklere til AgentCore Developer Guide, AgentCore‑prøve‑repoet på GitHub, og et tilhørende lastetest‑eksempel som demonstrerer den nye kjøretidens kaldstart‑latens i en brukers egen AWS‑konto.