AWS AgentCore Runtime biedt grotere sessies en koppelingen met bestandssystemen

Amazon Web Services heeft op 12 november 2026 zijn volgende generatie Amazon Bedrock AgentCore Runtime uitgebreid met grotere agentsessies, facturering op basis van een vastgelegd basisverbruik en dynamische koppelingen met bestandssystemen. Volgens AWS zorgen de updates voor sessiestarts die tot 15 keer sneller zijn, terwijl de hardware-isolatie behouden blijft.

De bijgewerkte runtime is beschikbaar in AWS-regio’s in Noord-Amerika, Zuid-Amerika, Europa en Azië-Pacific. AgentCore Runtime is de beheerde rekenlaag binnen AgentCore, het platform van AWS voor het bouwen van agents met verschillende frameworks en modellen. Het bredere platform omvat ook authenticatie, toegangsbeheer en waarneembaarheid.

De release volgt op de introductie van AgentCore Runtime V2 op 18 september 2026, met starts op basis van momentopnamen en het vrijgeven van geheugen. AWS had toen grotere reken- en opslagcapaciteit en prijzen op basis van vastgelegd basisverbruik aangekondigd als functies die binnenkort beschikbaar zouden komen. Die mogelijkheden vormen nu een groot deel van de update, samen met het koppelen van bestandssystemen.

Grotere sessies zonder vooraf opgewarmde pools

Elke sessie kan nu maximaal 8 vCPU’s en 32 GB geheugen gebruiken en containerimages tot 10 GB ondersteunen. Volgens AWS is dat vier keer zoveel rekenvermogen als in de vorige versie en starten sessies in minder dan twee seconden, ongeacht de imagegrootte of gelijktijdigheid. Daardoor zijn door klanten beheerde vooraf opgewarmde pools of vooraf ingerichte clusters niet meer nodig om koude starts op te vangen.

De opstartmethode is gebaseerd op het herstellen van momentopnamen, niet op herhaalde initialisatie. AgentCore maakt eenmalig een gezonde containeromgeving gereed, legt de geïnitialiseerde toestand vast en herstelt die momentopname voor elke nieuwe instantie. Daardoor hoeven taken zoals het laden van modelartefacten en het ophalen van statische configuratie niet bij elke koude start opnieuw te worden uitgevoerd.

Siwei Shen, vicepresident Engineering bij Coinbase, beschreef het resultaat in productie: “De migratie naar de volgende generatie van AgentCore Runtime heeft de koude starts van onze agentsessies teruggebracht van bijna een minuut tot minder dan vijf seconden, zelfs tijdens piekverkeer. Ook zijn opstartvertragingen van meer dan 30 seconden verdwenen, terwijl ons wekelijkse agentvolume meer dan verdubbelde.”

Mission Cloud meldde dat een eerste vergelijking van dezelfde workload met zoekopdrachten in natuurlijke taal op beide runtimeversies 35% snellere koude starts voor inferentieverzoeken, 77% snellere starts van statuscontroles en 17% lagere gemeten runtimekosten per aanroep opleverde. De agent haalt inzichten over vastgoed en verkoop op zonder dat gebruikers door complexe datasystemen hoeven te navigeren.

Geheugen vrijgeven en facturering op basis van basisverbruik

AWS verandert ook de manier waarop geheugen tijdens inactieve perioden wordt gefactureerd. De runtime geeft het geheugen binnen enkele minuten vrij nadat een agent het heeft losgelaten en schaalt een inactieve agent terug naar nul. Volgens AWS kunnen agents met meerdere beurten en natuurlijke pauzes tot 68% minder geheugen per sessie verbruiken. Daarmee wordt een probleem van het eerdere model aangepakt: dat factureerde op basis van de piektoewijzing van een sessie, ook nadat het geheugen niet meer in gebruik was.

Voor agents die altijd actief zijn, stelt de prijsstelling op basis van vastgelegd basisverbruik per sessie een geheugenbasisniveau vast dat als minimum wordt gefactureerd. Op aanvraag zijn pieken tot vier keer dat niveau mogelijk. AWS beschrijft het voorspelbare tarief dat dit oplevert voor stabiele workloads als gelijk aan de tarieven van AWS Lambda MicroVM. Voor workloads met sterk wisselend verbruik en workloads die naar nul kunnen worden teruggeschaald, blijft facturering op basis van verbruik gelden.

Zuora meldde dat de nieuwe runtime het geheugengebruik per aanroep in veel gebruikssituaties met ongeveer 60% verminderde, terwijl er meer verkeer werd verwerkt met een stabiele latentie.

Opslag, isolatie en implementatiebeperkingen

Elke sessie blijft draaien in een eigen, hardwarematig geïsoleerde Firecracker-microVM, met een eigen identiteit, toegangsbeleid en audittrail. Agents kunnen nu dynamisch een bestandssysteem koppelen en werk opslaan, bijvoorbeeld in een Amazon S3-bucket met FUSE-ondersteuning. Volgens AWS blijven de gegevens gedurende de hele taak binnen de vertrouwensgrens van de sessie, onder één reeks beveiligingsmaatregelen. Zo wordt de isolatie uitgebreid tot buiten de rekenomgeving.

Het afbakenen van opslagmappen per sessie maakt geen deel uit van de aangekondigde beschikbaarheid. AWS zegt dat bij re:Invent inloggegevens met een sessielabel elke sessie aan een eigen opslagmap zullen koppelen, als extra, fijnmaziger controle voor de mogelijkheid om bestandssystemen te koppelen.

Er zijn ook verschillen in de implementatie die worden beschreven in de huidige V2-documentatie. V2 blijft optioneel, omdat V1 de standaard is, tenzij platformVersion is ingesteld op V2; het maken of bijwerken van een V2-runtime duurt enkele minuten terwijl AWS de momentopname voorbereidt, en de container moet binnen 120 seconden via zijn /ping eindpunt als gezond worden gemeld. Deze insteltijden staan los van de latentie van koude starts van sessies.

Sessies kunnen maximaal acht uur actief blijven, maar worden beëindigd na 15 minuten inactiviteit, zodra de maximale looptijd is bereikt of wanneer ze ongezond zijn. De sessiestatus is vluchtig; bij beëindiging worden de microVM vernietigd en het geheugen gewist.

Deze release brengt de rekenkracht voor sessies, de facturering van geheugen en taakgegevens samen in één beheerd runtimemodel. De isolatie van opslag is nog niet volledig fijnmazig: afbakening van opslag per sessie is de laatste stap om de isolatiegarantie van de runtime uit te breiden van de uitvoering naar het opgeslagen werk van agents.