AWS überarbeitet Bedrock AgentCore Runtime für elastischen Speicher, schnelle Kaltstarts

Amazon Web Services kündigte das neue AgentCore‑Runtime am 18. September 2026 an, eine überarbeitete Version der verwalteten Compute‑Ebene in Amazon Bedrock AgentCore, von der das Unternehmen sagt, dass sie Speicher zurückgewinnt, sobald Agentensitzungen ihn freigeben, und konsistente Kaltstartzeiten liefert, unabhängig von der Größe des Container‑Images oder der Parallelität.

Das AgentCore‑Runtime ist die verwaltete Compute‑Ebene, die Entwicklern eine vollständig verwaltete Umgebung zum Bereitstellen und Ausführen von Agenten bietet, ohne Infrastruktur aufbauen oder warten zu müssen. AWS sagte, dass seit dem Start tausende Teams es zur Ausführung von Produktions‑Agenten verwendet haben und dass die erste Version eine serverlose Grundlage mit Sitzungsisolierung, Scale‑to‑Zero‑Verhalten und nutzungsbasierter Preisgestaltung geschaffen hat. Dieses Verbrauchsmodell bleibt erhalten: Die Abrechnung folgt dem Ressourcennutzungsgrad, ohne Kosten für Leerlauf‑CPU, die auf I/O wartet, und die Plattform skaliert vollständig auf Null, wenn ein Agent keine Arbeit hat.

Die Probleme, die die Einführung adressiert

Im ursprünglichen Runtime behielt eine Sitzung ihren zugewiesenen Speicher vom Zeitpunkt der Zuweisung bis zum Ende der Sitzung, weil nichts ihn zwischendurch zurückgeholt hat. AWS sagte, dass dies langlaufende oder burstige Agenten dazu zwingt, rund um die Uhr für ihren Höchstverbrauch zu zahlen, lange nachdem der Speicher nicht mehr genutzt wird – ein besonderes Problem für Agenten, die gelegentlich Spitzenwerte erreichen, aber den größten Teil des Tages untätig sind.

Das Startverhalten war die zweite Herausforderung. AWS erklärte, dass eine Sitzung, die auf einer bereits initialisierten Umgebung landet, in weniger als 100 Millisekunden startet, doch diese Umgebungen warm zu halten, um das zu garantieren, bedeutet, Rechenleistung in Reserve zu halten, sodass die meisten Sitzungen mit einem Kaltstart beginnen, bei dem eine neue Umgebung hochgefahren, das Image geladen und der Agent initialisiert wird, bevor die erste Anfrage verarbeitet wird. Diese Latenz steigt mit der Image‑Größe und der Parallelität und ist bei burstigem Verkehr am schlimmsten, wenn die meisten Sitzungen eintreffen und nur wenige fertige Umgebungen verbleiben. Laut AWS haben Kunden beide Probleme umgangen, indem sie Ersatzumgebungen bereitgehalten, die Speicherzuweisung optimiert und die Kapazität reduziert haben, um die Kosten im Griff zu behalten.

Was AWS gemessen hat

Um zu isolieren, welchen Anteil die Plattform selbst zu einem Kaltstart hat, testete AWS einen leeren Echo‑Agent, der seine Eingabe zurückgibt und weder ein Modell noch Werkzeuge aufruft. Ein Python‑Client auf einer Amazon‑EC2‑Instanz in us-west-2 rief Agenten in us-east-1 über das öffentliche Internet ohne VPC‑Peering mittels des boto3‑SDK auf, sodass jede Messung auf Client‑Seite die Rundreise zwischen den beiden AWS‑Regionen zusätzlich zur eigenen Startzeit der Plattform umfasst. Das Unternehmen sendete 5 000 kalte Aufrufe pro Agent über beide Runtime‑Versionen und fünf Image‑Größen hinweg, innerhalb der Standard‑Kontingente.

Auf diese Weise gemessen berichtete AWS, dass das neue Runtime bei einem P75‑Kaltstart‑Latenzwert von etwa 2 Sekunden von einem 200‑MB‑Image bis zu 2 GB lieferte, da die Image‑Größe keinen Einfluss darauf hat, während die Latenz des ursprünglichen Runtime mit der Image‑Größe von etwa 5,4 Sekunden auf fast 30 Sekunden anstieg. Im Echo‑Test lief der eigene Code des Agenten bei P75 in etwa 34 Millisekunden, sodass nahezu die gesamte gemessene Zeit auf die Plattform‑Startzeit entfiel. AWS empfiehlt, die Startzeit für interaktive Agenten zu verbergen, indem die Sitzung bereits beim ersten Nutzer‑Engagement gestartet wird, etwa wenn ein Chat geöffnet wird, sodass die Umgebung während der Eingabe der ersten Anfrage aufgewärmt wird.

Wie das neue Runtime funktioniert

Das neue Runtime startet jede Sitzung mit einem kleinen Speicherprofil statt mit einem vollständig bereitgestellten Footprint und weist bei Bedarf zusätzlichen Speicher zu, sobald die Arbeitslast ihn berührt. Wenn ein Agent pro‑Anfrage‑Puffer freigibt oder zwischengespeicherte Daten zwischen den Anfragen verfallen lässt, nimmt die Plattform den Speicher zurück, anstatt ihn bis zum Sitzungsende belegt zu lassen. AWS sagte, dass es das Rückgewinnungsverhalten anhand einer Analyse von Zuweisungsmustern über Milliarden von Sitzungen abgestimmt hat.

Kaltstarts ändern sich, weil jeder Agent einmal geladen wird und dann aus einem Snapshot läuft. Wenn ein Runtime erstellt oder aktualisiert wird, startet AgentCore den Container, wartet darauf, dass er als gesund meldet, und erstellt einen Snapshot der laufenden Umgebung, sodass einmalige Initialisierungen wie das Laden von Modelldateien und das Abrufen statischer Konfiguration bereits erledigt sind. Jede neue Instanz stellt diesen Snapshot wieder her, anstatt von Grund auf neu zu initialisieren. AWS sagte, das Runtime entfernt Caches und flüchtigen Speicher aus dem Snapshot, sodass seine Größe trotz wachsendem Container‑Image weitgehend konstant bleibt, was die Wiederherstellungs‑Latenz über ein breites Spektrum von Image‑Größen stabil hält.

Die Abrechnung ändert sich mit dem Speichermodell. Das neue Runtime berechnet den Speicher, den ein Agent aktiv nutzt, bei Bedarf geladen und bei Leerlauf zurückgewonnen, anstatt den gesamten Container‑Image‑Speicher für die gesamte Sitzungsdauer zu halten. AWS charakterisierte die Änderung als höheren Tarif, der auf deutlich weniger GB‑Stunden angewendet wird, und sagte, dass für die meisten Agenten der Speicherbedarf stärker sinkt, als der Tarif steigt, sodass die Rechnung geringer ausfällt.

Plattform‑Versionen, Regionen und Grenzen

Entwickler aktivieren das neue Runtime, indem sie beim Erstellen oder Aktualisieren eines Runtime das Feld platformVersion auf V2 setzen, gemäß dem AgentCore‑Entwicklerhandbuch. V1 ist die Vorgabe: Wird das Feld bei der Erstellung weggelassen, entsteht ein V1‑Runtime, und wird es bei einem Update weggelassen, bleibt die aktuelle Plattform‑Version des Runtime erhalten. V2 ist in us-east-1, us-east-2, us-west-2, eu-west-1 und ap-northeast-1 verfügbar.

Da ein V2‑Erstellen‑ oder -Update‑Vorgang die Umgebung vorbereitet und einen Snapshot erstellt, dauern diese Vorgänge mehrere Minuten, bis die Runtime den Status READY erreicht, während eine V1‑Runtime in Sekunden bereit ist. AgentCore nimmt den Snapshot beim ersten gesunden Antwortsignal vom /ping‑Endpunkt des Containers, und wenn der Container innerhalb von 120 Sekunden nach dem Start nicht als gesund gemeldet wird, schlägt die Erstellung mit einem Health‑Check‑Fehler fehl. Der Leitfaden weist außerdem darauf hin, dass V2 derzeit die Gesamtsumme der Umgebungsvariablen auf 1,5 KB für direkte Code‑Deployments und 2,5 KB für Container‑Agents begrenzt, verglichen mit 4 KB bei V1, und dass AWS CloudFormation sowie das AWS CDK aktuell keine Einstellung von platformVersion unterstützen.

Snapshots folgen den Versionen und Endpunkten der Runtime, anstatt direkt verwaltet zu werden. AgentCore erstellt einen Snapshot, wenn ein Endpunkt auf eine Version verweist, und löscht ihn, wenn kein Endpunkt mehr darauf zeigt; das Löschen kann bis zu 8 Stunden dauern, die maximale Sitzungsdauer, weil bereits laufende Sitzungen auf dem Snapshot weiterlaufen, bis sie beendet sind. Sitzungen laufen in dedizierten Micro‑VMs mit isolierten CPU‑, Speicher‑ und Dateisystem‑Ressourcen, bleiben bis zu 8 Stunden aktiv und werden nach 15 Minuten Inaktivität beendet, woraufhin die Micro‑VM terminiert und der Speicher bereinigt wird.

Roadmap und Einstieg

Über den Launch hinaus hat AWS mehrere weitere Funktionen angekündigt: verpflichtende Basisrabatte, die pro Sitzung einen Speicher‑Floor reservieren und bei Bedarf On‑Demand‑Bursting darüber zulassen, ausgerichtet auf dauerhaft aktive Sitzungen; mehr RAM, vCPU und Sitzungs‑Speicher; Unterstützung für x86‑Micro‑VMs; Suspend‑und‑Resume‑Funktionen mit Speicher‑Snapshotting plus Runtime‑Hooks zum Serialisieren des Zustands, bevor eine aktive Sitzung beendet wird; sowie Sitzungs‑Kontext‑Schlüssel, die jeder Sitzung eine abgegrenzte Identität für unbeaufsichtigte Agents verleihen.

AWS verwies Entwickler auf das AgentCore Developer Guide, das AgentCore‑Samples‑Repository auf GitHub und ein begleitendes Load‑Test‑Beispiel, das die Kaltstart‑Latenz der neuen Runtime im eigenen AWS‑Konto des Nutzers demonstriert.