AWS AgentCore Runtime Gets 8-vCPU Sessions and Filesystem Mounts

Amazon Web Services on November 12, 2026, expanded its next-generation Amazon Bedrock AgentCore Runtime with larger agent sessions, committed-baseline billing and dynamic filesystem mounts — and reports that the updates deliver up to 15 times faster session starts while retaining hardware isolation.

The updated runtime is available now in AWS Regions across North America, South America, Europe and Asia Pacific. For teams running agents in production, the stakes are direct: cold starts and peak-allocation memory billing have been among the largest cost and latency penalties in serverless agent deployments, and AWS is now attacking both inside one managed compute layer.

What is AgentCore Runtime?

AgentCore Runtime is the managed compute layer within AgentCore, AWS's platform for building agents with different frameworks and models. The broader platform also covers authentication, access control and observability. The runtime sits underneath all of it, executing agent sessions.

The November 12 release follows the September 18, 2026, introduction of AgentCore Runtime V2, which brought snapshot-based starts and memory reclamation. At that time AWS listed larger compute and storage, plus committed baseline pricing, as coming soon. Those capabilities now form much of this update, alongside filesystem mounting.

How large are the new sessions?

Each session can now use up to 8 vCPUs and 32 GB of memory and support container images as large as 10 GB. AWS says that is four times the compute of the previous version. Sessions start in under two seconds regardless of image size or concurrency, according to the company, which removes the need for customer-managed warm pools or pre-provisioned clusters to address cold starts.

The startup mechanism is snapshot restoration rather than repeated initialization. AgentCore prepares a healthy container environment once, captures its initialized state, and restores that snapshot for each new instance. Work such as loading model artifacts and fetching static configuration is therefore not repeated on every cold start.

What do customers report?

Coinbase VP of Engineering Siwei Shen described the production result in a statement AWS shared: "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 reported figures from an initial comparison of the same natural-language query workload on both runtime versions:

• 35% faster cold starts for inference requests
• 77% faster health-check starts
• 17% lower measured runtime cost per call

Mission Cloud's agent retrieves property and sales insights without requiring users to navigate complex data systems.

What changes in memory billing?

AWS is also changing how memory is billed during idle periods. The runtime reclaims memory within minutes after an agent releases it and scales an idle agent to zero. AWS says multi-turn agents with natural pauses can consume up to 68% less memory per session. That addresses the earlier model's tendency to bill for the session's peak allocation even after the memory was no longer in use.

For always-on agents, committed baseline pricing sets a per-session memory baseline that is billed as a minimum. Agents can burst to four times that level on demand. AWS describes the resulting predictable rate for steady workloads as using AWS Lambda MicroVM rates, while consumption pricing remains available for spiky and scale-to-zero workloads.

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

How does storage and isolation work?

Each session continues to run 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 remains 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 not part of the announced availability. AWS says that by re:Invent, session-labeled credentials will bind each session to its own storage folder, adding a more granular control to the mounting capability.

What limits and caveats apply to V2?

The current V2 documentation carries deployment distinctions that matter for operators planning a migration:

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

Session lifecycles are bounded. Sessions can persist for up to eight hours, but terminate after 15 minutes of inactivity, at the eight-hour lifetime limit, or when unhealthy. Session state is ephemeral: termination destroys the microVM and sanitizes memory.

Why does this matter?

The release ties session compute, memory billing and job data to one managed runtime model. That consolidation is the competitive logic of the update — AWS is positioning AgentCore as the single place where an agent's execution, its cost profile and its data all live under one control plane, rather than leaving teams to assemble warm pools, billing workarounds and storage plumbing themselves.

Its unfinished piece is granular storage isolation. Per-session storage scoping is the remaining step in extending the runtime's isolation guarantee from execution to saved agent work, and AWS has tied that milestone to re:Invent.