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

On August 6, 2026, AWS announced general availability 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. Bill lines stay in the 12-components pricing post.

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). 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). 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. Run the canary steps in microvm-vs-runtime-instances-canary-checklist.md. Model AgentCore Runtime lines on the 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

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.

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) 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.

1. Baseline (Day 0) — session duration histogram, active vCPU/GB, tool errors, $/successful session on microVM.
2. Score — decision matrix; 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).
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.
• Per-component unit prices — 12-components post and the pricing calculator.
• AgentCore vs Amazon Quick Suite seat TCO — decision guide.
• Exact AgentCore management rate card for Runtime Instances — verify on the AgentCore pricing page 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 — 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.
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 — AWS Select Tier Partner with Bedrock AgentCore delivery across SaaS and regulated workloads — or start from generative AI on AWS.

Related reading

• Amazon Bedrock AgentCore: Production Guide
• AgentCore Pricing: The 12 Components
• AgentCore Gateway Server-Side Tool Execution
• Bedrock AgentCore vs Amazon Q: Decision Framework
• AgentCore pricing calculator