---
title: AgentCore Runtime Instances GA: When to Leave microVM for EC2 Capacity Providers
description: On Aug 6, 2026 AgentCore Runtime Instances went GA — EC2-backed agents with sessions up to 14 days vs 8-hour microVM Runtime. Field guide: capacity providers, GPU fit, and when idle EC2 burns more than serverless.
url: https://www.factualminds.com/blog/amazon-bedrock-agentcore-runtime-instances-ga-2026/
datePublished: 2026-08-07T00:00:00.000Z
dateModified: 2026-08-07T00:00:00.000Z
author: palaniappan-p
category: Generative AI
tags: bedrock, agentcore, ai-agents, ec2, llm-ops
---

# AgentCore Runtime Instances GA: When to Leave microVM for EC2 Capacity Providers

> On Aug 6, 2026 AgentCore Runtime Instances went GA — EC2-backed agents with sessions up to 14 days vs 8-hour microVM Runtime. Field guide: capacity providers, GPU fit, and when idle EC2 burns more than serverless.

On **August 6, 2026**, AWS [announced general availability](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/) of **AgentCore runtime instances** — a new compute option in Amazon Bedrock AgentCore that runs agents on **your chosen Amazon EC2 instance types** while AgentCore still provisions, patches, scales, and manages lifecycle. Runtime Instances complement the existing **microVM-based** Runtime: same deploy and invoke paths, different substrate.

If your agents are short, bursty chat turns, this is not a fire drill — **stay on microVM**. If you are building research loops, multi-day batch agents, or GPU-backed tool chains, this is the moment to stop forcing those jobs into an **8-hour** microVM design point.

This post is the adoption guide only: microVM vs Runtime Instances, capacity providers, cost shape, and a Monday canary. Platform map, Memory/Gateway/Identity, and Classic cutover stay in the [AgentCore production guide](/blog/amazon-bedrock-agentcore-production/). Bill lines stay in the [12-components pricing post](/blog/amazon-bedrock-agentcore-pricing-12-components/).

> **First-party signals we reuse here** — Gateway canary on a **B2B CRM assistant** (12 tools, ~8k turns/day): median tool round-trip **~180 ms → ~95 ms** after server-side Gateway ([Gateway post](/blog/amazon-bedrock-agentcore-gateway-server-side-tool-execution-2026/)). First-party TCO silhouette (July 2026): **~500-employee** Quick Suite stack **~$3,580/mo** vs AgentCore support-style agent at **50K sessions/mo ~$791/mo** platform + Haiku-like inference ([decision guide](/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)). Those agents are microVM-shaped; Runtime Instances change the compute unit, not the Gateway or seat math.

> **Reproduce this** — Score [`runtime-instances-decision-matrix.md`](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/runtime-instances-decision-matrix.md). Run the canary steps in [`microvm-vs-runtime-instances-canary-checklist.md`](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/microvm-vs-runtime-instances-canary-checklist.md). Model AgentCore Runtime lines on the [AgentCore pricing calculator](/tools/amazon-bedrock-agentcore-pricing-calculator/) (list rates as of **2026-07-04**, us-east-1) and add EC2 On-Demand for the candidate instance type as a separate line.

---

## What AWS shipped on August 6, 2026

| Dimension                | microVM Runtime (default)            | Runtime Instances (GA)                                      |
| ------------------------ | ------------------------------------ | ----------------------------------------------------------- |
| **Session design point** | Up to **8 hours**, fast startup      | Up to **14 days**                                           |
| **Hardware**             | Purpose-built microVM isolation      | EC2 families you specify (GPU, memory-, compute-optimized)  |
| **Ops**                  | Serverless-style active compute      | AgentCore manages EC2 lifecycle; you pick capacity          |
| **Cost shape**           | Primarily active vCPU-hour / GB-hour | **EC2 hours + AgentCore management** of provisioned compute |
| **Best fit**             | Bursty, short-session product agents | Sustained, specialized-hardware, or long-wall-clock agents  |

**Regions (GA):** US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland).

**Opinionated take:** Default every net-new agent to **microVM Runtime**. Graduate to Runtime Instances only when session wall-clock, specialized hardware, or sustained CPU/GPU utilization makes microVM the wrong unit — not because EC2 “feels more production.”

---

## Capacity providers — the mental model

Using the Console, CLI, SDKs, or APIs you:

1. Create a **capacity provider** that lists the EC2 instance types the agent needs.
2. **Attach** one or more agents to that provider.
3. Keep deploying and invoking the same way — AWS positions Runtime Instances as a compute choice, not a new agent product.

Think of the capacity provider as a **hardware profile** for AgentCore Runtime, not a DIY Auto Scaling Group you patch yourself. AgentCore still owns provisioning, patching, scaling, and lifecycle; you own the instance-type decision and the FinOps review of idle capacity.

```
  Agent (same InvokeAgentRuntime path)
           │
           ├─► microVM Runtime ──► sessions ≤ 8h, fast start
           │
           └─► Runtime Instances ──► capacity provider
                    │
                    └─► EC2 types (g*, r*, c*, …)
                         + AgentCore management charge
```

---

## Cost honesty: two lines, not one

AWS is explicit: you are charged for **management of the compute provisioned**, **in addition to** Amazon EC2 costs. Teams that only price EC2 On-Demand will under-forecast.

| Line               | What to track                                                                                            |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| **EC2**            | Instance hours (and any RI/SP) for the capacity provider                                                 |
| **AgentCore**      | Runtime / platform metering — see [12 components](/blog/amazon-bedrock-agentcore-pricing-12-components/) |
| **Bedrock models** | Tokens — usually still the largest line                                                                  |

> **Benchmark pattern (not a cited client)** — Modeled a long-running document-research agent: **~120 sessions/day**, median wall-clock **6.5 hours**, peak **11 hours** (would break an 8-hour microVM design), **us-east-1**. On microVM the active-compute story fails past 8 hours. On a single **g5.xlarge**-class capacity profile, EC2 On-Demand alone is on the order of **~$1/hour** while the instance is up — so a poorly scaled always-on GPU canary can burn **hundreds of dollars per day** before AgentCore management and model tokens. The win condition is **$/completed research session** with measured GPU utilization, not “we have GPUs now.”

Normalize every canary to **$/successful session**. If idle EC2 capacity dominates, you picked the wrong substrate (or the wrong size).

---

## When Runtime Instances win — and when they do not

**Choose Runtime Instances when:**

- Sessions need wall-clock beyond the microVM **8-hour** design point (up to **14 days**).
- You need **GPU** or an EC2 family microVM cannot express.
- Compute is **sustained** (hours of active CPU/GPU per day), not chat bursts.

**Stay on microVM when:**

- Sessions are minutes to a few hours with fast-startup sensitivity.
- Traffic is bursty and you want pay-for-active-compute economics.
- You have not yet measured a hardware bottleneck — do not “upgrade” on vibes.

> **What broke** — Pattern failure we see in design reviews: a bursty customer-support agent (**~50K sessions/mo**, median active **~3–5 seconds** per turn — the shape from our [Quick Suite vs AgentCore TCO](/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)) gets pinned to always-on GPU Runtime Instances “for future multimodal tools.” Overnight idle windows show **GPU utilization near zero**; EC2 hours dwarf the prior microVM Runtime line. **Detection:** Cost Explorer split by tag `MigrationWave=agentcore-runtime-instances-canary` after 72 hours. **Fix:** keep that agent on microVM; reserve Runtime Instances for the research/batch agent that actually needs multi-hour wall-clock. **Lesson:** 14-day session support is a capability ceiling, not a target utilization.

---

## Canary without rewriting the product API

Assumes the agent already runs on AgentCore Runtime. Full Harness vs Runtime and Classic cutover: [production guide](/blog/amazon-bedrock-agentcore-production/).

1. **Baseline (Day 0)** — session duration histogram, active vCPU/GB, tool errors, $/successful session on microVM.
2. **Score** — [decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/runtime-instances-decision-matrix.md); proceed if sum ≥ 14 or hard GPU / >8h requirement.
3. **Canary (72 hours)** — one agent on a capacity provider; include overnight idle; tag for Cost Explorer ([checklist](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/microvm-vs-runtime-instances-canary-checklist.md)).
4. **Promote or park** — promote only agents that share the hardware profile; keep microVM for short-session fleets.

---

## What This Post Doesn't Cover

- **Full AgentCore platform map** (Harness, Memory, Gateway, Identity, Observability) — [production guide](/blog/amazon-bedrock-agentcore-production/).
- **Per-component unit prices** — [12-components post](/blog/amazon-bedrock-agentcore-pricing-12-components/) and the [pricing calculator](/tools/amazon-bedrock-agentcore-pricing-calculator/).
- **AgentCore vs Amazon Quick Suite seat TCO** — [decision guide](/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/).
- **Exact AgentCore management rate card for Runtime Instances** — verify on the [AgentCore pricing page](https://aws.amazon.com/bedrock/agentcore/pricing/) for your Region; this post treats it as a mandatory second line, not a published unit table.
- **Hands-on GPU utilization numbers in your account** — run the canary checklist; we published a modeled idle-burn pattern, not your CloudWatch.

---

## What to Do This Week

1. **Inventory** agents by median and p95 session duration — flag any approaching or exceeding **8 hours**.
2. **Score** each candidate with the [decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/runtime-instances-decision-matrix.md) — pilot if sum ≥ 14.
3. **Model** AgentCore Runtime + candidate EC2 On-Demand before creating a capacity provider; reject GPU unless utilization will be measured.
4. **Canary** one non-prod agent for **72 hours** with overnight idle windows using the [checklist](https://www.factualminds.com/examples/architecture-blog-2026/agentcore-runtime-instances/microvm-vs-runtime-instances-canary-checklist.md).
5. **Compare $/successful session** — promote only if Runtime Instances beat microVM on that metric for a real hardware or session-length reason.

Need help choosing microVM vs Runtime Instances for a production agent fleet? [Contact FactualMinds](/contact-us/) — AWS Select Tier Partner with Bedrock AgentCore delivery across SaaS and regulated workloads — or start from [generative AI on AWS](/services/generative-ai-on-aws/).

---

## Related reading

- [Amazon Bedrock AgentCore: Production Guide](/blog/amazon-bedrock-agentcore-production/)
- [AgentCore Pricing: The 12 Components](/blog/amazon-bedrock-agentcore-pricing-12-components/)
- [AgentCore Gateway Server-Side Tool Execution](/blog/amazon-bedrock-agentcore-gateway-server-side-tool-execution-2026/)
- [Bedrock AgentCore vs Amazon Q: Decision Framework](/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)
- [AgentCore pricing calculator](/tools/amazon-bedrock-agentcore-pricing-calculator/)

## FAQ

### What are AgentCore Runtime Instances?
Announced generally available on August 6, 2026, Runtime Instances let you run Amazon Bedrock AgentCore agents on Amazon EC2 instance types you choose (via a capacity provider) while AgentCore still handles provisioning, patching, scaling, and lifecycle. They complement the default serverless microVM Runtime — same deploy and invoke paths, different compute substrate.

### How long can Runtime Instance sessions run versus microVM Runtime?
Per the AWS announcement, Runtime Instances support long-running agent sessions of up to 14 days. The default serverless microVM Runtime is designed for sessions of up to 8 hours with fast startup. If your wall-clock never approaches 8 hours, microVM is usually the better default.

### When should I choose Runtime Instances over microVM Runtime?
Choose Runtime Instances when you need sustained or resource-intensive agents, specialized hardware (GPU, memory-optimized, or compute-optimized EC2 families), or session lengths beyond the microVM 8-hour design point. Stay on microVM for bursty, short-session agents that benefit from fast startup and pay-for-active-compute economics.

### When should I NOT move an agent to Runtime Instances?
Do not move if: (1) sessions are short chat turns and cold-start sensitivity matters more than custom hardware, (2) you have not modeled idle EC2 hours against microVM active vCPU/GB-hour, (3) your Region is outside the Aug 6, 2026 GA list, or (4) you are selecting GPU “just in case” without measured GPU utilization. Idle capacity is the common bill surprise.

### How are Runtime Instances billed?
AWS charges for management of the provisioned compute in addition to Amazon EC2 costs. Treat them as two Cost Explorer lines: EC2 instance hours for the capacity provider, plus AgentCore platform metering for Runtime. Model AgentCore lines on the AgentCore pricing calculator; do not assume EC2 On-Demand alone is the full bill.

### Do I need to change how I deploy or invoke agents?
Per AWS, you create a capacity provider with the EC2 instance types your agents need, attach agents to it, and continue using the same Console, CLI, SDK, or API deploy/invoke paths. The point of Runtime Instances is hardware choice without rewriting the agent control plane.

### Can I mix microVM Runtime and Runtime Instances?
Yes. Run a mix — short-session product agents on microVM, long-running or GPU agents on Runtime Instances — without changing how you deploy or invoke each agent. Mixed fleets are the normal production shape, not an edge case.

### What could go wrong after adopting Runtime Instances?
Common failures: pinning a bursty support chatbot onto always-on GPU instances (idle burn), assuming 14-day session support means you should keep sessions warm for days (Memory and model cost compound), underestimating AgentCore management charges on top of EC2, and canarying in a non-GA Region. Score the decision matrix and run a 72-hour canary with overnight idle windows before promoting.

---

*Source: https://www.factualminds.com/blog/amazon-bedrock-agentcore-runtime-instances-ga-2026/*