Amazon Bedrock AgentCore ermöglicht Live-Webvorschauen aus einer Agentensitzung
Amazon beschreibt in seinem Beispiel, wie sich eine Webanwendung beobachten lässt, während ein Coding-Agent ihre Dateien verändert. Grundlage ist die Amazon Bedrock AgentCore Runtime. Dort läuft jede Agentensitzung in einer eigenen isolierten microVM. Ein Session Endpoint gewährt authentifizierten Zugriff auf die Ports, die für genau diese Sitzung freigegeben wurden.
Die Anordnung trennt zwei Kommunikationswege. InvokeAgentRuntime dient dazu, den Agenten selbst zu erreichen. Weitere Dienste, die innerhalb derselben Sitzung neben dem Agenten laufen, etwa ein Entwicklungsserver oder eine Statusroute, können über den Session Endpoint angesprochen werden, sofern ihre Ports ausdrücklich in der Runtime-Konfiguration stehen.
Ports konfigurieren und die URL erhalten
Beim Erstellen einer Agent Runtime nimmt allowedPorts ein bis fünf einzelne Ports oder Portbereiche auf. Sie müssen innerhalb von 8000 bis 12000 liegen und dürfen keine von der Plattform reservierten Ports enthalten. Anwendungen, die über diese Ports erreichbar sein sollen, müssen auf 0.0.0.0 lauschen.
InvokeAgentRuntime liefert die URL des Session Endpoints im Header X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url zurück. Unterstützende SDKs stellen denselben Wert als sessionEndpointUrl bereit. Die Adresse gehört nur zu einer Sitzung. Jede Anfrage benötigt Anmeldedaten, und mit dem Ende der Sitzung funktioniert der Endpoint nicht mehr.
Authentifizierung und übertragener Datenverkehr
Bei einer mit IAM autorisierten Runtime müssen HTTP-Anfragen, HTTP/2-Streams und WebSocket-Handshakes für den Session Endpoint mit SigV4 signiert sein. Zusätzlich benötigt der Aufrufer die Berechtigung bedrock-agentcore:InvokeAgentRuntimeProxy. Verwendet die Runtime stattdessen einen eingehenden JWT Authorizer, werden Bearer-Token eingesetzt.
Der Session Endpoint transportiert HTTP/1.1- und HTTP/2-Datenverkehr. Dazu gehören Server-Sent Events und gRPC sowie WebSocket-Verbindungen. Im Beispiel können dadurch sowohl gewöhnliche Webinhalte als auch die Live-Verbindung des Entwicklungsservers über denselben sitzungsgebundenen Zugang übertragen werden.
Das SDK bedrock-agentcore bietet einen Session-Endpoint-Client, der einen lokalen Endpoint bereitstellen kann. Er ergänzt Browseranfragen und WebSocket-Handshakes um die erforderlichen Anmeldedaten und leitet sie anschließend an den Session Endpoint weiter. Der Browser verbindet sich somit mit einer lokalen Adresse, während der Client die authentifizierte Weiterleitung in die Sitzung übernimmt.
Aufbau des Beispiels
Der Coding-Agent läuft im Beispiel auf Port 8080. Ein Vite-Entwicklungsserver verwendet Port 8090, und der Agent stellt auf Port 8081 eine Statusroute bereit. Über den Session Endpoint werden nur 8090 und 8081 freigegeben. Port 8080 fehlt absichtlich, weil InvokeAgentRuntime den Agenten erreicht, ohne den Session Endpoint zu verwenden.
Speichert der Agent eine geänderte Datei, übermittelt Vite die Änderung über seinen Hot-Reload-WebSocket. Die Verbindung führt über den Session Endpoint und den lokalen Endpoint bis zum Browser. Dadurch aktualisiert sich die angezeigte Website ohne manuelles Neuladen. Der Ablauf verbindet die Dateiänderungen des Agenten, den weiterlaufenden Vite-Server und die authentifizierte WebSocket-Übertragung innerhalb derselben Sitzung.
Voraussetzungen und Zugriffsgrenzen
Für das Beispiel nennt Amazon Python 3.10 oder neuer, bedrock-agentcore ab Version 1.25.2 sowie boto3 ab Version 1.43.122. Erforderlich sind außerdem Node.js 22 oder neuer mit npm, Git, eine Jupyter-Umgebung und Zugriff auf Claude Haiku 5.5 in Amazon Bedrock.
Die Liste der erlaubten Ports steuert den Zugriff unmittelbar. Eine Anfrage an einen Port außerhalb von allowedPorts wird mit HTTP 403 AccessDenied abgewiesen. Dasselbe gilt für eine Anfrage ohne Anmeldedaten. Stammt die Ablehnung von der Runtime, bleibt der Antworttext leer; ein Fehlercode steht stattdessen in einem Antwort-Header.
Der Zugriff auf einen zusätzlichen Dienst hängt damit von drei Bedingungen ab: Die Anwendung muss an der vorgesehenen Adresse lauschen, ihr Port muss freigegeben sein, und jede Anfrage beziehungsweise Verbindung muss die zum Autorisierungsmodus passenden Anmeldedaten tragen. Zudem ist die URL an die Lebensdauer einer bestimmten Sitzung gebunden.
Der gesamte Weg ist klar begrenzt. InvokeAgentRuntime spricht den Agenten an und gibt die Sitzungs-URL zurück. Der Session Endpoint öffnet ausschließlich die konfigurierten Zusatzports. Der lokale SDK-Client versieht Browserdaten mit der nötigen Authentifizierung. Vite meldet gespeicherte Änderungen über seinen WebSocket, sodass die aktuelle Webvorschau ohne erneutes Laden sichtbar wird.
Für das Verständnis des Beispiels ist die unterschiedliche Rolle der Ports entscheidend. Port 8080 gehört zum direkten Aufruf des Agenten. Die Ports 8090 und 8081 zeigen dagegen den sitzungsgebundenen Proxyzugriff. Diese Trennung erklärt, warum die Webanwendung über den Session Endpoint angezeigt werden kann, während der Agent weiterhin über InvokeAgentRuntime erreichbar bleibt.