AWS Shows Live Web-App Preview Inside an AgentCore Runtime Session, with Allowed Ports and Per-Request Authentication

An AWS tutorial dated October 30, 2026, shows how to preview a web application while a coding agent edits it inside an Amazon Bedrock AgentCore runtime session. The example runs a Vite development server in the same session as the agent, opens a local browser page with a chat pane and a live site pane, and shows the site changing after an edit. This is a walkthrough for development and review, not a claim that the session URL is a public production hosting endpoint. The post calls the action “preview”; it does not make a general service-availability announcement.

The session endpoint is created for one runtime session. When creating the runtime, the developer chooses one to five allowed port entries, each a single port or range. In the example, port 8090 serves Vite and 8081 serves the agent's status route. The agent's invocation server listens on port 8080, but that port is not on the session endpoint allowlist: prompts reach it through the separate InvokeAgentRuntime API. A response to InvokeAgentRuntime carries the session endpoint URL in a header. To reach an allowed internal port, a client connects externally on HTTPS port 443 and selects the target with a port prefix in the hostname. The endpoint forwards HTTP/1.1, HTTP/2 including server-sent events and gRPC, and WebSocket traffic.

Each request to the session endpoint needs credentials. With an IAM-configured runtime, that means SigV4 signing; with an inbound JWT authorizer, a bearer token is used. A browser page cannot add these credentials to every resource request or WebSocket handshake on its own. The sample therefore uses the SDK's session endpoint client to open a local endpoint on localhost:8088. That local process adds the developer's credentials and forwards browser traffic to the remote port 8090. The preview UI is served separately on localhost:8087. These two local ports have different roles, and neither makes the session publicly accessible without authorization.

The tutorial's deployment prerequisites include an AWS account in a supported Region, permissions for IAM, S3 and runtime creation, Python 3.10 or later with specified AgentCore and boto3 versions, Node.js 22 or later, and access to Claude Haiku 5.5 in Bedrock. The sample uses direct code deployment: a script packages the Node agent and site, uploads a zip to S3 and creates the runtime. The Vite server listens on 0.0.0.0 inside the session, which is necessary for the session endpoint to reach it. The notebook starts the runtime session with InvokeAgentRuntime, obtains the endpoint URL, then starts the local forwarding endpoint and preview page.

When a user asks the coding agent for a change, the prompt travels through InvokeAgentRuntime, not through the session endpoint's web-port forwarding. The agent reads and writes only within its site folder in the example. Vite watches those files and sends a hot-update over WebSocket through the authenticated session endpoint and local endpoint, so the open page changes in place. The same endpoint can reach the agent's status route on allowed port 8081. Requests to a port outside the allowlist receive 403 AccessDenied; missing credentials yield 403 or 401, an allowed port with no listener yields 502, and an ended session yields 404. These are runtime responses, distinguishable from application errors.

AWS says the runtime removes its authentication headers before forwarding requests and can record InvokeAgentRuntimeProxy calls as CloudTrail data events only after a trail or event data store is configured with an advanced event selector for AWS::BedrockAgentCore::Runtime. Data events are not logged by default and do not appear in Event history. The website and agent still share one session, so their access is not isolated from each other; the execution role should have only the permissions the agent needs. Replacing the session's compute closes open connections, and file edits may not survive without persistent storage. The URL exists only for that session and needs credentials on every request. Teams wishing to serve an app to end users must deploy it separately. The tutorial also describes cleanup of the preview, runtime, uploaded code and IAM role to avoid ongoing charges; the published sample is a reproducible demonstration, not an assertion that a reader has run it successfully.