Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore | Amazon Web Services (opens in new tab)

Amazon Bedrock AgentCore Runtime Instances provides persistent, managed compute for production AI agents that need more than short-lived invocations. It supports multi-day workflows, shared state, GPU acceleration, multi-agent collaboration, and direct OS access while AWS manages the underlying EC2 infrastructure. Runtime Instances complements AgentCore’s lightweight microVMs, enabling teams to combine fast-scaling orchestration with persistent worker environments.

Why Persistent Compute Matters

• Production agents often run for hours or days and must preserve state across workflow steps.
• Complex systems may require:
  • Collaboration between multiple agents
  • Shared files and context
  • GPU acceleration
  • Direct operating-system access
  • Continuous execution across multiple days
• Previously, teams had to provision EC2 instances, configure networking, manage sessions and scaling, and build monitoring themselves.

What Runtime Instances Provides

• AWS-managed EC2 infrastructure for hosting multiple agents in one runtime.
• Shared sessions that persist for up to 14 days.
• Separate dependencies and artifacts for each deployed agent.
• GPU-capable infrastructure for compute-intensive workloads.
• Session stop and restart capabilities to reduce idle costs.
• Support for zip packages and container images.
• Compatibility with frameworks such as CrewAI, LangGraph, LlamaIndex, and Strands.
• Integration with existing AgentCore APIs, identity controls, and observability.
• Persistent knowledge storage through Amazon EBS and AgentCore Memory.

Combining MicroVMs and Runtime Instances

• Runtime microVMs remain useful for lightweight orchestrator agents that need rapid scaling.
• Runtime Instances are better suited to persistent, resource-intensive workers.
• An orchestrator can:
  • Route tasks to specialized agents
  • Make API calls
  • Aggregate results
• Instance-based workers can handle tasks such as code compilation, security scanning, or GUI automation while retaining local state.

Shared-Filesystem Agent Example

The demonstration uses two Strands Agents applications:

• A code writer:
  • Generates Python code from a natural-language task.
  • Saves the result as code.py in a session-specific shared directory.
• A code reviewer:
  • Reads the writer’s file from the same filesystem.
  • Reviews it for bugs, style issues, and suggestions.
• Both applications use:
  • An @app.entrypoint decorator
  • A selected Bedrock model
  • The session ID to identify shared storage
• Because both agents share the host filesystem, they exchange artifacts without API calls or explicit data transfer.

Deployment Workflow

Create a Capacity Provider

• Select the operating system, allowed EC2 instance types, VPC, subnets, and security groups.
• The example uses:
  • Linux 64-bit ARM
  • c7g.2xlarge
  • 8 vCPUs and 16 GiB of memory
  • A default gp3 volume
• AgentCore creates or assigns the required infrastructure role and instance profile.
• Once active, most capacity provider settings cannot be changed, so configuration should be verified beforehand.

Create a Runtime and Deploy an Agent

• Create a runtime using the Instances compute type.
• Associate it with the capacity provider.
• Upload the agent package to Amazon S3.
• Specify the language runtime, such as Python 3.13, and the entry-point file containing @app.entrypoint.
• Deployment can be performed through the AWS Management Console, AgentCore CLI, AWS CLI, or infrastructure as code.

Runtime Instances are a strong fit for agents with long-running, stateful, collaborative, or compute-heavy workloads. Use them alongside microVMs when a system needs both elastic orchestration and persistent worker infrastructure, while relying on EBS or AgentCore Memory for state that must outlive individual sessions.