Amazon Bedrock AgentCore Runtime V2 macht Cold Starts berechenbar, doch die Kosten müssen sich noch beweisen

Amazon hat Amazon Bedrock AgentCore Runtime V2 mit einer bemerkenswerten Behauptung vorgestellt: Cold Starts bleiben bei rund zwei Sekunden – für Container-Images von 200 MB bis 2 GB.

Dieses Ergebnis stellt einen bekannten Kompromiss bei Serverless-Systemen infrage. Teams können einen Agenten auf null skalieren und Kosten sparen, doch der nächste Nutzer wartet oft, während dessen Umgebung startet. Instanzen warm zu halten verkürzt diese Verzögerung, bindet aber auch Kapazität, die möglicherweise ungenutzt bleibt.

Runtime V2 greift beide Seiten dieses Kompromisses an. AWS zufolge stellt es vorbereitete Snapshots wieder her, statt jede Umgebung neu aufzubauen. Zudem gibt es ungenutzten Speicher frei, während eine Sitzung aktiv bleibt, anstatt die Abrechnung am früheren Höchstwert der Sitzung auszurichten.

Die Ankündigung ist relevant, weil produktive Agenten anders funktionieren als herkömmliche Request-Handler. Sie können auf Modelle warten, Tools aufrufen, Dateien verarbeiten und Arbeitszustände über eine lange Folge von Anfragen hinweg behalten. Eine Laufzeitumgebung, die auf kurze Webtransaktionen ausgelegt ist, kann Ressourcen verschwenden, wenn diese Pausen die Sitzung dominieren.

AWS positioniert V2 gegen diese Infrastruktur-Diskrepanz, nicht nur gegen ein weiteres Agent-Framework. Im Mittelpunkt steht der Wettbewerb zwischen Snapshot-basierter, nutzungssensitiver Ausführung und Umgebungen, die für vorhersehbare Leistung warm bleiben oder Spitzenzuweisungen beibehalten.

Microsoft und Google bieten bereits eigene Antworten auf die Startlatenz von Containern. Microsoft nutzt vorgewärmte Sitzungspools, während Google Mindestinstanzen und CPU-Beschleunigung beim Start empfiehlt. Amazons neues Argument lautet, dass Teams keine dauerhaft warme Kapazität benötigen sollten, um konsistentes Startverhalten zu erzielen.

Die Zahlen wirken vielversprechend, stammen jedoch aus dem AWS-eigenen Benchmark. Käufer benötigen weiterhin Nachweise auf Workload-Ebene, die realen Initialisierungscode, Lastspitzen, Speicherdruck, regionale Kapazitäten und die Gesamtlatenz der Anwendung abdecken.

Was Amazon Bedrock AgentCore Runtime V2 tatsächlich verändert

Runtime V2 verändert, wann Agentenumgebungen initialisiert werden und wie lange zugewiesener Speicher kostenpflichtig bleibt.

Amazon Bedrock AgentCore Runtime ist die verwaltete Compute-Schicht innerhalb von AgentCore. Sie hostet einen Agenten oder ein Tool in einer isolierten MicroVM, einer schlanken virtuellen Maschine mit getrennten CPU-, Speicher- und Dateisystemressourcen.

AWS kündigte V2 am 18. September 2026 an. Entwickler können es auswählen, indem sie beim Erstellen oder Aktualisieren einer Runtime platformVersion auf V2 setzen. Laut der aktuellen Runtime-Architektur bleibt V1 der Standard.

Die erste wesentliche Änderung betrifft die Initialisierung. Wenn ein Entwickler eine V2-Runtime erstellt oder aktualisiert, startet AgentCore den Container und wartet auf dessen Health Check. Anschließend erstellt die Plattform einen vorbereiteten Snapshot dieser laufenden Umgebung.

Künftige Instanzen stellen den Snapshot wieder her, statt die gesamte Startsequenz zu wiederholen. Einmalige Arbeiten wie das Laden von Bibliotheken, das Abrufen statischer Konfigurationen oder die Vorbereitung von Modellartefakten können daher erfolgen, bevor die erste Live-Anfrage eintrifft.

Snapshotting ist an sich nicht neu. AWS Lambda SnapStart stellt ebenfalls initialisierte Ausführungsumgebungen wieder her, um Startverzögerungen zu reduzieren. AgentCore überträgt diesen Ansatz auf langlebigere, isolierte Agentensitzungen mit benutzerdefinierten Containern und zustandsbehafteten Interaktionen.

Die zweite Änderung betrifft die Speicherabrechnung. V1 behielt zugewiesenen Speicher bis zum Ende einer Sitzung bei, selbst wenn der Agent Puffer freigab oder zwischengespeicherte Daten nicht mehr nutzte. Die Nutzung konnte daher dem höchsten während dieser Sitzung erreichten Speicherwert folgen.

V2 beginnt mit einem kleineren residenten Speicherbedarf und lagert Speicher bei Bedarf ein, wenn der Workload darauf zugreift. AWS zufolge gibt die Plattform Speicher frei, nachdem die Anwendung ihn freigegeben hat oder die Daten kalt geworden sind.

Die aktuellen Nutzungsregeln besagen, dass ungenutzter Speicher in V2 nach 120 Sekunden automatisch freigegeben wird. Für die Speicherabrechnung gilt ein Minimum von 128 MB, während auch System-Overhead in die gemessene Nutzung einfließt.

Die CPU folgte bereits einem verbrauchsorientierten Modell. Wartet ein Agent auf ein Modell, Tool, eine Datenbank oder eine externe API, können CPU-Kosten auf null sinken, sofern kein Hintergrundprozess aktiv bleibt. V2 erweitert diese Elastizität nun deutlich stärker auf den Speicher.

Diese Änderungen sind besonders wichtig, wenn eine Sitzung sehr unterschiedliche Phasen durchläuft. Ein Dokumentenagent könnte Speicher beim Parsen einer großen Datei belegen, diese Puffer anschließend freigeben und dann Minuten auf Modellaufrufe warten.

Unter einem High-Watermark-Modell kann die Parsing-Phase die Speichernutzung für den Rest der Sitzung prägen. Unter V2 kann die spätere Nutzung laut AWS sinken, nachdem diese temporäre Zuweisung verschwindet.

AgentCore-Sitzungen erfordern weiterhin sorgfältiges Lifecycle-Management. Eine MicroVM kann bis zu acht Stunden laufen, und das standardmäßige Inaktivitäts-Timeout kann ihre Compute-Ressourcen früher stoppen. Anwendungen müssen außerdem dauerhafte Informationen außerhalb des flüchtigen Sitzungsspeichers bewahren.

Der Start verwandelt einen Agentencontainer daher nicht in unbegrenzt persistente Infrastruktur. Er verändert die Effizienz und das Startverhalten der verwalteten Umgebung, während die Sitzungsgrenzen von AgentCore erhalten bleiben.

Diese Unterscheidung erzeugt die eigentliche Spannung. AWS verspricht die Reaktionsfähigkeit vorbereiteter Kapazität und will zugleich die Ökonomie einer Scale-to-Zero-Ausführung beibehalten.

Warum Agenten-Workloads das alte Speichermodell überforderten

Das alte Modell wurde ineffizient, weil Agentensitzungen über wechselnde Phasen aus Rechenlast, Speicherwachstum und externem Warten hinweg aktiv bleiben.

Eine herkömmliche Webanfrage hat meist einen kurzen, nachvollziehbaren Lebenszyklus. Sie trifft ein, führt Anwendungscode aus, greift auf eine Datenbank zu, liefert eine Antwort zurück und gibt ihre Ausführungsumgebung frei.

Ein Agent kann eher wie ein temporärer Mitarbeiter agieren. Er erhält ein Ziel, ruft ein Modell auf, verwendet mehrere Tools, lädt Material herunter, erstellt Zwischendateien, wartet auf Freigaben und setzt seine Arbeit später fort.

Diese Phasen stellen unterschiedliche Anforderungen an die Runtime. Tool-Aufrufe können die CPU nahezu unbeschäftigt lassen. Dokumentenverarbeitung kann kurzzeitige Speicherspitzen erzeugen. Interaktive Gespräche bestrafen Startverzögerungen, während unbeaufsichtigte Aufgaben Kosten gegenüber sofortiger Reaktion priorisieren.

V1 bot bereits Sitzungsisolierung, Scale-to-Zero-Verhalten und verbrauchsbasierte CPU-Abrechnung. Seine Speicherverwaltung behielt jedoch Zuweisungen bei, nachdem ihre nützliche Phase vorbei war.

Betrachten wir einen Coding-Agenten, der ein großes Repository überprüft. Er könnte einen Index laden, Build-Ausgaben untersuchen, mehrere Tool-Antworten vorhalten und dann den Großteil dieser Daten freigeben, bevor er auf das Modell wartet.

Die Speicherspitze beeinflusste unter der ursprünglichen Runtime dennoch die spätere Nutzung. Längere Sitzungen verstärkten die Konsequenz, weil eine frühe Zuweisung mit dem Speicherbedarf der Sitzung verbunden bleiben konnte.

AWS erklärt, bei der Abstimmung von V2 Zuweisungsmuster aus Milliarden von Sitzungen untersucht zu haben. Diese Aussage deutet auf umfangreiche interne Telemetrie hin, doch das Unternehmen hat weder die Verteilung noch die Methodik oder den repräsentativen Workload-Mix hinter der Analyse veröffentlicht.

Das Freigeben kalten Speichers richtet den Zähler stärker an der sich verändernden Last eines Agenten aus. Es schafft jedoch auch eine neue operative Frage: Wie schnell können ausgelagerte Daten zurückkehren, wenn ein Agent sie unerwartet wieder benötigt?

AWS beschreibt Speicher als bedarfsgerecht geladen, bei Freigabe zurückgewonnen und bei Kaltwerden zurückgewonnen. Die öffentliche Ankündigung nennt keine detaillierten Page-Fault-Latenzen oder Schwellenwerte für jedes Workload-Muster.

Diese Auslassung ist für Agenten mit großen wiederverwendbaren Caches relevant. Das Freigeben eines Caches kann den gemessenen Speicherverbrauch senken, doch sein späterer Neuaufbau kann CPU verbrauchen, die Latenz erhöhen oder Netzwerktransfers wiederholen.

Entwickler müssen tatsächlich entbehrliche Zuweisungen von Daten unterscheiden, die spätere Durchläufe verbessern. Ein niedrigerer Speichergraph bedeutet nicht automatisch einen schnelleren oder günstigeren vollständigen Workflow.

Die Architektur verleiht auch dem Anwendungsverhalten mehr Gewicht. Software, die temporäre Puffer freigibt, gibt der Plattform die Gelegenheit, Speicher zurückzugewinnen. Ein Prozess, der Referenzen dauerhaft behält, kann nicht erwarten, dass die Runtime erkennt, dass die Daten unnötig sind.

Lange Agentensitzungen machen diese Disziplin wertvoll. Laut AWS-Dokumentation erhält jede MicroVM-Sitzung isolierte Compute-, Speicher- und Dateisystemressourcen. Eine gestoppte Sitzung kann später neue Compute-Ressourcen erhalten, doch flüchtiger Zustand verschwindet, sofern die Anwendung keinen persistenten Sitzungsspeicher oder einen anderen dauerhaften Dienst verwendet.

Dieses Design schützt die Trennung zwischen Nutzern, verhindert jedoch, dass Entwickler In-Process-Speicher als permanenten Wissensspeicher behandeln. Gesprächsaufzeichnungen, erlernte Präferenzen und wiederverwendbare Fakten benötigen dauerhaften Speicher außerhalb der MicroVM.

Die Unterscheidung ist besonders für wissensintensive Agenten wichtig. Teams benötigen außerdem eine durchsuchbare operative Dokumentation, die Prompts, Quelldokumente, Testergebnisse und Runtime-Änderungen abdeckt. Eine gepflegte Engineering-Wissensdatenbank kann diesen Kontext über eine einzelne Ausführungssitzung hinaus bewahren.

Runtime V2 beseitigt diese architektonischen Verantwortlichkeiten nicht. Es macht die temporäre Compute-Schicht elastischer, wodurch es noch wichtiger wird, flüchtige Arbeitsdaten von dauerhaftem organisatorischem Wissen zu trennen.

Snapshot-Wiederherstellung verändert den Cold-Start-Kompromiss

Die zentrale Verbesserung entsteht durch die Wiederherstellung eines bereinigten, initialisierten Snapshots, dessen Größe mit wachsender Container-Image-Größe relativ stabil bleibt.

Ein Cold Start ist die Zeitspanne, bevor eine neu erstellte Umgebung bereit ist, Anwendungsarbeit zu verarbeiten. Sie kann das Abrufen eines Images, die Bereitstellung von Compute-Ressourcen, den Prozessstart, das Laden von Abhängigkeiten und die Ausführung von Initialisierungscode umfassen.

Cold Starts werden besonders sichtbar, wenn Traffic eintrifft, nachdem ein Dienst auf null skaliert wurde. Sie treten auch bei plötzlichen Lastspitzen auf, wenn vorhandene Umgebungen nicht jede neue Sitzung bewältigen können.

Große Agentencontainer können das Problem verschärfen. Sie können Sprach-Laufzeitumgebungen, Browser-Abhängigkeiten, Agent-Frameworks, Dokumentenparser, Machine-Learning-Bibliotheken und interne Tools enthalten.

Runtime V2 verändert diesen Ablauf. AgentCore initialisiert die Umgebung bei der Vorbereitung einer Runtime-Version, erfasst ihren Zustand und stellt diesen Zustand für künftige Instanzen wieder her.

AWS erklärt, dass die Plattform auch Caches und flüchtigen Speicher entfernt, die eine wiederhergestellte Instanz nicht benötigt. Diese Bereinigung soll verhindern, dass die Snapshot-Größe mit dem gesamten residenten Speicherbedarf eines größeren Containers wächst.

Der Launch-Benchmark des Unternehmens führte 5.000 Cold Invocations pro Agent über V1 und V2 hinweg aus. Der Test umfasste fünf Image-Größen unter den Standardkontingenten eines Accounts.

V2 erreichte eine P75-Cold-Start-Latenz von etwa zwei Sekunden – von einem 200-MB-Image bis zu einem 2-GB-Image. P75 bedeutet, dass 75 Prozent der gemessenen Starts innerhalb oder unterhalb der angegebenen Zeit abgeschlossen wurden.

V1 verhielt sich im selben AWS-Test anders. Sein P75-Ergebnis stieg von rund 5,4 Sekunden für das kleinste Image auf nahezu 30 Sekunden für das größte.

Diese Zahlen machen den Mechanismus interessanter als eine bloße prozentuale Verbesserung. AWS behauptet, dass die Image-Größe im getesteten Bereich kein wesentlicher Treiber der Wiederherstellungslatenz mehr ist.

Der Benchmark verwendete außerdem eine Echo-Anwendung, deren Code bei P75 in etwa 34 Millisekunden ausgeführt wurde. Dieses Setup isoliert den Start der Infrastruktur, bildet jedoch nicht den vollständigen Ausführungspfad eines anspruchsvollen Agenten ab.

Reale Agenten verbringen bei jedem Modellaufruf oft mehrere Sekunden. Sie können außerdem Remote-Tools kontaktieren, Kontext abrufen, Nutzer authentifizieren oder Netzwerkverbindungen herstellen, nachdem die Umgebung bereit ist.

Ein Plattformstart von zwei Sekunden bedeutet nicht eine Antwort in zwei Sekunden. Er bedeutet, dass die Infrastruktur eine geringere und besser vorhersehbare Verzögerung verursacht, bevor der Agent-Code seine erste Anfrage erhält.

Diese Vorhersehbarkeit kann wichtiger sein als der Durchschnitt. Produktteams können Ladezustände, Timeouts und Erwartungen an das erste Token mit größerer Sicherheit gestalten, wenn die Startlatenz in einem engen Bereich bleibt.

AWS schlägt vor, eine Sitzung zu starten, wenn ein Nutzer eine Oberfläche öffnet, noch bevor diese Person den ersten Prompt absendet. Begrüßungstext und Tippzeit können dann einen Großteil des verbleibenden Startintervalls verbergen.

Diese Taktik ist praktisch, verändert aber auch die Nachfrage. Das Öffnen einer Oberfläche könnte Sitzungen erzeugen, die nie eine Nachricht erhalten. Teams sollten daher abgebrochene Sitzungen und unnötige Umgebungserstellungen messen.

Snapshots bringen zudem Überlegungen für die Bereitstellung mit sich. Initialisierung, die vor dem Snapshot erfasst wird, sollte keine abgelaufenen Anmeldedaten, unsichere Zufallswerte oder nutzerspezifischen Zustand enthalten.

Statische Konfiguration kann gut passen. Zeitkritische Geheimnisse und die Identität pro Sitzung sollten über restore-sichere Mechanismen abgerufen werden. Auch Health Checks müssen eine tatsächlich vorbereitete Umgebung abbilden, nicht lediglich einen lauschenden Netzwerkport.

Das Snapshot-Modell verlagert damit einen Teil der Arbeit von der Anfragezeit in die Bereitstellungszeit. Teams gewinnen schnellere Instanzerstellung, müssen aber prüfen, was Teil des erfassten Zustands wird.

AWS setzt das Modell vorgewärmter Pools unter Druck

Amazons Wettbewerbsaussage lautet nicht einfach schnellere Container; vielmehr geht es um konsistente Starts, ohne dass jedes Team dauerhaft warme Kapazität finanzieren muss.

Cloud-Anbieter bieten bereits mehrere Möglichkeiten, die Kaltstartlatenz zu reduzieren. Die meisten Ansätze tauschen ungenutzte Ressourcen, operatives Tuning oder Anwendungseinschränkungen gegen schnellere Antworten ein.

Microsofts Azure Container Apps bietet dynamische Sitzungen. Diese nutzen Pools vorgewärmter Umgebungen, die isolierte Sitzungen in Millisekunden bereitstellen können.

Dieses Modell eignet sich für Code-Interpreter und Workloads, die wegwerfbare Sandboxes benötigen. Seine Geschwindigkeit entsteht dadurch, dass vor dem Eintreffen einer Anfrage bereits fertige Umgebungen verfügbar sind.

Google Cloud Run verfolgt einen breiteren Container-Ansatz. Entwickler können Mindestinstanzen konfigurieren, um Container warm zu halten, und ein Startup-CPU-Boost kann die Initialisierung beschleunigen.

Mindestinstanzen verringern die Anfälligkeit für Kaltstarts, können jedoch durch ungenutzte Instanzen Kosten verursachen. Der Startup-CPU-Boost verbessert den Initialisierungspfad, ohne die Notwendigkeit zu beseitigen, eine Anwendung zu laden und zu starten.

Amazons V2-Design nimmt eine andere Position ein. Es bereitet einmalig einen Runtime-Snapshot vor, entfernt nicht benötigten Zustand und stellt isolierte Instanzen wieder her, sobald Sitzungen eintreffen.

Der Vergleich ist nicht absolut. Vorgewärmte Pools können eine geringere Zuweisungslatenz liefern als das von AWS gemeldete P75-Ergebnis von etwa zwei Sekunden. Sie können zudem bei vorhersehbarer Nachfrage eine klarere Kapazitätsuntergrenze bieten.

Snapshots bewahren bessere Scale-to-zero-Ökonomie, wenn der Datenverkehr unregelmäßig ist. Ihr Wert steigt, wenn ein Team viele Agenten hat, die lange ungenutzt bleiben, bei Aufruf jedoch konsistent reagieren müssen.

Dieser Wettbewerb spiegelt eine seit Langem bestehende Serverless-Frage wider. Sollten Kunden dafür zahlen, Kapazität bereitzuhalten, oder sollte die Plattform die Just-in-time-Erstellung so vorhersehbar machen, dass warme Kapazität optional wird?

Agenten-Workloads verschärfen die Frage. Ein Unternehmen könnte Hunderte spezialisierter Agenten betreiben, während jeweils nur ein kleiner Teil Arbeit verarbeitet. Jede Umgebung warm zu halten, würde Kapazität verschwenden.

Burst-Traffic schafft die gegenteilige Sorge. Wenn viele Sitzungen gleichzeitig starten, muss die Plattform Snapshots schnell wiederherstellen, ohne einen Nachteil bei der Parallelität einzuführen.

AWS sagt, dass V2 die Kaltstartlatenz unabhängig von der Parallelität konsistent hält. Die veröffentlichte Benchmark-Beschreibung betont jedoch Image-Größen und Standardquoten. Sie legt nicht jede Parallelitätsstufe oder regionale Bedingung offen.

Teams, die AgentCore bewerten, sollten vollständige Service-Level-Ziele vergleichen, nicht nur eine Startzahl. Sinnvolle Messgrößen umfassen Tail-Latenz, Zeit bis zum ersten Modell-Token, Verhalten wiederhergestellter Caches, fehlgeschlagene Starts und Leistung bei abrupten Traffic-Spitzen.

Sie sollten auch den gesamten Ressourcenverbrauch vergleichen. Ein vorgewärmter Pool hat sichtbare Leerlaufkapazität, während ein Snapshot-basierter Dienst Kosten bei Wiederherstellung, Memory Paging, Networking oder wiederholter Initialisierung nach Bereitstellungsänderungen verbergen kann.

Portabilität bleibt ein weiterer Faktor. AgentCore akzeptiert containerisierte Anwendungen und unterstützt Frameworks wie LangGraph, CrewAI und Strands Agents. Seine Runtime-Steuerung, Sitzungs-APIs, Identitätsschicht und sein Abrechnungsmodell sind jedoch AWS-spezifisch.

Microsoft und Google fördern ebenfalls die Integration mit ihren umgebenden Identitäts-, Monitoring-, Speicher- und KI-Diensten. Die Wettbewerbsentscheidung reicht daher über Kaltstarts hinaus.

Ein Unternehmen, das bereits auf eine Cloud standardisiert ist, kann operative Konsistenz höher bewerten als einen Benchmark-Vorteil. Ein Team, das eine latenzeritische Agentenplattform entwickelt, könnte stattdessen jede Runtime direkt testen.

AWS gewinnt dennoch ein wichtiges Verkaufsargument. V2 erlaubt dem Unternehmen zu behaupten, dass Scale-to-zero nicht länger erfordert, dass die Startlatenz mit dem Container-Image wächst.

Wenn unabhängige Workloads dieses Ergebnis reproduzieren, werden Cloud-Käufer von konkurrierenden Plattformen erwarten, zu erklären, warum warme Pools oder Mindestinstanzen für vergleichbare Anwendungen weiterhin notwendig sind.

Der Benchmark ist stark, aber eng gefasst

AWS hat eine glaubwürdige Infrastrukturverbesserung gezeigt, aber noch nicht niedrigere Gesamtkosten oder vorhersehbare Anwendungslatenz für jeden Produktionsagenten belegt.

Die erste Einschränkung betrifft die Unabhängigkeit der Quelle. AWS hat die Runtime entwickelt, die Testkonfiguration ausgewählt, den Benchmark ausgeführt und die Ergebnisse veröffentlicht.

Der begleitende Testcode ermöglicht es Kunden, das Experiment in ihren Accounts zu reproduzieren. Das ist nützlich, doch die Reproduzierbarkeit hängt weiterhin von Region, Quoten, Container-Design, Traffic-Muster und dem Zeitpunkt jedes Durchlaufs ab.

Die zweite Einschränkung betrifft die Wahl des Perzentils. P75 bietet eine bessere Sicht als ein Durchschnitt, doch latenzsensitive Dienste planen oft anhand von P95- oder P99-Ergebnissen.

Ein stabiles P75 von zwei Sekunden kann neben langsameren Tail-Ereignissen bestehen. Die Ankündigung liefert nicht die vollständige Verteilung, die zur Bewertung strenger nutzerseitiger Ziele erforderlich ist.

Die dritte Einschränkung ist die Einfachheit des Workloads. Ein Echo-Test hilft, den Plattformstart zu isolieren, aber Produktionscontainer führen mehr Initialisierung durch und bauen mehr externe Verbindungen auf.

Die Snapshot-Erfassung kann einen Teil der Initialisierung einbetten. Sie kann nicht garantieren, dass jede Datenbankverbindung, jeder Credential-Austausch, jede Netzwerkroute oder externe Abhängigkeit nach der Wiederherstellung sofort nutzbar ist.

Das vierte Thema ist die Kosteninterpretation. AWS sagt, dass V2 einen höheren Ressourcensatz als V1 berechnet, während die meisten Agenten ausreichend weniger Speicher verbrauchen sollten, um ihre Gesamtrechnung zu senken.

Das ist eine Unternehmensprognose, kein universelles Ergebnis. Ein speicherstabiler Agent, der Allokationen selten freigibt, könnte nur begrenzte Einsparungen erzielen und gleichzeitig den höheren V2-Satz zahlen.

Ein Agent mit temporären Speicherspitzen hat ein stärkeres Argument. Die Einsparungen sollten sich verbessern, wenn große Puffer früh verschwinden und die verbleibende Sitzung viel Zeit mit geringer Speicherbelegung verbringt.

Teams sollten beide Versionen anhand identischer Traces testen. Sie sollten Speichernutzung pro Sekunde, CPU-Verbrauch, Sitzungsdauer, Wiederherstellungslatenz, Modellkosten, Speicherkosten und Netzwerkübertragung erfassen.

Auch bei der Abrechnungstelemetrie ist Vorsicht erforderlich. AWS sagt, dass Monitoring-Daten verzögert sein und aufgrund von Aggregation und Abstimmung von maßgeblichen Abrechnungsdaten abweichen können.

Die fünfte Sorge betrifft Cache-Churn. Wenn V2 Daten freigibt, die ein Agent kurz darauf wieder benötigt, kann der Workload zusätzliche Zeit damit verbringen, diese Daten neu zu erzeugen.

Die 120-Sekunden-Regel von AWS zur Freigabe im Leerlauf liefert einen sichtbaren Schwellenwert, erklärt aber nicht vollständig, wie sich jede Speicherkategorie verhält. Entwickler sollten Abstände zwischen Turns testen, die diesen Schwellenwert überschreiten.

Die sechste Sorge betrifft die Korrektheit von Snapshots. Anwendungen initialisieren beim Start häufig Zufallszahlengeneratoren, Anmeldedaten, Netzwerkclients, temporäre Dateien und Hintergrund-Threads.

Ein wiederhergestellter Prozess darf keinen unsicheren Zustand zwischen isolierten Sitzungen wiederverwenden. Teams sollten prüfen, wie sich ihre Bibliotheken nach der Wiederherstellung verhalten, und sicherstellen, dass die Identität pro Sitzung nach der Snapshot-Grenze eintrifft.

AgentCore stellt isolierte MicroVMs bereit, aber die Anwendung bleibt für die Zuordnung von Nutzern zu Sitzungen verantwortlich. Ein Client-Backend muss verhindern, dass ein Nutzer die Sitzungskennung eines anderen Nutzers bereitstellt oder wiederverwendet.

Auch operative Fehler bleiben möglich. Quoten, regionale Kapazität, fehlerhafte Container, mangelhafte Health Checks und Limits nachgelagerter Dienste können allesamt die Nutzererfahrung dominieren.

Keine dieser Fragen entkräftet den Benchmark von V2. Sie definieren die Lücke zwischen einem vielversprechenden Plattformresultat und einer Produktionsentscheidung.

Die richtige Schlussfolgerung ist bedingt. V2 wirkt besonders attraktiv für burstige Agenten mit großen Images, aufwendiger Initialisierung, temporären Speicherspitzen und langen Wartezeiten auf Modelle oder Tools.

Agenten mit konstantem Speicherbedarf, dauerhaft aktiver Nachfrage, spezialisierten Prozessoren oder strengen Anforderungen unter einer Sekunde benötigen einen breiteren Vergleich. AWS selbst bereitet für einige dieser Workloads größere Compute-Optionen und Baseline-Zusagen vor.

Drei Signale entscheiden darüber, ob V2 gewinnt

Der nächste Test besteht darin, ob Kundenmessungen außerhalb des kontrollierten AWS-Benchmarks stabile Startlatenz, niedrigere Gesamtrechnungen und sicheres Snapshot-Verhalten bestätigen.

Das erste Signal ist die Form unabhängiger Latenzergebnisse. Entwickler sollten P50-, P75-, P95- und P99-Kaltstarts über mehrere Regionen und Traffic-Muster hinweg veröffentlichen.

Die Image-Größe sollte Teil dieser Tests bleiben, aber Parallelität ist ebenso wichtig. Eine nützliche Bewertung würde plötzliche Wellen isolierter Sitzungen starten, nachdem eine Runtime auf null skaliert wurde.

Wenn die Tail-Latenz stabil bleibt, während Image-Größe und Parallelität wachsen, wird die Kernbehauptung von AWS deutlich stärker. Große Container würden Teams nicht länger dazu zwingen, Reserveumgebungen weiterlaufen zu lassen.

Wenn P95- und P99-Ergebnisse stark variieren, wird die P75-Schlagzeile von zwei Sekunden weniger operativen Wert haben. Teams mit interaktiven Agenten bräuchten weiterhin warme Kapazität oder eine aggressive Voraberstellung von Sitzungen.

Das zweite Signal sind gemessene Kosten über vollständige Sitzungen hinweg. Der höhere Ressourcensatz von V2 bedeutet, dass das wirtschaftliche Ergebnis davon abhängt, wie viel Speicher die Runtime tatsächlich freigibt.

Teams sollten Workloads mit bekannten Phasen wiedergeben. Ein repräsentativer Test könnte ein großes Dokument parsen, dessen Puffer freigeben, mehrere Modellaufrufe durchführen, länger als 120 Sekunden warten und dann fortsetzen.

Wenn der abgerechnete Speicher nach der Parsing-Phase sinkt und niedrig bleibt, stützt V2 das Kostenargument von AWS. Bleibt der Verbrauch nahe dem früheren Peak, schwächen sich die erwarteten Einsparungen ab.

Der Vergleich sollte mehr als Runtime-Gebühren umfassen. Modellinferenz, Observability, Speicher, Netzwerkübertragung, Container-Speicher, Browser-Sitzungen und Tool-Dienste können die Endrechnung dominieren.

Diese breitere Sicht verhindert, dass eine kleine Runtime-Einsparung als dramatische Reduzierung auf Anwendungsebene dargestellt wird. Sie zeigt auch, ob schnellere Starts Teams dazu ermutigen, unnötige Sitzungen zu erstellen.

Das dritte Signal ist die Bereitstellung der von AWS als „coming soon“ aufgeführten Funktionen. Die Roadmap umfasst Rabatte für zugesagte Baseline-Kapazität, größere Compute- und Speicherressourcen, x86-MicroVM-Unterstützung, stärkere Lifecycle-Kontrolle und sitzungsbezogene Identität.

Jeder dieser Punkte betrifft eine aktuelle Grenze. Größere Umgebungen erweitern die zulässigen Workloads. x86-Unterstützung verringert den Migrationsaufwand für Abhängigkeiten, die sich nicht ohne Weiteres auf eine andere Architektur verlagern lassen.

Steuerungen zum Anhalten und Fortsetzen würden Agenten helfen, über einen einzelnen Compute-Lebenszyklus hinaus weiterzuarbeiten. Eine kontextbezogene Identität würde klarstellen, worauf unbeaufsichtigte Agenten zugreifen können, wenn keine Person sie aktiv überwacht.

Wenn AWS diese Funktionen mit klarer Dokumentation und stabilem Verhalten bereitstellt, wird Runtime V2 zu einer breiter angelegten Plattform statt zu einer gezielten Optimierung für Kaltstarts.

Verzögerungen würden die Grenzen der aktuellen Version offenlegen. Einige persistente, spezialisierte oder unbeaufsichtigte Workloads würden weiterhin andere AgentCore-Compute-Optionen oder externe Infrastruktur benötigen.

Entwickler können mit einem kontrollierten V1-zu-V2-Test beginnen. Sie sollten Agentencode, Modellaufrufe, Traffic-Trace, Region und Observability-Einstellungen unverändert lassen.

Die Entscheidung sollte auf fünf Ergebnissen beruhen: Startzeit-Perzentile, Sitzungsfehlerrate, Speichernutzung im Zeitverlauf, vollständige Workflow-Latenz und die endgültige Cloud-Rechnung.

Interaktive Produkte sollten zudem die Strategie von AWS für frühe Sitzungen testen. Das Starten der Umgebung, wenn ein Nutzer einen Chat öffnet, kann die Startzeit verbergen; abgebrochene Sitzungen müssen jedoch in der Analyse sichtbar bleiben.

Produktive Agenten verbringen zunehmend mehr Zeit mit Warten, dem Vorhalten von Zustand und der Koordination von Tools als mit kontinuierlicher CPU-Ausführung. Dadurch passen herkömmliche Container-Ökonomien für viele Workloads schlecht.

Amazon Bedrock AgentCore Runtime V2 bietet eine technisch schlüssige Antwort. Es bereitet Arbeit einmal vor, stellt einen kleineren Snapshot wieder her und gibt Speicher frei, wenn der Bedarf einer Sitzung sinkt.

Die verbleibende Frage ist empirisch: Bewahrt Amazon Bedrock AgentCore Runtime V2 diese Vorteile unter Ihren Containern, Traffic-Spitzen, Abhängigkeiten und Sicherheitskontrollen?

Führen Sie denselben Workload auf beiden Plattformversionen aus, bewahren Sie die vollständige Latenzverteilung auf und prüfen Sie die Rechnung nach der Abrechnungskonsolidierung. Diese Evidenz sollte über die Migration entscheiden, nicht die Ankündigungsüberschrift.