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.

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

Figure: the capacity choice in the article. Callers keep the same invoke path. MicroVM fits short sessions. Runtime Instances attach a capacity provider and EC2 types when the session is long, needs a GPU, or stays busy. Prices and instance names stay in the article. Open the draw.io source.

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.

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, so do not “upgrade” on vibes.

Canary without rewriting the product API

Figure: the canary rule in the article. Keep bursty, short-session agents on microVM. Put a capacity provider only on agents whose wall-clock or hardware need matches it. The modeled session counts and dollar examples are not shown. Open the draw.io source.

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.
• A Region other than us-east-1: the pricing calculator uses us-east-1 list rates as of 2026-09-23 (EC2 On-Demand plus 12%, or 7.8% on G-series). Confirm the management fee on the AgentCore pricing page before you budget another Region.
• 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, an AWS Select Tier Services Partner, 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
• eCommerce AI Agents series, 64 parts applying these primitives to retail workloads
• AWS AI Agent Architecture for eCommerce

Frequently asked questions