AWS omarbejder Bedrock AgentCore-runtime for elastisk hukommelse, hurtige koldstarter

Amazon Web Services annoncerede den nye AgentCore-runtime den 18. september 2026, en omarbejdet version af det administrerede beregningslag i Amazon Bedrock AgentCore, som virksomheden siger genvinder hukommelse, når agentsessioner frigiver den, og leverer konsistente koldstarttider uanset containerbilledets størrelse eller samtidighed.

AgentCore-runtime er det administrerede beregningslag, der giver udviklere et fuldt administreret miljø til at implementere og køre agenter uden at skulle bygge eller vedligeholde infrastruktur. AWS oplyser, at tusindvis af teams har brugt den til at køre produktionsagenter siden lanceringen, og at den første version etablerede et serverløst grundlag med sessionsisolering, skalerings‑til‑nul‑adfærd og betaling pr. brug. Denne forbrugsmodel videreføres: fakturering følger ressourceforbruget uden omkostning for inaktiv CPU, der venter på I/O, og platformen skalerer helt ned til nul, når en agent ikke har noget arbejde.

Problemerne, som lanceringen adresserer

I den oprindelige runtime holdt en session sin tildelte hukommelse fra allokeringsøjeblikket indtil sessionen sluttede, fordi intet genvandt den undervejs. AWS sagde, at dette betød, at lang‑kørende eller burst‑agtige agenter betalte for deres højeste forbrug døgnet rundt, længe efter hukommelsen ikke længere blev brugt – et særligt problem for agenter, der kun har spidsbelastninger lejlighedsvis, men som ellers er inaktive størstedelen af dagen.

Opstartsadfærden var den anden udfordring. AWS sagde, at en session, der lander i et allerede initialiseret miljø, starter på under 100 millisekunder, men at holde miljøer varme nok til at garantere dette betyder, at beregning holdes i reserve, så de fleste sessioner begynder med en koldstart, der starter et nyt miljø, henter billedet og initialiserer agenten, før den første anmodning behandles. Denne latenstid vokser med billedstørrelse og samtidighed og er værst under burst‑trafik, når flest sessioner ankommer, og færrest klar‑miljøer er tilgængelige. Ifølge AWS har kunder omgået begge problemer ved at holde ekstra miljøer klar, optimere hukommelsesallokering og reducere kapaciteten for at holde omkostningerne i skak.

Hvad AWS målte

For at isolere, hvad platformen selv tilføjer til en koldstart, testede AWS en tom echo‑agent, der returnerer sit input og ikke kalder nogen model eller værktøjer. En Python‑klient på en Amazon EC2‑instans i us-west-2 kaldte agenter i us-east-1 over det offentlige internet uden VPC‑peering, ved brug af boto3‑SDK’en, så hver måling på klientsiden inkluderer round‑trip‑tiden mellem de to AWS‑regioner ud over platformens egen starttid. Virksomheden sendte 5.000 kold‑opkald pr. agent på tværs af begge runtime‑versioner og fem billedstørrelser, inden for standardkontokvoter.

Målt på den måde rapporterede AWS, at den nye runtime leverede en P75‑koldstartlatens på omkring 2 sekunder fra et 200 MB‑billede op til 2 GB, fordi billedstørrelsen ikke påvirker den, mens den oprindelige runtimes latenstid steg med billedstørrelsen fra cirka 5,4 sekunder til næsten 30 sekunder. I echo‑testen kørte agentens egen kode på omkring 34 millisekunder ved P75, så næsten hele den målte tid var platformens starttid. AWS foreslår at skjule starttiden for interaktive agenter ved at starte sessionen så snart en bruger engagerer sig, f.eks. når de åbner en chat, så miljøet varmes op mens de skriver den første anmodning.

Sådan fungerer den nye runtime

Den nye runtime starter hver session fra en lille hukommelsesprofil i stedet for et fuldt provisioneret fodaftryk, og allokerer derefter yderligere hukommelse efter behov, efterhånden som arbejdsbelastningen berører den. Når en agent frigiver buffer‑per‑anmodning eller lader cachede data udløbe mellem anmodninger, tager platformen hukommelsen tilbage i stedet for at lade den forblive tildelt indtil sessionen slutter. AWS oplyser, at de finjusterede genvindingsadfærden baseret på en analyse af allokeringsmønstre på tværs af milliarder af sessioner.

Koldstarts ændrer sig, fordi hver agent indlæses én gang og derefter kører fra et snapshot. Når en runtime oprettes eller opdateres, starter AgentCore containeren, venter på, at den rapporterer sund, og optager et snapshot af det kørende miljø, så engangsinitialisering som indlæsning af modelartefakter og hentning af statisk konfiguration allerede er udført. Hver ny instans gendanner dette snapshot i stedet for at initialisere fra bunden. AWS sagde, at runtimen fjerner caches og midlertidig hukommelse fra snapshotet, så størrelsen forbliver omtrent konstant, selvom containerbilledet vokser, hvilket holder gendannelseslatensen stabil på tværs af et bredt udvalg af billedstørrelser.

Faktureringen ændres med hukommelsesmodellen. Den nye runtime opkræver for den hukommelse, en agent aktivt bruger, indlæst efter behov og genvundet, når den er inaktiv, i stedet for at holde hele containerbilledet i hukommelsen i hele sessionens levetid. AWS karakteriserede ændringen som en højere sats anvendt på langt færre GB‑timer, og sagde, at for de fleste agenter falder fodaftrykket mere, end satsen stiger, så regningen går ned.

Platformversioner, regioner og grænser

Udviklere aktiverer den nye runtime ved at sætte platformVersion‑feltet til V2, når de opretter eller opdaterer en runtime, ifølge AgentCore-udviklervejledning. V1 er standard: udeladelse af feltet ved oprettelse giver en V1‑runtime, og udeladelse ved en opdatering bevarer runtime’ens nuværende platformversion. V2 er tilgængelig i us-east-1, us-east-2, us-west-2, eu-west-1 og ap-northeast-1.

Denne V2‑oprettelse eller -opdatering forbereder og tager et snapshot af miljøet, så disse handlinger kører i flere minutter, før runtime når READY, mens en V1‑runtime bliver klar på få sekunder. AgentCore tager snapshot ved den første sunde respons fra containerens /ping‑endpoint, og hvis containeren ikke rapporterer sund inden 120 sekunder efter opstart, fejler oprettelsen med en sundhedstjek‑fejl. Guiden angiver også, at V2 i øjeblikket begrænser den samlede størrelse af miljøvariabler til 1,5 KB for direkte kodeimplementeringer og 2,5 KB for containeragenter, sammenlignet med 4 KB på V1, og at AWS CloudFormation og AWS CDK endnu ikke understøtter indstilling af platformVersion.

Snapshots følger runtimes versioner og endpoints i stedet for at blive administreret direkte. AgentCore forbereder et snapshot, når et endpoint peger på en version, og sletter et, når intet endpoint peger på det, og sletning kan tage op til 8 timer, den maksimale sessionslevetid, fordi sessioner, der allerede kører på snapshot’et, fortsætter, indtil de afsluttes. Sessioner kører i dedikerede microVM’er med isolerede CPU‑, hukommelses‑ og filsystemressourcer, kan vedvare i op til 8 timer og afsluttes efter 15 minutters inaktivitet, hvorefter microVM’en termineres og hukommelsen saniteres.

Roadmap og kom i gang

Ud over lanceringen har AWS oplyst flere funktioner på vej: forpligtende grundlæggende rabatter, der reserverer et mindste hukommelsesniveau pr. session med on‑demand burst ud over dette, rettet mod stabile, altid‑aktive sessioner; større RAM, vCPU og sessionslager; x86 microVM‑understøttelse; suspendér‑og‑genoptag med hukommelsessnapshotting plus runtime‑hooks til serialisering af tilstand før en aktiv session afsluttes; og sessionskontekstnøgler, der giver hver session en scoped identitet for uovervågede agenter.

AWS henviser udviklere til AgentCore Developer Guide, AgentCore‑samples‑repository på GitHub og et tilhørende belastningstest‑eksempel, der demonstrerer den nye runtimes kolde start‑latens i en brugers egen AWS‑konto.