AMAZON BEDROCK / SERVICE DETAIL S02

AGENTCORE RUNTIME

CHAPTER 07 / 36
IN ONE LINE the cloud that runs your agent
REV 2026.07

Runtime is the service that runs your agent in the cloud. You hand it your agent code; it provides the computer, scales it up and down, keeps each user separate, and handles the plumbing. You manage no servers.

New to these words? Read chapter 02 "Key terms" (serverless, container, ARM64, microVM, session).

[ 1 ] WHAT RUNTIME IS

Runtime hosts your agent as a container (a sealed package of your code and everything it needs). It runs serverless: AWS provides and scales the computers, and you pay only for what you use. Each user's run, called a session, happens in its own microVM (a tiny private computer), so one user's data never touches another's. It supports long jobs (up to 8 hours), answers that stream as they are written, images and files (multi-modal), and many agent frameworks.

YOU BRING

Your agent code, packaged as a container built for ARM64 (the chip type AWS uses).

RUNTIME HANDLES

Starting and scaling the computers, keeping sessions isolated, identity, versions, and logs.

[ 2 ] HOW YOU DEPLOY AND CALL IT

STEP 01

PREPARE

Add the small web endpoints the AgentCore SDK needs, and list your Python dependencies.

==>

STEP 02

BUILD

Package your code for ARM64: a code zip the CLI uploads for you (the default), or a container image you push to Amazon ECR (AWS's image store).

==>

STEP 03

CREATE

==>

STEP 04

CALL

Invoke it with a session id (a name for this conversation) and the user's input.

==>

STEP 05

WATCH AND UPDATE

Read logs and traces. New code becomes a new version. Point the address at the version you want.

[ 3 ] HOW SESSIONS STAY SEPARATE

A session is one continuous run with a user, named by a session id. Reuse the id across turns to keep the conversation going. Each session runs in its own microVM (a tiny private computer).

ACTIVE

Working on a request, or running a background task.

IDLE

Waiting for the next turn, but still holding the conversation.

STOPPED

After 15 minutes idle or 8 hours of compute (both defaults, configurable), an explicit stop, or ill health. The next invocation resumes the session on fresh compute.

When a session's compute stops, its microVM is destroyed and its memory is wiped, so nothing leaks. Files are temporary by default (optional session storage can persist them). For lasting memory, use the Memory service (chapter 09).

[ 4 ] VERSIONS AND ENDPOINTS, FOR SAFE UPDATES

VERSIONS

A version is a frozen snapshot of your setup.

V1 is created with the runtime.

Each change makes a new version.

This gives you history and an easy roll back.

ENDPOINTS

An endpoint is an address that points at a version.

The DEFAULT endpoint always points at the newest.

Make extra endpoints for dev, test, and prod.

Endpoints can be repointed to another version without redeploying.

[ 5 ] THE SERVICE CONTRACT (only if you build a custom agent)

Your agent is a small web service. AgentCore talks to it on fixed addresses (ports and paths). The SDK sets these up for you, so you only need this table if you build an agent by hand.

PROTOCOL (how it talks)	PORT	PATH	USE
HTTP	8080	/invocations, /ws	normal request and reply, plus live streaming
MCP	8000	/mcp	when the agent is itself a tool server
A2A	9000	/ (root)	when other agents call this agent
AG-UI	8080	/invocations (SSE), /ws	driving an interactive user interface

/ping is a health check: your agent replies Healthy or HealthyBusy (optionally with the time its status last changed, set only on a real change), so AgentCore knows it is alive and not stuck. Inbound auth (who is allowed to call your agent) is AWS SigV4 or OAuth 2.0.

Plain definitions: chapter 02 "Key terms". Hands-on commands: chapter 08 "Runtime, practical".

SRC: AWS AgentCore Developer Guide (runtime how-it-works, service contract). DRAWN 2026.06, REV 2026.07.26