AWS expands Bedrock AgentCore runtime capacity for AI agents

By Amara Osei

AWS now supports Amazon Bedrock AgentCore runtime sessions with up to eight virtual CPUs (vCPUs) and 32GB of memory, providing as much as four times the compute of the previous version, the company said Thursday. The upgrade also brings startup times below two seconds, regardless of container image size, and accepts container images up to 10GB.

AWS positions the runtime-layer upgrade as a way for enterprises to deploy and scale agents faster and with lower runtime costs.

What changed in the AgentCore runtime?

AWS says the larger sessions can support demanding workloads, including large codebase compilations, browser-driven workflows and local model inference. The runtime can also reclaim unused memory within minutes after an agent releases it and scale idle agents to zero.

Those controls reduce resources consumed while agents wait for model responses, tool calls or human intervention. For multi-turn agents with natural pauses between interactions, AWS expects memory consumption per session to fall by as much as 68%.

Developers can dynamically mount and save the data agents access and generate to file systems, including Amazon S3 buckets, through FUSE support. Before the update, enterprises had to build their own mechanisms for moving files, credentials and tool outputs between an agent’s isolated environment and external storage.

In plain terms, AWS has made isolated agents larger, cheaper to idle and easier to connect to enterprise data.

How do faster sessions change development?

Ashish Chaturvedi, executive research leader at HFS Research, said coding agents that compile large codebases, browser agents that load full web pages and agents running small models locally had outgrown the earlier session size. Developers had to split those jobs awkwardly or move them outside the isolated environment. The new 8 vCPU, 32GB and 10GB-image limits let the workloads remain inside the secure boundary.

Startup time changes the economics of provisioning. A fresh isolated session that takes nearly a minute forces developers to maintain warm pools of pre-provisioned capacity, even when those resources sit idle. Chaturvedi said: “With startup times of under two seconds, regardless of container image size, developers can provision isolated sessions on demand rather than maintaining idle capacity.”

Memory reclamation and scale-to-zero also remove some custom inactivity handling. Developers no longer need to write their own logic to shut down sessions, save state and restart for multi-turn or long-running agents.

Developers can spend less time managing idle infrastructure and workarounds for complex agent sessions.

Can scale-to-zero pricing lower CIO costs?

AWS introduced baseline pricing with the updates to support always-on agents. The model sets a minimum memory allocation for each session and permits burst capacity up to four times that baseline. AWS says the arrangement gives enterprises pricing predictability: they can keep sessions available without paying for peak capacity upfront, then add capacity as demand increases.

Stephanie Walter, practice leader of AI stack at HyperFRAME Research, said agents generally need fewer resources while waiting for approval than while executing code. Reclaiming memory and scaling idle sessions to zero could therefore lower the cost of keeping long-running agents available.

Walter added: “And since enterprises are likely to run hundreds of concurrent agent sessions, particularly agents that spend considerable time waiting for model responses, tool calls or human intervention, reducing resource consumption can be a material change.”

Improved resource efficiency should also help developers manage workflows more effectively, deploy agents faster and extend their use across business functions more quickly, Walter said.

For CIOs, efficient idling can lower the bill, but only for the runtime resources the service actually reclaims.

What trade-offs should CIOs test?

Walter warned that scale-to-zero does not eliminate all charges. Storage, model calls, external tools and other services can still incur costs, so teams should test whether files remain available after resume, whether credentials have expired and whether the agent knows its last action completed. A restart that repeats a payment or production change would erase much of the saving.

Chaturvedi also cautioned that resuming an agent can add latency, making scale-to-zero a poor choice for latency-sensitive agents. He further warned that low idle costs may encourage enterprises to leave unnecessary long-running agents in place indefinitely.

Those agents can retain permissions and access to enterprise resources, so regular reviews of agent access and deployment remain necessary. Baseline sizing adds another trade-off. A high baseline means paying for unused capacity across sessions; a low baseline makes frequent bursts less predictable and may weaken the case for committing to one.

CIOs should assess actual workload patterns, confirm how burst capacity is billed and monitor usage after deployment. Chaturvedi said stable resource requirements suit baseline pricing best, while unpredictable or experimental workloads may work better with usage-based pricing.

Scale-to-zero saves runtime resources, but cost control still depends on accurate baselines, tested resumes and active access reviews.

Where can enterprises use the update?

AWS has made the updated capabilities available across 19 AWS Regions: N. Virginia, Ohio, Oregon, Canada, São Paulo, Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Malaysia, Mumbai, Seoul, Singapore, Sydney, Thailand and Tokyo.

The release gives enterprises more room to run complex agents, but its savings depend on workload fit and disciplined operations.