Amazon launches runtime instances for Bedrock agents

Amazon Web Services has introduced runtime instances in Amazon Bedrock AgentCore Runtime, aimed at production AI agents that need persistent managed compute.

The service provides AWS-managed EC2 infrastructure for deploying multiple agents in a single runtime, with shared sessions that can persist for up to 14 days. It sits alongside AgentCore runtime microVMs, which support invocations of up to eight hours through managed session storage.

Runtime instances are designed for workloads in which agents must run continuously for several days, coordinate with other agents on the same host, or use GPUs for heavier processing. The service also supports session stop and restart, allowing teams to suspend environments during idle periods and resume them later with state intact.

Customers can deploy several agents in one runtime while keeping separate dependencies and artefact types for each. Agents can also call one another as tools within a shared session, using the same host and file system instead of passing data through external transfers or separate application programming interfaces.

That marks a shift from earlier approaches, in which users had to assemble the underlying infrastructure themselves. Teams typically provisioned EC2 instances, configured networking, set up session management and scaling, and connected monitoring tools around the workloads.

Runtime instances use the same AgentCore APIs, identity controls and observability features as AgentCore runtime microVMs. The two compute options can be used separately or together, including in setups where a lightweight orchestrator agent running in a microVM dispatches tasks to worker agents running on instances.

How it works

In an example published alongside the launch, AWS described a two-agent workflow built in Python using Strands Agents. One agent generated Python code from a natural-language prompt, while a second reviewed the resulting file for bugs, style issues and suggested improvements.

Both agents ran on the same underlying infrastructure and used a shared session directory. That allowed the reviewer to read the code written by the first agent directly from the file system, without direct messaging between the two.

The example used a capacity provider based on 64-bit Arm Linux and an allowed instance type of c7g.2xlarge, with eight vCPUs and 16 GiB of memory. Capacity providers define the EC2 infrastructure on which the agents run, including operating system, instance types, networking and storage configuration.

Developers can package agents as zip files or container images. Supported runtimes at launch include Python 3.11 through 3.14 with native code support, and the service supports both Arm64 and x86_64 Linux environments.

Shared sessions

The launch reflects growing demand for AI agent systems that maintain state across long-running tasks rather than responding to one-off prompts. In practical terms, that can include software development flows, security reviews, GUI automation and other multi-step processes that require continuity across hours or days.

Shared sessions can persist for up to 14 days, extending the time window available through AgentCore runtime microVMs. For data that must outlive a session, runtime instances can be paired with Amazon Elastic Block Store and AgentCore Memory for longer-term retention across sessions and environments.

The service also supports GPU-backed instance types for jobs that need additional compute resources. AWS positioned that as relevant for specialist tasks in which agents need direct operating system access or local coordination with other agents on the same host.

Pricing and regions

Pricing is based on standard EC2 charges plus a management fee for AgentCore orchestration. The service is available in US East in Ohio and North Virginia, US West in Oregon, Asia Pacific in Mumbai, Singapore, Sydney and Tokyo, and Europe in Frankfurt and Ireland.

The demonstration showed the writer agent creating a Python file in a shared session path and the reviewer agent reading the same file after the user entered the same session ID. AWS said the two agents "collaborated through the shared file system that runtime instances provide within a session."