AWS AgentCore Runtime får stöd för större sessioner och montering av filsystem

Amazon Web Services utökade den 12 november 2026 sin nästa generations Amazon Bedrock AgentCore Runtime med större agentsessioner, debitering utifrån en åtagandebaserad basnivå och dynamisk montering av filsystem. Enligt AWS ger uppdateringarna upp till 15 gånger snabbare sessionsstarter samtidigt som maskinvaruisoleringen bibehålls.

Den uppdaterade runtime-miljön är tillgänglig i AWS-regioner i Nordamerika, Sydamerika, Europa och Asien och Stillahavsområdet. AgentCore Runtime är det hanterade beräkningslagret i AgentCore, AWS plattform för att bygga agenter med olika ramverk och modeller. Den bredare plattformen omfattar även autentisering, åtkomstkontroll och observerbarhet.

Uppdateringen följer på introduktionen av AgentCore Runtime V2 den 18 september 2026, som innebar starter baserade på ögonblicksbilder och frigöring av minne. AWS hade då uppgett att större beräkningskapacitet och lagring samt prissättning med åtagandebaserad basnivå skulle bli tillgängliga senare. Dessa funktioner utgör nu en stor del av uppdateringen, tillsammans med montering av filsystem.

Större sessioner utan förberedda resurspooler

Varje session kan nu använda upp till 8 vCPU:er och 32 GB minne samt ha stöd för containeravbildningar på upp till 10 GB. Enligt AWS är det fyra gånger så stor beräkningskapacitet som i den tidigare versionen, och sessioner startar på under två sekunder oavsett avbildningens storlek eller samtidighet. Därmed behövs inte längre kundhanterade resurspooler eller förkonfigurerade kluster för att hantera kalla starter.

Startmekanismen bygger på att ögonblicksbilder återställs i stället för att miljön initieras om varje gång. AgentCore förbereder en fungerande containermiljö en gång, fångar dess initierade tillstånd och återställer sedan ögonblicksbilden för varje ny instans. Därmed behöver sådant som att läsa in modellartefakter och hämta statisk konfiguration inte upprepas vid varje kallstart.

Coinbases tekniska vice vd Siwei Shen beskrev resultatet i produktion: ”När vi migrerade till nästa generation av AgentCore-runtime minskade kallstarterna för våra agentsessioner från nästan en minut till under fem sekunder, även vid hög belastning. Migreringen eliminerade också startfördröjningar på över 30 sekunder, samtidigt som vår veckovolym av agenter mer än fördubblades.”

Mission Cloud uppgav att en inledande jämförelse av samma arbetsbelastning med frågor på naturligt språk i de båda runtime-versionerna visade 35 % snabbare kallstarter för inferensförfrågningar, 77 % snabbare starter för hälsokontroller och 17 % lägre uppmätt runtime-kostnad per anrop. Företagets agent hämtar insikter om fastigheter och försäljning utan att användarna behöver navigera i komplexa datasystem.

Frigöring av minne och basnivådebitering

AWS ändrar också hur minne debiteras under inaktiva perioder. Runtime-miljön frigör minne inom några minuter efter att en agent släppt det och skalar ned en inaktiv agent till noll. Enligt AWS kan agenter med flera turer och naturliga pauser använda upp till 68 % mindre minne per session. Det åtgärdar en nackdel med den tidigare modellen, där debiteringen utgick från sessionens högsta minnesallokering även när minnet inte längre användes.

För agenter som alltid är aktiva fastställer prissättning med åtagandebaserad basnivå en miniminivå för minne per session som debiteras, samtidigt som tillfälliga toppar på upp till fyra gånger den nivån tillåts vid behov. AWS beskriver den förutsägbara kostnaden för jämna arbetsbelastningar som baserad på priserna för AWS Lambda MicroVM. Förbrukningsbaserad prissättning gäller fortfarande för arbetsbelastningar med kraftiga variationer och sådana som skalas ned till noll.

Zuora uppgav att den nya runtime-miljön i många användningsfall minskade minnesåtgången per anrop med omkring 60 %, samtidigt som den hanterade mer trafik med jämn svarstid.

Lagring, isolering och begränsningar vid driftsättning

Varje session körs fortfarande i en egen maskinvaruisolerad Firecracker-mikro-VM, med egen identitet, åtkomstpolicy och granskningslogg. Agenter kan nu dynamiskt montera ett filsystem och spara arbete där, till exempel i en Amazon S3-bucket med FUSE-stöd. AWS uppger att data stannar inom sessionens säkerhetsgräns under hela jobbet och omfattas av en och samma uppsättning kontroller, vilket utvidgar isoleringen bortom beräkningsmiljön.

Möjligheten att begränsa lagringsmappar till enskilda sessioner ingår inte bland de funktioner som nu har meddelats som tillgängliga. AWS uppger att autentiseringsuppgifter märkta med sessionens namn kommer att knyta varje session till en egen lagringsmapp senast till re:Invent, vilket ger mer finkornig kontroll över monteringsfunktionen.

Det finns också skillnader i driftsättningen som beskrivs i den aktuella V2-dokumentationen. V2 måste fortfarande väljas aktivt, eftersom V1 är standardversionen om inte platformVersion är inställt på V2; det tar flera minuter att skapa eller uppdatera en V2-runtime medan AWS förbereder ögonblicksbilden, och containern måste rapportera att den fungerar via sin /ping slutpunkt inom 120 sekunder. Dessa installationstider är åtskilda från sessionsfördröjningen vid kallstart.

Sessioner kan bestå i upp till åtta timmar, men avslutas efter 15 minuters inaktivitet, när tidsgränsen för sessionen nås eller om sessionen inte fungerar som den ska. Sessionsstatusen är tillfällig, och när sessionen avslutas förstörs mikro-VM:en och minnet rensas.

Uppdateringen samlar sessionsberäkning, minnesdebitering och jobbdata i en enda hanterad runtime-modell. Den återstående delen är en mer finkornig lagringsisolering: begränsning av lagring per session är det sista steget för att utvidga runtime-miljöns isoleringsgaranti från körningen till agentens sparade arbete.