AWS AgentCore Runtime Adds Larger 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. AWS reports that the updates deliver up to 15 times faster session starts while retaining hardware isolation.

The updated runtime is available in AWS Regions across North America, South America, Europe and Asia Pacific. 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 release follows the September 18, 2026, introduction of AgentCore Runtime V2, which brought snapshot-based starts and memory reclamation. AWS had then listed larger compute and storage and committed baseline pricing as coming soon; those capabilities now form much of the update, alongside filesystem mounting.

Larger Sessions Without Warm Pools

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 and that 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 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, so work such as loading model artifacts and fetching static configuration is not repeated on every cold start.

Coinbase VP of Engineering Siwei Shen described the production result: “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 that an initial comparison of the same natural-language query workload on both runtime versions produced 35% faster cold starts for inference requests, 77% faster health-check starts and 17% lower measured runtime cost per call. Its agent retrieves property and sales insights without requiring users to navigate complex data systems.

Memory Reclamation and Baseline 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 and allows bursts to four times that level on demand. AWS describes the resulting predictable rate for steady workloads as using AWS Lambda MicroVM rates; consumption pricing remains 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.

Storage, Isolation and Deployment Limits

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.

There are also deployment distinctions in the current V2 documentation. 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, and the container must report healthy through its /ping endpoint within 120 seconds. Those setup times are separate from session cold-start latency.

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

The release ties session compute, memory billing and job data to one managed runtime model. 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.