AWS AgentCore Runtime får større sessioner og understøttelse af filsystemmontering

Amazon Web Services udvidede den 12. november 2026 sin næste generations Amazon Bedrock AgentCore Runtime med større agentsessioner, fakturering baseret på et bindende grundniveau og dynamisk filsystemmontering. AWS oplyser, at opdateringerne giver op til 15 gange hurtigere sessionsstart, samtidig med at hardwareisoleringen bevares.

Den opdaterede runtime er tilgængelig i AWS-regioner i Nordamerika, Sydamerika, Europa og Asien og Stillehavsområdet. AgentCore Runtime er det administrerede beregningslag i AgentCore, AWS’ platform til at bygge agenter med forskellige frameworks og modeller; den bredere platform omfatter også godkendelse, adgangskontrol og observerbarhed.

Udgivelsen følger introduktionen af AgentCore Runtime V2 den 18. september 2026, som indførte snapshotbaseret opstart og frigivelse af hukommelse. AWS havde dengang annonceret, at større kapacitet til beregning og lagring samt priser baseret på et bindende grundniveau ville komme senere; disse funktioner udgør nu en stor del af opdateringen sammen med filsystemmontering.

Større sessioner uden puljer af forvarmede instanser

Hver session kan nu bruge op til 8 vCPU’er og 32 GB hukommelse og understøtte containeraftryk på op til 10 GB. AWS oplyser, at det er fire gange så stor beregningskapacitet som i den tidligere version, og at sessioner starter på under to sekunder uanset aftrykkets størrelse eller samtidigheden. Dermed er der ikke længere behov for kundestyrede puljer af forvarmede instanser eller forhåndskonfigurerede klynger for at håndtere kolde starter.

Opstarten sker ved at gendanne et snapshot i stedet for at gentage initialiseringen. AgentCore klargør én gang et velfungerende containermiljø, registrerer dets initialiserede tilstand og gendanner dette snapshot for hver ny instans. Dermed gentages opgaver som indlæsning af modelartefakter og hentning af statisk konfiguration ikke ved hver kold start.

Siwei Shen, teknisk direktør hos Coinbase, beskrev resultatet i produktion således: »Overgangen til den næste generation af AgentCore Runtime reducerede vores agentsessioners kolde starter fra næsten et minut til under fem sekunder, selv under spidsbelastning. Den fjernede også opstartsforsinkelser på over 30 sekunder, samtidig med at vores ugentlige agentvolumen mere end fordobledes.«

Mission Cloud oplyste, at en indledende sammenligning af den samme arbejdsbelastning med forespørgsler på naturligt sprog i begge runtimeversioner gav 35 % hurtigere kolde starter for inferensanmodninger, 77 % hurtigere opstart af sundhedstjek og 17 % lavere målt runtimeomkostning pr. kald. Agenten henter oplysninger om ejendomme og salg, uden at brugerne behøver at navigere i komplekse datasystemer.

Frigivelse af hukommelse og fakturering efter grundniveau

AWS ændrer også, hvordan der faktureres for hukommelse i perioder uden aktivitet. Runtimen frigiver hukommelsen inden for få minutter, efter at en agent har frigivet den, og skalerer en inaktiv agent ned til nul. AWS oplyser, at agenter med flere samtalerunder og naturlige pauser kan bruge op til 68 % mindre hukommelse pr. session. Det afhjælper den tidligere models tendens til at fakturere efter sessionens maksimale allokering, selv efter at hukommelsen ikke længere var i brug.

For agenter, der altid er aktive, fastsætter priser baseret på et bindende grundniveau en hukommelsesbaseline pr. session, som faktureres som et minimum, og giver mulighed for efter behov at øge forbruget til fire gange dette niveau. AWS beskriver den forudsigelige pris for stabile arbejdsbelastninger som svarende til priserne for AWS Lambda MicroVM; for arbejdsbelastninger med store udsving og skalering helt ned til nul gælder fortsat forbrugsbaseret prissætning.

Zuora oplyste, at den nye runtime i mange anvendelsestilfælde reducerede hukommelsesforbruget pr. påkaldelse med omkring 60 %, samtidig med at den håndterede mere trafik med stabil latenstid.

Lagring, isolering og begrænsninger ved udrulning

Hver session kører fortsat i sin egen hardwareisolerede Firecracker-mikro-VM med sin egen identitet, adgangspolitik og revisionslog. Agenter kan nu dynamisk montere et filsystem og gemme arbejde på det, for eksempel i en Amazon S3-bucket med FUSE-understøttelse. AWS oplyser, at dataene forbliver inden for sessionens tillidsgrænse under hele jobbet og er underlagt ét sæt kontroller, hvilket udvider isoleringen til også at omfatte mere end selve beregningsmiljøet.

Afgrænsning af lagringsmapper pr. session er ikke en del af den annoncerede tilgængelighed. AWS oplyser, at legitimationsoplysninger mærket med sessions-id ved re:Invent vil knytte hver session til sin egen lagringsmappe og dermed føje en mere detaljeret kontrol til monteringsfunktionen.

Der er også forskelle i udrulningen, som beskrevet i den aktuelle V2-dokumentation. V2 skal fortsat tilvælges, fordi V1 er standard, medmindre platformVersion er indstillet til V2; det tager flere minutter at oprette eller opdatere en V2-runtime, mens AWS klargør snapshottet, og containeren skal melde status som sund via sit /ping slutpunkt inden for 120 sekunder. Disse klargøringstider er adskilte fra latenstiden ved kolde sessionsstarter.

Sessioner kan vare i op til otte timer, men afsluttes efter 15 minutters inaktivitet, når den maksimale levetid nås, eller hvis sessionen ikke er sund. Sessionstilstanden er flygtig, og når sessionen afsluttes, destrueres mikro-VM’en, og hukommelsen renses.

Udgivelsen samler sessionsbaseret beregning, fakturering for hukommelse og jobdata i én administreret runtime-model. Det udestående punkt er detaljeret isolering af lagring: afgrænsning af lagring pr. session er det sidste skridt i at udvide runtimens isoleringsgaranti fra selve kørslen til det arbejde, agenter gemmer.