AgentCore session endpoints let a coding agent keep a Vite‑based web site running inside its isolated microVM and expose it through a signed URL. Practitioners can open that URL in a browser, see file changes instantly, and send WebSocket traffic without redeploying the app, which shortens the feedback cycle for prototype development.
How Session Endpoints Work
When you create a runtime with CreateAgentRuntime, you specify an allowedPorts list – up to five entries, each a single port or a range inside 8000–12000, excluding the reserved platform ports. The runtime does not open a listener automatically; your agent must bind a server to the chosen port on 0.0.0.0.
The InvokeAgentRuntime call returns a header named X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url. SDKs surface this as sessionEndpointUrl. The URL contains a host prefix that maps the external request port (always 443) to the internal port you allowed, for example https://8090--.runtime.bedrock-agentcore..on.aws forwards to port 8090 inside the session.
Every request – HTTP, HTTP/2, or WebSocket – must be authenticated. For IAM‑based runtimes, each request carries a SigV4 signature and requires the bedrock-agentcore:InvokeAgentRuntimeProxy permission on both the runtime and its endpoint. For runtimes using an inbound JWT authorizer, a bearer token is required instead. Knowing the URL alone does not grant access.
Because browsers cannot add SigV4 signatures or JWTs to outbound requests automatically, the Bedrock AgentCore SDK runs a local proxy (e.g., on http://localhost:8088) that injects the required credentials before forwarding traffic to the session endpoint.
Architectural and Operational Implications
- Shorter iteration loops: Developers can edit code, watch the live page update, and request further changes without waiting for a separate deployment pipeline.
- Isolated testing environment: Each session runs in its own microVM, limiting cross‑session interference and simplifying cleanup after a review.
- Port management: Teams must ensure the agent’s web server listens on an allowed port and binds to all interfaces; otherwise the endpoint will reject connections.
- Local proxy requirement: Production users cannot connect directly; a trusted local process is needed to sign requests, which adds a small operational component to the workflow.
Security Considerations
The endpoint enforces per‑request authentication, so accidental exposure of the URL does not compromise the service. However, the following points merit attention:
- Credentials used by the local proxy must be protected, as they can sign any request to the session.
- Allowed ports should be limited to the minimum required; broader ranges increase the attack surface within the microVM.
- Because the session URL is short‑lived, it should be discarded after the review to avoid reuse.
- When using IAM, the
bedrock-agentcore:InvokeAgentRuntimeProxypermission should be scoped tightly to the specific runtime and endpoint resources.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
AgentCore session endpoints provide a practical way to preview agent‑generated web apps without a full CI/CD push. Teams should adopt the pattern for rapid prototyping, ensure port configurations match the agent’s server, and treat the local credential‑injecting proxy as a trusted component. Monitoring the lifetime of session URLs and restricting IAM permissions will keep the convenience from becoming a security liability.
