Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore | Amazon Web Services
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.
Read original(opens in new tab)