Was am 6. August auf den Markt kam, und wo

AWS beschreibt Runtime Instances in der eigenen Ankündigung als 'persistente, verwaltete EC2-Infrastruktur für produktive KI-Agenten mit Multi-Agent-Zusammenarbeit, GPU-Unterstützung und Sitzungen von bis zu 14 Tagen Dauer'. Diese Zahl ist die zentrale Neuerung: Die zuvor ausgelieferten AgentCore-Runtime-MicroVMs von AWS sind bei 8 Stunden pro Aufruf gedeckelt, was für eine einzelne Aufgabe praktikabel ist, nicht aber für einen Agenten, der tagelang weiterarbeiten, überwachen oder auf externe Ereignisse warten soll.

Die regionale Verfügbarkeit zum Start umfasst US East (Ohio, N. Virginia), US West (Oregon), Asien-Pazifik (Mumbai, Singapur, Sydney, Tokio) und Europa (Frankfurt, Irland). Für jede EU-Organisation, die aus Gründen der Datenresidenz oder vertraglicher Anforderungen die Datenverarbeitung von Agenten-Workloads innerhalb der EU halten muss, ist die Verfügbarkeit in Frankfurt und Irland bereits zum Start - statt erst Monate später - das bemerkenswerte Detail.

Wie Agenten wirklich miteinander sprechen: Ein gemeinsames Verzeichnis, keine API

Das eigene Anwendungsbeispiel von AWS ist konkret: Ein Code schreibender Agent speichert seine Ausgabe unter einem Pfad wie /tmp/agentcore-session/{session-id}/code.py, und ein zweiter, prüfender Agent liest von genau diesem Pfad mit derselben Sitzungs-ID - sie koordinieren sich über das gemeinsame Dateisystem, das eine Runtime-Instanz innerhalb einer Sitzung bereitstellt, statt über direkte API-Aufrufe zwischen den beiden Agenten.

Das ist eine bedeutsam andere Architektur als das Anfrage-Antwort-Muster, das die meisten Frameworks zur Agenten-Orchestrierung verwenden, und das ist mehr als nur eine Bequemlichkeitsfrage. Ein gemeinsames Sitzungsverzeichnis ist eine gemeinsame Vertrauensgrenze: Jeder Agent mit Schreibzugriff auf diesen Pfad kann im Prinzip verändern, was ein anderer Agent liest - eine seitliche Bewegungsfläche innerhalb dessen, was AWS als eine einzelne isolierte Sitzung darstellt, und etwas, das eine Sicherheitsprüfung von AgentCore ausdrücklich testen muss, statt es einfach vorauszusetzen.

Die eigentliche Verschiebung: KI-Rechenleistung erscheint jetzt wie ein Server auf der Rechnung

Die Preisgestaltung für Runtime Instances besteht aus Standard-EC2-Instanzpreisen plus einer zusätzlichen AgentCore-Orchestrierungsgebühr, und AWS' eigene Beispielkonfiguration - eine c7g.2xlarge-Instanz mit 8 vCPUs und 16 GiB Arbeitsspeicher, unter Arm64 oder x86_64 Linux - liest sich wie eine Serverspezifikation, weil sie genau das ist. Sitzungen können gestoppt und neu gestartet werden, um Leerlaufzeiten nicht bezahlen zu müssen, doch eine bereitgestellte Instanz, die bis zu 14 Tage besteht, ist ein grundlegend anderes Kostenobjekt als ein zustandsloser, pro Token abgerechneter Inferenzaufruf.

Für jedes Finanz- oder Plattformteam, das generative KI-Ausgaben bislang rein als Inferenzkosten-Posten budgetiert hat, ist dies der Punkt, an dem agentische KI-Workloads sich wie der Rest des Rechenbestands zu verhalten beginnen: Kapazitätsplanung, Leerlaufmanagement und Instanztypauswahl werden erneut zu lebendigen Budgetfragen - genau wie vor der Serverless-Abstraktion.

Was ein EU-Käufer vor der Einführung von Runtime Instances prüfen sollte

Zwei Fragen lohnen sich vor einer produktiven Einführung. Erstens sollte für jeden Workload mit personenbezogenen oder regulierten Daten bestätigt werden, dass die Verfügbarkeit in Frankfurt oder Irland tatsächlich die spezifischen Residenz- und Verarbeitungsortsanforderungen der Organisation erfüllt, denn regionale Verfügbarkeit des Dienstes ist nicht automatisch dasselbe wie eine Garantie darüber, wo jedes einzelne Sitzungsdatum und jede Protokollausgabe landet.

Zweitens sollte bei jeder Multi-Agent-Bereitstellung, die das gemeinsame Sitzungsverzeichnis nutzt, dieselbe Frage gestellt werden, die ein Sicherheitsteam bei jeder gemeinsam genutzten Dateisystem-Architektur stellen würde: Welche Agenten dürfen in den gemeinsamen Pfad schreiben, was passiert, wenn die Ausgabe eines Agenten bösartig oder beschädigt ist, und ob die Isolation, die AWS zwischen getrennten Sitzungen bietet, tatsächlich die Isolationsgrenze ist, die die Organisation zwischen den einzelnen Agenten innerhalb einer Sitzung wirklich benötigt.