AWS zeigt Live-Vorschau einer Web-App in einer AgentCore-Runtime-Sitzung mit Portfreigabe und Authentifizierung jeder Anfrage

Ein AWS-Tutorial vom 30. Oktober 2026 zeigt, wie sich eine Webanwendung live ansehen lässt, während ein Coding-Agent sie in einer Amazon-Bedrock-AgentCore-Runtime-Sitzung bearbeitet. Im Beispiel laufen der Vite-Entwicklungsserver und der Agent in derselben Sitzung. Eine lokale Seite zeigt links den Chat und rechts die aktuelle Website; nach einer Dateiänderung ändert sich die Ansicht. Das ist ein Ablauf für Entwicklung und Prüfung, keine Behauptung, dass die Sitzungs-URL als öffentliche Produktionsumgebung dient. Das Wort „preview“ im Titel bezeichnet die Vorschauhandlung und kündigt keine bestimmte Freigabephase eines Dienstes an.

Ein Session endpoint gehört zu genau einer Runtime-Sitzung. Bei der Erstellung der Runtime bestimmt der Entwickler ein bis fünf erlaubte Porteinträge, jeweils einen Port oder einen Bereich. Im Beispiel bedient Port 8090 Vite und Port 8081 die Statusroute des Agenten. Dessen Aufrufserver läuft auf Port 8080, doch dieser steht nicht auf der Freigabeliste des Session endpoints: Prompts kommen über die getrennte InvokeAgentRuntime-API. Eine Antwort dieser API trägt die URL des Session endpoints im Header. Von außen verbindet sich der Client immer per HTTPS über Port 443; ein Präfix im Hostnamen wählt den internen Port. HTTP/1.1, HTTP/2 mit Server-Sent Events und gRPC sowie WebSocket lassen sich weiterleiten.

Jede Anfrage an den Session endpoint benötigt Authentifizierung. Bei IAM ist sie mit SigV4 signiert, bei einem eingehenden JWT-Authorizer trägt sie ein Bearer-Token. Ein Browser kann die Zugangsdaten nicht selbst zu allen Ressourcenabrufen und WebSocket-Handshakes einer Seite hinzufügen. Deshalb öffnet der SDK-Client im Beispiel einen lokalen Weiterleiter auf localhost:8088, der die Entwickleranmeldedaten ergänzt und zum entfernten Port 8090 weiterleitet. Die Vorschauseite selbst läuft getrennt auf localhost:8087. Die beiden lokalen Ports erfüllen unterschiedliche Aufgaben und machen die Sitzung nicht ohne Berechtigung öffentlich zugänglich.

Für das Tutorial nennt AWS ein Konto in einer unterstützten Region, Rechte zum Anlegen von IAM-Rolle, S3-Ressourcen und Runtime, Python ab 3.10 mit den angegebenen AgentCore- und boto3-Versionen, Node.js ab 22 und Zugriff auf Claude Haiku 5.5 in Bedrock. Ein Skript verpackt den Node-Agenten und die Website als ZIP, lädt es auf S3 und erstellt per direktem Code-Deployment die Runtime. Vite lauscht innerhalb der Sitzung auf 0.0.0.0, damit der Session endpoint es erreichen kann. Das Notebook startet die Sitzung mit InvokeAgentRuntime, liest die URL aus der Antwort und öffnet den lokalen Weiterleiter sowie die Vorschau.

Ein Änderungswunsch an den Agenten läuft über InvokeAgentRuntime und nicht über den weitergeleiteten Webport. Die Dateiwerkzeuge des Beispiels begrenzen Lese- und Schreibzugriffe auf den Site-Ordner. Speichert der Agent eine Datei, sendet Vite ein Hot-Update über WebSocket durch den authentifizierten Session endpoint und den lokalen Weiterleiter; die offene Seite ändert sich ohne manuelles Neuladen. Über den ebenfalls erlaubten Port 8081 erreicht man die Statusroute. Ein Port außerhalb der Freigabeliste ergibt 403, fehlende Zugangsdaten 403 oder 401, ein erlaubter Port ohne lauschenden Dienst 502 und eine beendete Sitzung 404. Diese Runtime-Antworten sind von Fehlern der Webanwendung zu unterscheiden.

AWS zufolge entfernt die Runtime ihre Authentifizierungsheader vor der Weiterleitung und kann Aufrufe als InvokeAgentRuntimeProxy-Datenereignisse in CloudTrail protokollieren, sofern ein Trail oder Event Data Store mit einem Advanced Event Selector für AWS::BedrockAgentCore::Runtime eingerichtet wird. Datenereignisse werden standardmäßig nicht protokolliert und erscheinen nicht in Event history. Website und Agent teilen aber eine Sitzung und sind nicht durch getrennte Berechtigungsräume isoliert; die Ausführungsrolle sollte nur nötige Rechte besitzen. Wenn die Sitzungsberechnung ersetzt wird, brechen Verbindungen ab, und ohne dauerhaften Speicher können Dateiänderungen verloren gehen. Die URL gilt nur während der Sitzung und verlangt bei jeder Anfrage Zugangsdaten. Für Endnutzer muss die App getrennt bereitgestellt werden. Das Tutorial beschreibt auch die Entfernung von Vorschau, Runtime, hochgeladenem Code und IAM-Rolle, damit keine laufenden Kosten entstehen.