AWS upgrades AgentCore runtime with bigger sessions and scale-to-zero agents

What AWS announced on November 12

AWS announced an upgraded Amazon Bedrock AgentCore runtime on November 12, 2026, with larger isolated sessions, faster startup and memory management intended to reduce idle-agent costs. Sessions can now reach 8 vCPUs and 32 GB of memory, and accept container images up to 10 GB. AWS says the next-generation runtime is available today in regions across North America, South America, Europe and Asia Pacific; the announcement does not enumerate every supported region.

This is an execution-platform update for AI agents, not a new foundation model or a new model API identifier. AgentCore hosts the program that calls models, executes tools and maintains a session. AWS’s product page describes support for frameworks including LangChain, OpenAI Agents SDK, Claude Agent SDK and Strands SDK, as well as custom frameworks. That flexibility does not establish compatibility for every dependency in an existing container.

The immediate decision is whether agents that compile code, drive browsers or wait between user turns now fit managed hosting better than a custom sandbox fleet. The launch changes the resource and idle-capacity trade-off; it does not by itself make a more capable or more trustworthy agent.

Larger sessions without maintaining a warm pool

AWS describes the new compute ceiling as four times the previous version and says sessions start in under two seconds regardless of image size and concurrency. Its headline also claims startup up to 15 times faster. These are AWS performance claims, not AccessAllGPT measurements or a service-level guarantee established by this briefing.

The larger envelope matters for a coding agent whose dependencies or compilation exceed a small sandbox, or a browser agent that needs more memory. AWS also names local model inference as a possible workload, but this announcement does not establish GPU availability, accelerator support or inference throughput. An 8-vCPU ceiling should not be read as a claim that a particular model will serve efficiently.

Our analysis: test startup through the first useful tool result, not just the creation of a session. Image initialization, dependency loading, model calls and remote tools all contribute to the delay a user experiences. A fast runtime start cannot remove waiting elsewhere in the workflow.

Scale-to-zero changes the idle-cost calculation

AWS says the runtime reclaims memory within minutes after an agent releases it, and an idle agent scales to zero. For multi-turn agents with natural pauses, it reports up to 68% less memory consumed per session. That is a memory-consumption claim, not a measured reduction in total task cost: model inference, external tools and other services still need their own accounting.

For always-on workloads, AWS describes committed baseline pricing: a memory baseline per session is billed as a minimum, with bursts up to four times that baseline. The announcement refers to AWS Lambda MicroVM rates but does not give a region-specific numerical tariff. We have not verified a quote, billing export or the applicable settings for an existing deployment.

These are different utilization choices. A bursty assistant may benefit from releasing memory between turns; a continuously active worker may prefer predictable baseline capacity. Compare the actual idle pattern and minimum commitment before assuming that either option is cheaper. A customer saving quoted in AWS’s announcement is evidence of that customer’s reported workload, not a forecast for yours.

Filesystem support is here; folder scoping is a future commitment

AWS says each session continues to run in its own hardware-isolated Firecracker micro virtual machine, with its own identity, policy and audit trail. The update lets agents dynamically mount and save work to a filesystem, including an Amazon S3 bucket with FUSE support. Those statements describe the platform’s execution and storage design; we have not independently tested isolation.

An important qualification appears near the end of the announcement: AWS says that by re:Invent, per-session scoping will bind each session to its own storage folder through session-labeled credentials. That is a future commitment. Do not treat folder-specific credential binding as a feature already shipped just because dynamic mounting is available.

For a coding or document agent, persistent work can make a session more useful without copying every artifact through the application. But the allowed bucket, prefix, credentials and cleanup rules still need review. Runtime isolation does not prove that the agent has permission to every file it can reach or that a requested external action is appropriate.

What builders should try next

Choose one non-sensitive agent workload that is currently constrained by startup, memory or idle cost. Keep the model, task inputs and acceptance tests unchanged, and compare the existing deployment with the new runtime. Include a cold session, a busy period and a pause-and-resume case. Record completed-task latency, peak and reclaimed memory, failures and all billed services.

Before a broader rollout, confirm that the target region exposes the required configuration and quotas, and verify how workspace persistence behaves under the storage permissions actually granted. If the design depends on automatic per-session storage-folder scoping, wait for a separate availability record rather than implementing against the roadmap sentence. This is a proposed evaluation, not an experiment AccessAllGPT has run.

Disclosures

AccessAllGPT received no payment, credits or private access for this briefing. AWS did not review or endorse it. AccessAllGPT Research is operated by NeuralArc, is independent and is not affiliated with AWS. Publication-wide relationships are listed on the disclosures page.