Amazon Bedrock AgentCore Runtime V2 in Context
Amazon Bedrock AgentCore Runtime provides managed execution environments for production AI agents and tools. AWS currently documents two Runtime platform versions: V1 and V2. V1 remains the default when no platform version is specified, while V2 introduces the newer snapshot-based runtime architecture. That distinction matters because several of the most notable recent capabilities, including elastic memory reclamation and more consistent cold-start behavior, are V2 features rather than generic behavior across every Runtime deployment.
Elastic Memory and Cold Starts in Runtime V2
Runtime V2 can reclaim memory as an agent releases it instead of retaining the session’s peak memory allocation for the full compute lifetime. AWS positions this as a way to improve resource efficiency for workloads whose memory needs change during execution.
V2 also changes cold-start behavior. AWS says the platform loads an agent, captures a prepared snapshot, and restores new instances from that snapshot. In AWS testing, this architecture produced relatively consistent cold-start latency across different container image sizes and concurrency levels. These claims should be understood as V2 behavior, not as guarantees for Runtime V1 or as a service-level objective.
Isolation, Identity, and Authentication
For microVM-based execution, each user session receives a dedicated microVM with isolated CPU, memory, and filesystem resources. When the microVM compute is terminated, AWS sanitizes memory before that environment is reused. Runtime-local state is therefore ephemeral unless the application uses an additional persistence mechanism.
Runtime supports IAM SigV4 inbound authentication or JWT Bearer Token authorization, depending on how the runtime is configured. JWT authorizers can integrate with OAuth 2.0 or OIDC-compatible identity providers. These are alternative inbound authorization modes for a runtime configuration rather than two modes that operate simultaneously.
For state that must survive beyond ephemeral runtime memory, AgentCore Memory provides a separate managed memory capability. AWS also documents managed session storage for microVMs and persistent EBS-backed volumes for Runtime Instances, each with different lifecycle rules. For a different approach to private AI memory, see Google’s secure server-side memory design.
Models, Frameworks, and Streaming
AgentCore Runtime is both framework agnostic and model agnostic. AWS documentation identifies support for agents that use Amazon Bedrock models as well as external model providers including Anthropic Claude, OpenAI, and Google Gemini. Runtime also supports streaming partial responses to clients.
AWS has documented a healthcare migration example in which AgentCore Runtime preserves triple-model orchestration and vector-enhanced retrieval while reducing infrastructure-management work. AWS presents that pattern as applicable beyond healthcare, including industries such as financial services and manufacturing.
Observability and Evaluation
AgentCore Observability integrates with Amazon CloudWatch to provide logs, metrics, and traces that can help teams investigate latency, execution bottlenecks, and memory growth in long-running agents. CloudWatch Transaction Search is part of the documented setup for the full AgentCore observability experience; it should not be treated as a universal prerequisite for simply running every AgentCore Runtime workload.
AWS also provides AgentCore Evaluators. When an online evaluation configuration is enabled, evaluation jobs can continuously process incoming traces and produce evaluation results for live agent traffic.
AWS technical guidance uses roughly 200 milliseconds as a target for memory retrieval in interactive scenarios, and AgentCore Memory material reports similar semantic retrieval performance. That number is best read as guidance or a reported performance characteristic, not as a guaranteed service-level objective.
microVMs and Runtime Instances
AgentCore Runtime offers two distinct compute models.
Runtime microVMs provide per-session isolation and are suited to request-driven agent execution. The default idle timeout is 15 minutes, and the default maximum compute lifetime is eight hours. Eight hours describes the lifetime of a running microVM compute environment, not necessarily the lifetime of the logical session identity. A stopped session can later return to an active state when Runtime provisions fresh compute.
Runtime Instances use AWS-managed Amazon EC2 infrastructure in the customer’s AWS account. They are intended for persistent, long-running, collaborative, or specialized-hardware workloads. Multiple agents or agent runtimes can share an Instances session through the same capacity-provider environment and can collaborate using shared filesystem resources. Instances sessions can run for up to 14 days.
Selected Runtime Instances configurations also support GPU or accelerator families, with drivers provisioned by AgentCore.
Session Lifecycle and Persistence
Applications can supply a runtimeSessionId to associate related invocations, and current AWS flows can also provide a session identifier on first invocation when one is not supplied. Reusing the same identifier allows Runtime to route related invocations consistently and preserve session context.
Session states in the newer lifecycle model include Active, Idle, and Stopped. Compute can stop because of inactivity, maximum compute lifetime, an explicit StopRuntimeSession request, or unhealthy compute. A subsequent invocation can provision new compute and return the logical session to an active state.
Persistence depends on the compute type and configuration. Managed session storage for microVMs can survive stop and resume cycles and is isolated per session, although AWS currently documents that feature as Preview and applies its own expiry and version-update rules. Runtime Instances can use persistent EBS volumes that survive compute replacement and can be reattached when new managed EC2 compute is provisioned. AgentCore Memory is a separate managed service for short-term and long-term agent memory and should not be conflated with either filesystem mechanism.
For direct-code deployment, AWS currently lists Python 3.12, 3.13, and 3.14 as the practical current choices. Python 3.11 remains visible in the Runtime table but is already past its documented deprecation and runtime-update-block dates as of September 21, 2026. Container-based deployments follow a different runtime and dependency model.
Regional Availability and Pricing
Regional availability depends on which Runtime capability is being discussed.
General Runtime microVM availability is broader than both Runtime Instances and Runtime V2. Runtime Instances are currently documented in nine Regions: US East (N. Virginia and Ohio), US West (Oregon), Europe (Frankfurt and Ireland), and Asia Pacific (Mumbai, Singapore, Sydney, and Tokyo).
Runtime V2 has a narrower footprint. AWS currently documents V2 in US East (N. Virginia and Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo). Teams evaluating elastic memory reclamation or V2’s snapshot-based cold-start behavior should therefore verify V2 availability specifically rather than relying on the broader Runtime or Runtime Instances region lists.
Pricing also depends on the compute model. Runtime microVMs use consumption-based pricing. Runtime Instances use underlying EC2 compute in the customer’s AWS account plus an AgentCore management fee. Persistent EBS storage and network transfer can add separate charges. The EC2-plus-management-fee description therefore applies to Runtime Instances, not to AgentCore Runtime universally.
What Teams Should Check Before Deploying
AgentCore Runtime now spans multiple platform versions and compute models, so architecture choices need to be made explicitly. Teams evaluating the service should decide whether they need Runtime V2 features, microVM isolation, long-running Runtime Instances, durable filesystem storage, AgentCore Memory, GPU support, or continuous evaluation, then verify the lifecycle, pricing, and regional constraints that apply to that specific combination.
The key point is that “AgentCore Runtime” is no longer a single uniform execution profile. V1 and V2, microVMs and Instances, and the available persistence options each have different operational characteristics. Keeping those boundaries clear is essential when evaluating the service for production workloads.
Sources
- The new AgentCore runtime: Elastic, optimized, and consistently fast starts
- Securely launch and scale your agents and tools on Amazon Bedrock AgentCore Runtime
- Optimizing production agents with Amazon Bedrock AgentCore Observability
Explore more AI Agents coverage.
Leave a Reply