AgentCore Runtime Instances: What Changes When Your Agents Stop Being Stateless

Amazon Bedrock AgentCore just got a second compute option, and it's a meaningfully different one. Since its GA, AgentCore Runtime has run agents on "microVMs" — fast-spinning, ephemeral, stateless-by-default virtual machines. That model is a good fit for short, bursty agent interactions. It is not a good fit for an agent that needs to run for two days, hold state across dozens of steps, coordinate with other agents, or use a GPU.

Runtime Instances is AWS's answer to that gap. It's not a replacement for microVMs — both compute modes sit behind the same AgentCore Runtime APIs, and you pick whichever fits the workload. But it's a real architectural departure, and it's worth understanding both what it enables and what it quietly changes about how your AWS bill reads.

The problem this solves

The original AgentCore Runtime model optimizes for elasticity: spin up fast, handle the request, tear down. Its constraints reflect that design:

• Sessions cap out at 8 hours.
• State is not assumed to persist — you lean on managed session storage if you need continuity.
• No GPU-backed instance types.
• No native way for multiple agents to share state on the same host; coordination happens through APIs.

For a lot of agent workloads, none of that matters. But for long-running workflows, multi-agent systems that need to collaborate closely, or anything computationally heavy enough to want a GPU, those constraints are a hard ceiling. Historically, the answer was to step outside AgentCore entirely — provision your own EC2 instances, wire up networking, build your own session management and scaling, stitch together monitoring. AWS's own framing of the gap: teams needing this "had to build and manage that infrastructure yourself."

Runtime Instances is AWS building that infrastructure for you, inside AgentCore.

What Runtime Instances actually are

The clearest way to see the shift is side by side:

	microVMs	Runtime Instances
Session duration	Up to 8 hours	Up to 14 days
State model	Managed session storage	Shared filesystem across co-located agents
Hardware	Abstracted	GPU-accelerated types supported; direct OS access possible
Deployment	Serverless, ephemeral	Persistent, containerized or zip-based
Scaling behavior	Fast auto-scaling	Reserved, persistent allocation

Both are invoked through the same runtime ARN and the same InvokeAgentRuntime call with a runtimeSessionId — from the calling code's perspective, the interface doesn't change. What changes is what's running underneath, and what it's capable of holding onto.

How state persistence actually works

Runtime Instances give agents a few different ways to hold onto state across a long-running session:

• Shared session storage: co-located agents can read and write to a shared filesystem at a path like /tmp/agentcore-session/{session_id}/, letting multiple agents on the same host coordinate directly instead of going through API calls to talk to each other.
• Longer-term recall: integration with Amazon EBS and AgentCore Memory extends that beyond the life of a single session.
• Hibernation: a workflow can be paused mid-flight and picked back up later — AWS's own example is starting something Monday night and resuming it Wednesday morning with everything intact.

Practically, this is the feature set that makes a genuinely long-running or multi-agent workflow possible without you building the state layer yourself.

The infrastructure reality: it's EC2 underneath

Here's the part that's easy to miss if you only read the feature announcement: Runtime Instances are, physically, real EC2 instances running in your account.

They're not hidden behind some abstracted AgentCore-only resource type — they show up in the EC2 API and console. AWS's own docs are explicit about how to spot them: you can identify a Runtime Instance in DescribeInstances output by its Operator field, plus an AgentCore capacity-provider tag applied to the instance. What is different is default visibility: these managed instances are hidden from your normal EC2 console views and list operations unless you explicitly turn on the "managed resource visibility" setting. Turn that off (the default), and they're invisible unless you go looking — but they're "fully operational and billable in your account" the entire time.

On the AgentCore side, there isn't a separate ARN namespace for "instances" or "capacity providers" in what AWS has published. You still invoke and manage everything through the same bedrock-agentcore runtime ARN:

arn:aws:bedrock-agentcore:<region>:<account-id>:runtime/<name>-<suffix>

The instance-level detail — which EC2 host, which capacity provider — lives underneath that ARN, not alongside it as its own addressable resource.

What it means for your bill

Pricing for Runtime Instances is two components, and AWS states both plainly: "Standard EC2 pricing plus a management fee for AgentCore orchestration." The EC2 portion bills at your normal EC2 On-Demand rates for whatever instance type you chose (AWS's own walkthrough uses a c7g.2xlarge as the example). The management fee is calculated as a percentage of that same public EC2 On-Demand price — a markup for the orchestration layer, not a flat add-on.

So a rough monthly estimate for a single always-on Runtime Instance is: (EC2 On-Demand hourly rate × hours running) + (management fee % × that same EC2 cost). For something running continuously all month, that's a very different cost profile than per-invocation microVM billing — you're now paying for reserved, persistent capacity whether or not it's actively doing work in every hour.

And here's the part worth sitting with if you're the one explaining the bill: this quietly changes what "EC2 spend" means in your account. Historically, your EC2 line item has been a reasonably clean signal — it's the compute you or your team explicitly provisioned for applications, servers, batch jobs, whatever. Now, some fraction of that EC2 spend can be AI-agent infrastructure, tagged and billed as EC2, sitting behind AgentCore's abstraction. It's identifiable — the Operator field and the capacity-provider tag are there — but it's not visible by default, and it's not going to show up as its own distinct category unless someone specifically knows to filter for it. Anyone doing cost allocation, chargeback, or just a normal "why did EC2 go up this month" review now has a new thing hiding inside a familiar bucket. The category didn't get a new name; it got absorbed into an existing one.

Where this fits, and where it doesn't

Runtime Instances make sense when:

• A workflow genuinely needs to run longer than 8 hours or spans multiple sessions with state carried between them.
• You have multiple agents that need to collaborate closely on shared state, not just exchange messages.
• The workload needs a GPU or benefits from more direct hardware access than the microVM abstraction allows.

They're not the right fit — yet, or at all — for short, bursty, stateless interactions, which is exactly what the original microVM model already handles well and cheaply. Reaching for persistent instances by default for workloads that don't need the 14-day session ceiling just trades cheap per-invocation billing for reserved-capacity billing with nothing to show for it.

Limits worth knowing before you adopt it

A few practical constraints as of GA:

• Regions: available in eight regions at launch — US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland). Not global yet.
• OS/runtime: Linux only (ARM64 and x86_64) at launch, with Python 3.11–14 or container images as the deployment options.
• Configuration lock-in: once a capacity provider is created, only its description remains editable — the underlying infrastructure choices are effectively fixed after deployment. Plan the instance type and configuration carefully up front.

The bigger picture

This is the same "serverless for bursty, persistent for stateful" split that's played out across compute generally (Lambda vs. EC2, Fargate vs. self-managed clusters) now showing up one layer up, inside a managed agent platform. What makes it worth paying attention to isn't just the new capability — it's that the persistent option arrives wearing an EC2 costume, which means the usual instinct to read "EC2 spend" as "traditional infrastructure spend" no longer holds without a closer look.

---

Sources: AWS News Blog — Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore, AWS — AgentCore Runtime Instances GA announcement, AWS Docs — Instances (AgentCore devguide), AWS — Bedrock AgentCore Pricing