AWS montre la prévisualisation en direct d’une application web dans une session AgentCore Runtime avec ports autorisés et authentification par requête

Published 2026-10-30 · AI Daily — AI-assisted deep research, methodology & disclosure

Un tutoriel AWS daté du 30 octobre 2026 montre comment prévisualiser une application web pendant qu'un agent de programmation la modifie dans une session Amazon Bedrock AgentCore runtime. L'exemple fait tourner le serveur de développement Vite avec l'agent, puis ouvre une page locale avec une conversation et le site vivant côte à côte. Après un changement de fichier, le site affiché évolue. Il s'agit d'une méthode de développement et de revue, pas de l'annonce d'un hébergement public de production par l'URL de session. Dans le titre, « preview » décrit l'action de prévisualiser, sans préciser un statut de lancement du service.

Un Session endpoint appartient à une seule session de runtime. Lors de la création du runtime, le développeur choisit une à cinq entrées de ports autorisés, chacune étant un port ou une plage. Dans l'exemple, Vite écoute sur 8090 et la route de statut de l'agent sur 8081. Le serveur d'invocation de l'agent écoute sur 8080, mais ce port ne figure pas dans la liste du Session endpoint : les instructions de l'utilisateur passent par l'API distincte InvokeAgentRuntime. Une réponse de cette API fournit l'URL du Session endpoint dans un en-tête. Le client externe se connecte en HTTPS sur le port 443 ; un préfixe de nom d'hôte choisit le port interne. Le tunnel accepte HTTP/1.1, HTTP/2, y compris les événements serveur et gRPC, ainsi que WebSocket.

Chaque requête adressée au Session endpoint doit être authentifiée. Avec IAM, elle porte une signature SigV4 ; avec un autoriseur JWT entrant, un jeton bearer. Une page de navigateur ne sait pas ajouter seule ces identifiants à chaque ressource et poignée de main WebSocket. L'exemple utilise donc le client du SDK pour ouvrir un relais local sur localhost:8088, lequel ajoute les identifiants du développeur et transmet vers le port distant 8090. L'interface de prévisualisation est servie séparément sur localhost:8087. Ces deux ports locaux ont des fonctions distinctes et ne transforment pas la session en site public libre d'accès.

Le parcours demande un compte AWS dans une région compatible, les droits de créer un rôle IAM, des ressources S3 et le runtime, Python 3.10 ou plus avec des versions précisées d'AgentCore et boto3, Node.js 22 ou plus et l'accès à Claude Haiku 5.5 dans Bedrock. Le script de démonstration emballe l'agent Node et le site dans un zip, le charge sur S3 puis crée le runtime par déploiement direct de code. Dans la session, Vite écoute sur 0.0.0.0 pour être accessible par le Session endpoint. Le notebook lance ensuite une session avec InvokeAgentRuntime, lit l'URL de la réponse et démarre le relais local puis la page de prévisualisation.

Lorsqu'un utilisateur demande un changement, son message passe par InvokeAgentRuntime, pas par le relais du port web. Les outils de fichiers de l'exemple limitent lecture et écriture au dossier du site. Après l'enregistrement, Vite pousse la mise à jour par WebSocket à travers le Session endpoint authentifié et le relais local ; la page ouverte change sans rechargement manuel. Le même endpoint peut joindre la route de statut sur 8081. Un port non autorisé renvoie 403, une requête sans identifiants 403 ou 401, un port permis sans serveur 502 et une session disparue 404. Ce sont des refus du runtime, à distinguer des erreurs de l'application.

AWS indique retirer ses en-têtes d'authentification avant de transmettre la requête et permettre l'enregistrement des appels InvokeAgentRuntimeProxy comme événements de données CloudTrail, à condition de créer un trail ou un event data store et de configurer un advanced event selector pour AWS::BedrockAgentCore::Runtime. Les événements de données ne sont pas enregistrés par défaut et ne figurent pas dans Event history. Le site et l'agent partagent néanmoins la même session : leurs droits ne sont pas isolés l'un de l'autre. Il faut limiter le rôle d'exécution aux permissions nécessaires. Si le calcul de la session est remplacé, les connexions se ferment et les modifications de fichiers risquent de disparaître sans stockage persistant. L'URL ne dure que le temps de la session et demande une authentification à chaque requête. Pour servir une application aux utilisateurs finaux, AWS conseille un déploiement séparé et explique comment supprimer ensuite le runtime, le code chargé et le rôle IAM afin d'éviter des frais continus.

Sources

FAQ

Quel est le rôle des ports 8080, 8081, 8090, 8087 et 8088 dans l’exemple ?

Le port 8080 reçoit les invocations de l'agent via l'API distincte InvokeAgentRuntime et ne figure pas parmi les ports du Session endpoint. Dans la session, 8090 sert Vite et 8081 le statut. En local, 8088 est le relais authentifié du SDK et 8087 sert la page mêlant conversation et site. Le client externe utilise toujours HTTPS sur 443.

Quels chemins empruntent respectivement les demandes et les mises à jour Vite ?

La demande passe par InvokeAgentRuntime vers l'agent, qui modifie les fichiers du dossier du site. Vite détecte l'enregistrement et pousse une mise à jour par WebSocket, à travers le Session endpoint authentifié puis le relais local 8088, vers l'aperçu sur 8087. L'invocation de l'agent et la prévisualisation empruntent des chemins distincts.

Le Session endpoint peut-il héberger directement un site public de production, et quelles sont ses limites ?

Non. L'endpoint ne dure qu'une session, authentifie chaque requête et limite les ports accessibles. Un port interdit renvoie 403, un port permis sans serveur 502 et une session terminée 404. Un remplacement du calcul coupe les connexions ; sans stockage persistant, les modifications peuvent disparaître. Il faut déployer séparément le site destiné aux utilisateurs finaux.