AWS omarbetar Bedrock AgentCore Runtime för elastiskt minne, snabba kallstarter

Amazon Web Services annonserade den nya AgentCore runtime den 18 september 2026, en omarbetad version av det hanterade beräkningslagret i Amazon Bedrock AgentCore som företaget säger återvinner minne när agentsessioner släpper det och levererar konsekventa kallstartstider oavsett storlek på containeravbildning eller samtidighet.

AgentCore runtime är det hanterade beräkningslagret som ger utvecklare en helt hanterad miljö för att distribuera och köra agenter utan att bygga eller underhålla infrastruktur. AWS sade att tusentals team har använt den för att köra produktionsagenter sedan lanseringen, och att den första versionen etablerade en serverlös grund med sessionsisolering, skala‑till‑noll‑beteende och betalning per användning. Den konsumtionsmodellen fortsätter: fakturering följer resursanvändning utan kostnad för inaktiv CPU som väntar på I/O, och plattformen skalar helt ner till noll när en agent inte har något arbete.

Problemen som lanseringen adresserar

I den ursprungliga runtime behöll en session sitt tilldelade minne från det att det allokerades tills sessionen avslutades, eftersom inget återvann det under tiden. AWS sade att detta lämnade långlivade eller burstiga agenter som betalar för sin högsta minnesnivå dygnet runt, långt efter att minnet slutat användas, ett särskilt gap för agenter som ibland får en spik men är inaktiva större delen av dagen.

Uppstarts‑beteendet var den andra utmaningen. AWS sade att en session som hamnar i en redan initierad miljö startar på under 100 millisekunder, men att hålla miljöer tillräckligt varma för att garantera detta innebär att hålla beräkning i reserv, så de flesta sessioner börjar med en kall start som startar en ny miljö, hämtar avbildningen och initierar agenten innan den första begäran körs. Den latensen ökar med avbildningsstorlek och samtidighet och är som värst under burstig trafik, när flest sessioner anländer och få färdiga miljöer finns kvar. Enligt AWS har kunder kringgått båda problemen genom att hålla reservmiljöer redo, optimera minnesallokering och minska kapaciteten för att hålla kostnaderna i schack.

Vad AWS mätte

För att isolera vad plattformen själv lägger till en kall start testade AWS en tom echo‑agent som returnerar sin indata och inte anropar någon modell eller verktyg. En Python‑klient på en Amazon EC2‑instans i us-west-2 anropade agenter i us-east-1 via det offentliga internet utan VPC‑peering, med boto3‑SDK, så varje klient‑sida mätning inkluderar rundresan mellan de två AWS‑regionerna ovanpå plattformens egen starttid. Företaget skickade 5 000 kalla anrop per agent över båda runtime‑versionerna och fem avbildningsstorlekar, inom standardkontokvoter.

Mätt på det sättet rapporterade AWS att den nya runtime levererade en P75‑kallstartlatens på cirka 2 sekunder från en 200 MB‑avbildning upp till 2 GB, eftersom avbildningsstorleken inte påverkar den, medan den ursprungliga runtime‑latensen ökade med avbildningsstorlek från ungefär 5,4 sekunder till nästan 30 sekunder. I echo‑testet kördes agentens egen kod på cirka 34 millisekunder vid P75, så nästan hela den uppmätta tiden var plattformens starttid. AWS föreslår att dölja starttiden för interaktiva agenter genom att påbörja sessionen så snart en användare engagerar sig, till exempel när de öppnar en chatt, så miljön värms upp medan de skriver den första begäran.

Hur den nya runtime‑en fungerar

Den nya runtime‑en startar varje session från en liten minnesprofil snarare än ett fullt provisionerat fotavtryck, och allokerar sedan ytterligare minne på begäran när arbetsbelastningen berör det. När en agent släpper per‑begäran‑buffertar eller låter cachad data gå ut mellan begäranden, tar plattformen tillbaka minnet istället för att låta det förbli reserverat tills sessionen avslutas. AWS sade att de finjusterade återvinningsbeteendet baserat på en analys av allokeringsmönster över miljarder sessioner.

Kallstarter förändras eftersom varje agent laddas en gång och sedan körs från en ögonblicksbild. När en runtime skapas eller uppdateras startar AgentCore containern, väntar på att den rapporterar som frisk och fångar en ögonblicksbild av den körande miljön, så engångsinitiering såsom inläsning av modellartefakter och hämtning av statisk konfiguration redan är klar. Varje ny instans återställer den ögonblicksbilden istället för att initiera från början. AWS sade att runtime‑en tar bort cache och tillfälligt minne från ögonblicksbilden så dess storlek förblir ungefär konstant när containeravbildningen växer, vilket håller återställningslatensen stabil över ett brett spektrum av avbildningsstorlekar.

Faktureringen förändras med minnesmodellen. Den nya runtime‑en debiterar för det minne som en agent aktivt använder, laddat på begäran och återvunnet när det är inaktivt, snarare än för att hålla hela containeravbildningen i minnet under hela sessionens livstid. AWS beskrev förändringen som en högre taxa tillämpad på mycket färre GB‑timmar, och sade att för de flesta agenter minnesavtrycket minskar mer än taxan ökar, så kostnaden sjunker.

Plattforms versioner, regioner och begränsningar

Utvecklare aktiverar den nya runtime‑en genom att sätta fältet platformVersion till V2 när de skapar eller uppdaterar en runtime, enligt AgentCore utvecklardokumentation. V1 är standard: om fältet utelämnas vid skapande får man en V1‑runtime, och om det utelämnas vid en uppdatering behåller runtime‑en sin nuvarande plattformsversion. V2 är tillgänglig i us-east-1, us-east-2, us-west-2, eu-west-1 och ap-northeast-1.

Eftersom en V2‑skapelse eller -uppdatering förbereder och tar en ögonblicksbild av miljön, tar dessa operationer flera minuter innan runtime blir READY, medan en V1‑runtime blir klar på några sekunder. AgentCore tar ögonblicksbilden vid det första friska svaret från containerns /ping‑endpoint, och om containern inte rapporterar friskt inom 120 sekunder efter start misslyckas skapelsen med ett fel för hälsokontrollen. Guiden anger också att V2 för närvarande begränsar den totala storleken på miljövariabler till 1,5 KB för direkta koddistributioner och 2,5 KB för container‑agenter, jämfört med 4 KB på V1, samt att AWS CloudFormation och AWS CDK för närvarande inte stödjer att ange platformVersion.

Ögonblicksbilder följer runtime‑versionerna och endpointarna snarare än att hanteras direkt. AgentCore förbereder en ögonblicksbild när en endpoint pekar på en version och tar bort en när ingen endpoint pekar på den, och borttagning kan ta upp till 8 timmar, den maximala sessionens livstid, eftersom sessioner som redan körs på ögonblicksbilden fortsätter tills de avslutas. Sessioner körs i dedikerade microVM‑ar med isolerade CPU‑, minnes‑ och filsystemresurser, varar i upp till 8 timmar och avslutas efter 15 minuters inaktivitet, varpå microVM‑en termineras och minnet saneras.

Färdplan och kom igång

Utöver lanseringen listade AWS flera funktioner som är på väg: förpliktade grundrabatter som reserverar ett minnesgolv per session med on‑demand‑bursting ovanför, avsedda för ständigt aktiva sessioner; större RAM, vCPU och sessionslagring; stöd för x86‑microVM; suspend‑och‑återuppta med minnes‑ögonblicksbilder samt runtime‑krokar för att serialisera tillstånd innan en aktiv session avslutas; och sessionskontextnycklar som ger varje session en avgränsad identitet för oövervakade agenter.

AWS pekade utvecklare till AgentCore Developer Guide, AgentCore‑exempelförvaret på GitHub och ett medföljande belastningstestexempel som demonstrerar den nya runtime‑ens kallstartslatens i en användares egna AWS‑konto.