AWS AgentCore Runtime Gets 8-vCPU Sessions and Up to 68% Memory Savings

Amazon Web Services on November 12, 2026, expanded its next-generation Amazon Bedrock AgentCore Runtime with sessions up to 8 vCPUs and 32 GB of memory, committed-baseline billing and dynamic filesystem mounts. AWS reports the updates deliver up to 15 times faster session starts while keeping hardware isolation.

The updated runtime is available across AWS Regions in North America, South America, Europe and Asia Pacific. AgentCore Runtime is the managed compute layer inside AgentCore, AWS's platform for building agents with different frameworks and models; the broader platform also handles authentication, access control and observability.

The release follows the September 18, 2026, launch of AgentCore Runtime V2, which introduced snapshot-based starts and memory reclamation. AWS had then promised larger compute and storage plus committed baseline pricing. Those capabilities now ship, alongside filesystem mounting.

How fast are session starts now?

Each session supports up to 8 vCPUs, 32 GB of memory and container images as large as 10 GB — four times the compute of the previous version, according to AWS. Sessions start in under two seconds regardless of image size or concurrency, removing the need for customer-managed warm pools or pre-provisioned clusters to fight cold starts.

The mechanism is snapshot restoration, not repeated initialization. AgentCore prepares a healthy container environment once, captures its initialized state, and restores that snapshot for each new instance. Loading model artifacts and fetching static configuration no longer repeats on every cold start.

The production numbers back the claim. Coinbase VP of Engineering Siwei Shen said: "Migrating to the next generation of AgentCore runtime reduced our agent session cold starts from nearly a minute to under five seconds, even during peak traffic. It also eliminated startup delays longer than 30 seconds, all while our weekly agent volume more than doubled."

Mission Cloud tested the same natural-language query workload on both runtime versions. It measured 35% faster cold starts for inference requests, 77% faster health-check starts and 17% lower runtime cost per call. In short: bigger sessions, smaller bills.

What changes in memory billing?

The runtime now reclaims memory within minutes after an agent releases it and scales idle agents to zero. AWS says multi-turn agents with natural pauses can consume up to 68% less memory per session. That fixes the earlier model, which billed the session's peak allocation even after the memory sat unused.

For always-on agents, committed baseline pricing sets a per-session memory floor billed as a minimum, with bursts up to four times that level on demand. AWS prices the predictable steady-workload rate using AWS Lambda MicroVM rates; consumption pricing stays for spiky and scale-to-zero workloads.

Zuora reported the new runtime cut its memory footprint per invocation by roughly 60% in many use cases, while handling more traffic at steady latency.

What about storage and isolation?

Each session still runs in its own hardware-isolated Firecracker microVM, with its own identity, access policy and audit trail. Agents can now dynamically mount and save work to a filesystem, such as an Amazon S3 bucket with FUSE support. AWS says the data stays inside the session trust boundary for the entire job under one set of controls, extending isolation beyond the compute environment.

Per-session storage-folder scoping is missing from the announced availability. AWS says that by re:Invent, session-labeled credentials will bind each session to its own storage folder.

V2 remains opt-in — V1 is the default unless platformVersion is set to V2. Creating or updating a V2 runtime takes several minutes while AWS prepares the snapshot, and the container must report healthy through its /ping endpoint within 120 seconds. Those setup times are separate from session cold-start latency.

Sessions persist up to eight hours but terminate after 15 minutes of inactivity, at the lifetime limit or when unhealthy. Session state is ephemeral; termination destroys the microVM and sanitizes memory.

The release ties session compute, memory billing and job data into one managed runtime model. The unfinished piece is per-session storage scoping — the remaining step in extending the runtime's isolation guarantee from execution to saved agent work.