KI-Modelle und Plattformen
AWS AgentCore Runtime unterstützt größere Sitzungen und Dateisystemeinbindungen
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Amazon Web Services hat am 12. November 2026 die nächste Generation von Amazon Bedrock AgentCore Runtime um größere Agentensitzungen, eine Abrechnung auf Basis einer verbindlich vereinbarten Grundausstattung und dynamische Dateisystemeinbindungen erweitert. Laut AWS ermöglichen die Neuerungen bis zu 15-mal schnellere Sitzungsstarts bei gleichbleibender Hardwareisolation.
Die aktualisierte Laufzeitumgebung ist in AWS-Regionen in Nordamerika, Südamerika, Europa und im asiatisch-pazifischen Raum verfügbar. AgentCore Runtime ist die verwaltete Rechenebene innerhalb von AgentCore, der AWS-Plattform zum Erstellen von Agenten mit verschiedenen Frameworks und Modellen. Die umfassendere Plattform deckt außerdem Authentifizierung, Zugriffskontrolle und Beobachtbarkeit ab.
Die Veröffentlichung folgt auf die Einführung von AgentCore Runtime V2 am 18. September 2026, die snapshotbasierte Starts und die Freigabe von Speicher eingeführt hatte. AWS hatte damals größere Rechen- und Speicherkapazitäten sowie Preise auf Basis einer verbindlich vereinbarten Grundausstattung als bald verfügbar angekündigt. Diese Funktionen machen nun einen Großteil der Neuerungen aus, ergänzt um die Dateisystemeinbindung.
Größere Sitzungen ohne vorgewärmte Pools
Jede Sitzung kann jetzt bis zu 8 vCPUs und 32 GB Arbeitsspeicher nutzen und Container-Images mit einer Größe von bis zu 10 GB unterstützen. Laut AWS entspricht das der vierfachen Rechenleistung der Vorgängerversion. Sitzungen starten unabhängig von Image-Größe und Parallelität in weniger als zwei Sekunden. Dadurch benötigen Kunden keine selbst verwalteten vorgewärmten Pools oder vorab bereitgestellten Cluster mehr, um Kaltstarts zu vermeiden.
Der Start erfolgt durch die Wiederherstellung eines Snapshots statt durch wiederholte Initialisierung. AgentCore bereitet einmalig eine funktionsfähige Containerumgebung vor, erfasst deren initialisierten Zustand und stellt diesen Snapshot für jede neue Instanz wieder her. Dadurch müssen Aufgaben wie das Laden von Modellartefakten und das Abrufen statischer Konfigurationen nicht bei jedem Kaltstart erneut ausgeführt werden.
Siwei Shen, Vice President of Engineering bei Coinbase, beschrieb die Ergebnisse im Produktivbetrieb so: „Durch die Migration auf die nächste Generation von AgentCore Runtime sank die Dauer der Kaltstarts unserer Agentensitzungen von fast einer Minute auf weniger als fünf Sekunden – selbst während der Spitzenlast. Außerdem wurden Startverzögerungen von mehr als 30 Sekunden vollständig beseitigt, während sich unser wöchentliches Agentenvolumen mehr als verdoppelte.“
Mission Cloud berichtete, dass ein erster Vergleich derselben natürlichsprachlichen Abfragelast auf beiden Versionen der Laufzeitumgebung bei Inferenzanfragen 35 % schnellere Kaltstarts, 77 % schnellere Starts der Integritätsprüfungen und 17 % niedrigere gemessene Laufzeitkosten pro Aufruf ergab. Der Agent ruft Immobilien- und Verkaufsinformationen ab, ohne dass Nutzer komplexe Datensysteme durchsuchen müssen.
Freigabe von Arbeitsspeicher und Abrechnung der Grundausstattung
AWS ändert auch die Abrechnung des Arbeitsspeichers während Leerlaufzeiten. Die Laufzeitumgebung gibt den Arbeitsspeicher innerhalb weniger Minuten frei, nachdem ein Agent ihn freigegeben hat, und skaliert einen inaktiven Agenten auf null herunter. Laut AWS können Agenten mit mehreren Interaktionen und natürlichen Pausen bis zu 68 % weniger Arbeitsspeicher pro Sitzung verbrauchen. Damit wird ein Problem des früheren Modells behoben, bei dem die Spitzenzuweisung einer Sitzung abgerechnet wurde, auch wenn der Arbeitsspeicher nicht mehr genutzt wurde.
Für ständig aktive Agenten legt die Preisgestaltung auf Basis einer verbindlich vereinbarten Grundausstattung eine Arbeitsspeicher-Grundmenge pro Sitzung fest, die als Mindestverbrauch abgerechnet wird und bei Bedarf kurzfristig auf das Vierfache erhöht werden kann. AWS zufolge entspricht der dadurch entstehende vorhersehbare Tarif für gleichmäßige Arbeitslasten den Tarifen für AWS-Lambda-MicroVMs. Für stark schwankende Arbeitslasten und solche, die auf null herunterskalieren, gilt weiterhin die verbrauchsabhängige Abrechnung.
Zuora berichtete, dass die neue Laufzeitumgebung den Arbeitsspeicherbedarf pro Aufruf in vielen Anwendungsfällen um rund 60 % senkte und zugleich ein höheres Anfragevolumen bei gleichbleibender Latenz bewältigte.
Speicher, Isolation und Bereitstellungsgrenzen
Jede Sitzung läuft weiterhin in einer eigenen, hardwareisolierten Firecracker-MicroVM mit eigener Identität, Zugriffsrichtlinie und eigenem Prüfprotokoll. Agenten können jetzt dynamisch ein Dateisystem einbinden und ihre Arbeit darin speichern, etwa in einem Amazon-S3-Bucket mit FUSE-Unterstützung. Laut AWS bleiben die Daten während des gesamten Auftrags innerhalb der Vertrauensgrenze der Sitzung und unterliegen einem einheitlichen Satz von Kontrollen. Damit wird die Isolation über die Rechenumgebung hinaus erweitert.
Die Beschränkung des Speicherordners auf einzelne Sitzungen gehört nicht zu den angekündigten verfügbaren Funktionen. AWS zufolge werden bis zur re:Invent sitzungsbezogene Anmeldedaten jede Sitzung an ihren eigenen Speicherordner binden und so die Einbindungsfunktion um eine feinere Kontrollmöglichkeit ergänzen.
Auch in der aktuellen V2-Dokumentation werden Unterschiede bei der Bereitstellung beschrieben. V2 muss weiterhin ausdrücklich aktiviert werden, da standardmäßig V1 verwendet wird, sofern nicht platformVersion auf V2gesetzt ist. Das Erstellen oder Aktualisieren einer V2-Laufzeitumgebung dauert mehrere Minuten, während AWS den Snapshot vorbereitet. Außerdem muss der Container über seinen /ping Endpunkt innerhalb von 120 Sekunden den Status „funktionsfähig“ melden. Diese Einrichtungszeiten sind von der Kaltstartlatenz der Sitzungen unabhängig.
Sitzungen können bis zu acht Stunden bestehen bleiben, werden jedoch nach 15 Minuten Inaktivität, beim Erreichen dieser Laufzeitgrenze oder bei einem fehlerhaften Zustand beendet. Der Sitzungszustand ist flüchtig. Bei der Beendigung wird die MicroVM zerstört und der Arbeitsspeicher bereinigt.
Mit dieser Veröffentlichung werden Sitzungsrechenleistung, Arbeitsspeicherabrechnung und Auftragsdaten in einem einzigen verwalteten Laufzeitmodell zusammengeführt. Noch fehlt die fein abgestufte Speicherisolation: Die Beschränkung des Speichers auf einzelne Sitzungen ist der letzte Schritt, um die Isolationsgarantie der Laufzeitumgebung von der Ausführung auf gespeicherte Agentenarbeit auszuweiten.
