AWS werkt Bedrock AgentCore-runtime opnieuw voor elastisch geheugen, snelle koude starts

Amazon Web Services aankondigde de nieuwe AgentCore-runtime op 18 september 2026, een opnieuw ontworpen versie van de beheerde rekentlaag in Amazon Bedrock AgentCore die, volgens het bedrijf, geheugen terugvordert zodra agentsessies het vrijgeven en consistente koude‑starttijden levert, ongeacht de grootte van de container‑image of de gelijktijdigheid.

AgentCore-runtime is de beheerde rekentlaag die ontwikkelaars een volledig beheerde omgeving biedt om agents te implementeren en uit te voeren zonder infrastructuur te bouwen of te onderhouden. AWS meldde dat duizenden teams het sinds de lancering hebben gebruikt om productie‑agents uit te voeren, en dat de eerste versie een serverless‑basis legde met sessie‑isolatie, schaal‑naar‑nul‑gedrag en pay‑per‑use‑tarief. Dat consumptiemodel blijft bestaan: facturering volgt het resource‑gebruik zonder kosten voor een idle CPU die wacht op I/O, en het platform schaalt volledig naar nul wanneer een agent geen werk heeft.

De problemen die de lancering aanpakt

In de oorspronkelijke runtime hield een sessie zijn toegewezen geheugen vast vanaf het moment van toewijzing tot het einde van de sessie, omdat er niets was dat het onderweg terugvorderde. AWS meldde dat dit lange‑lopende of burst‑agents betaalde voor hun piekgeheugen de hele dag door, lang nadat het geheugen niet meer werd gebruikt, een specifiek gat voor agents die af en toe een piek vertonen maar het grootste deel van de dag idle zijn.

Opstartgedrag was de tweede uitdaging. AWS meldde dat een sessie die op een al geïnitialiseerde omgeving terechtkomt, in minder dan 100 milliseconden start, maar om omgevingen voldoende warm te houden om dat te garanderen, moet rekenkracht in reserve worden gehouden, waardoor de meeste sessies beginnen met een koude start die een verse omgeving opstart, de image ophaalt en de agent initialiseert voordat het eerste verzoek wordt verwerkt. Die latentie neemt toe met de grootte van de image en de gelijktijdigheid en is het hoogst bij burst‑verkeer, wanneer de meeste sessies binnenkomen en de minste klaar‑omgevingen overblijven. Volgens AWS omzeilden klanten beide problemen door spare omgevingen gereed te houden, geheugenallocatie te optimaliseren en capaciteit te verminderen om de kosten onder controle te houden.

Wat AWS heeft gemeten

Om te isoleren wat het platform zelf toevoegt aan een koude start, testte AWS een lege echo‑agent die zijn invoer retourneert en geen model of tools aanroept. Een Python‑client op een Amazon EC2‑instance in us-west-2 riep agents in us-east-1 op via het openbare internet zonder VPC‑peering, met behulp van de boto3‑SDK, zodat elke client‑zijde meting de round‑trip tussen de twee AWS‑regio’s omvat naast de eigen starttijd van het platform. Het bedrijf stuurde 5,000 koude oproepen per agent over beide runtime‑versies en vijf image‑groottes, binnen de standaard account‑quota.

Op die manier gemeten meldde AWS dat de nieuwe runtime een P75‑koude‑startlatentie van ongeveer 2 seconden leverde van een 200 MB‑image tot 2 GB, omdat de grootte van de image hier geen invloed op heeft, terwijl de latentie van de oorspronkelijke runtime toenam met de image‑grootte van ongeveer 5,4 seconden tot bijna 30 seconden. In de echo‑test draaide de eigen code van de agent in ongeveer 34 milliseconden bij P75, dus bijna alle gemeten tijd was platform‑starttijd. AWS suggereert de starttijd te verbergen voor interactieve agents door de sessie te starten zodra een gebruiker interacteert, bijvoorbeeld wanneer hij een chat opent, zodat de omgeving opwarmt terwijl hij het eerste verzoek typt.

Hoe de nieuwe runtime werkt

De nieuwe runtime start elke sessie vanuit een klein geheugenprofiel in plaats van een volledig geprovisioneerde footprint, en allocateert vervolgens extra geheugen op aanvraag wanneer de workload het nodig heeft. Wanneer een agent per‑request buffers vrijgeeft of cached data laat verlopen tussen verzoeken, neemt het platform het geheugen terug in plaats van het geclaimd te laten tot het einde van de sessie. AWS meldde dat het het terugvorderingsgedrag heeft afgestemd op basis van een analyse van allocatiepatronen over miljarden sessies.

Koude starts veranderen omdat elke agent één keer laadt en daarna draait vanaf een snapshot. Wanneer een runtime wordt gecreëerd of bijgewerkt, start AgentCore de container, wacht tot deze gezond meldt, en maakt een snapshot van de draaiende omgeving, zodat eenmalige initialisatie zoals het laden van model‑artefacten en het ophalen van statische configuratie al voltooid is. Elke nieuwe instantie herstelt die snapshot in plaats van van nul te initialiseren. AWS meldde dat de runtime caches en tijdelijk geheugen uit de snapshot verwijdert zodat de grootte ongeveer constant blijft naarmate de container‑image groeit, wat de hersteltijd stabiel houdt over een breed scala aan image‑groottes.

Facturering verschuift met het geheugenmodel. De nieuwe runtime rekent voor het geheugen dat een agent actief gebruikt, on‑demand geladen en teruggeëist wanneer idle, in plaats van voor het vasthouden van de volledige container‑image in het geheugen gedurende de levensduur van een sessie. AWS karakteriseerde de wijziging als een hoger tarief toegepast op veel minder GB‑uren, en meldde dat voor de meeste agents de footprint meer daalt dan het tarief stijgt, waardoor de rekening lager uitvalt.

Platformversies, regio’s en limieten

Ontwikkelaars schakelen de nieuwe runtime in door het platformVersion‑veld op V2 te zetten bij het creëren of bijwerken van een runtime, volgens de AgentCore-ontwikkelaarsgids. V1 is de standaard: het weglaten van het veld bij creatie resulteert in een V1‑runtime, en het weglaten bij een update behoudt de huidige platformversie van de runtime. V2 is beschikbaar in us-east-1, us-east-2, us-west-2, eu-west-1 en ap-northeast-1.

Omdat een V2‑creatie of -update de omgeving voorbereidt en een snapshot maakt, duren die bewerkingen enkele minuten voordat de runtime READY is, terwijl een V1‑runtime binnen enkele seconden klaar is. AgentCore maakt de snapshot bij de eerste gezonde respons van de /ping‑endpoint van de container, en als de container binnen 120 seconden na het opstarten geen gezonde status meldt, mislukt de creatie met een health‑check‑fout. De gids vermeldt ook dat V2 momenteel de totale grootte van omgevingsvariabelen beperkt tot 1,5 KB voor directe code‑implementaties en 2,5 KB voor container‑agents, vergeleken met 4 KB bij V1, en dat AWS CloudFormation en de AWS CDK momenteel geen ondersteuning bieden voor het instellen van platformVersion.

Snapshots volgen de versies en eindpunten van de runtime in plaats van direct beheerd te worden. AgentCore bereidt een snapshot voor wanneer een eindpunt naar een versie wijst en verwijdert er één wanneer geen eindpunt ernaar wijst, en het verwijderen kan tot 8 uur duren, de maximale sessieduur, omdat sessies die al op de snapshot draaien doorgaan tot ze eindigen. Sessies draaien in toegewijde micro‑VM’s met geïsoleerde CPU‑, geheugen‑ en bestandssysteem‑bronnen, blijven tot 8 uur bestaan en beëindigen na 15 minuten inactiviteit, waarna de micro‑VM wordt beëindigd en het geheugen wordt gesaniteerd.

Roadmap en Aan de slag

Buiten de lancering heeft AWS verschillende functionaliteiten aangekondigd die onderweg zijn: toegewijde baseline‑kortingen die een geheugen‑minimum per sessie reserveren met on‑demand burst‑capaciteit erboven, gericht op continu actieve sessies; meer RAM, vCPU en sessie‑opslag; ondersteuning voor x86‑micro‑VM’s; pauzeren‑en‑hervatten met geheugen‑snapshotting plus runtime‑hooks voor het serialiseren van de status voordat een actieve sessie wordt beëindigd; en sessie‑context‑sleutels die elke sessie een scoped identiteit geven voor onbeheerde agents.

AWS verwees ontwikkelaars naar de AgentCore Developer Guide, de AgentCore‑samples‑repository op GitHub, en een bijbehorend load‑test‑voorbeeld dat de koude‑start‑latentie van de nieuwe runtime aantoont binnen een eigen AWS‑account van de gebruiker.