Amazon Bedrock AgentCore Pricing: The 12 Components Behind Your Agent Bill

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is now Bedrock Agents Classic, in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

Amazon Bedrock AgentCore is the modular production platform for net-new agents (Harness, Runtime, Memory, Gateway, Identity, and related services) — not a thin wrapper around Agents Classic. The architecture story is in our AgentCore production guide. This post is the bill story — twelve distinct metered components, what each one charges for, which two of them quietly dominate the invoice, and how to model the spend before the first session. Work the numbers on the AgentCore pricing calculator (list rates as of 2026-07-04, us-east-1).

Amazon Bedrock AgentCore pricing meters twelve components — Runtime, tools, Memory, and more — on top of underlying model token spend. In us-east-1 (July 2026), Runtime active compute (vCPU/GB-hour) and long-term Memory events/retrievals are the dominant lines for most production agents. Most surprises come from cross-session Memory growing without a retention TTL.

AgentCore went generally available with a metered-component pricing model that AWS has been incrementally adjusting through 2026. The pricing page reflects the current rates per region; the structure below is what stays stable across rate changes.

What Are the 12 Bedrock AgentCore Pricing Components?

Bedrock AgentCore bills across twelve distinct lines. Eleven are AgentCore-specific; the twelfth — the underlying Bedrock model spend — is what your agent calls into and is metered separately on the Bedrock model invocation rate sheet.

If you only audit one dimension first, start with long-term Memory retention — it compounds silently while user counts stay flat.

The Two Lines That Quietly Dominate

In typical production AgentCore deployments, two components consistently drive 75–85% of the AgentCore-attributable spend. Knowing which two collapses the optimization problem from twelve dimensions to two.

Runtime (active compute)

Every agent session burns active seconds on Runtime, metered as vCPU-hour + GB-hour (same shape for Browser and Code Interpreter session time). Session count is fixed by the product — you cannot reduce it without reducing user interactions. What you can reduce is average active seconds per session and the vCPU/memory footprint you configure. Three factors compound it:

1. Tool latency — every Browser, Code Interpreter, or external API call extends wall-clock time, which is what AgentCore Runtime charges for.
2. Self-reflection loops — agents configured to re-evaluate their own output add a second model round-trip, doubling duration.
3. Verbose tool payloads — tools that return large payloads force the agent to process more tokens before responding, extending the turn.

The lever is reducing per-session active seconds and right-sizing vCPU/GB — not wishing away traffic. Streamlined Gateway tools, tighter system prompts, and disabling self-reflection for low-stakes turns are the practical moves.

Long-term Memory

Long-term Memory looks cheap per event. It compounds because every user accumulates facts forever without a TTL, and every new session retrieves the relevant slice (a separate per-1k retrieval line). A B2C agent at 500K monthly active users with 30 retained facts per user is carrying roughly 15M LTM events by month six, with retrieval traffic on every session start.

How the Bill Compounds: A Worked Example

Example workload (not from a client engagement) — consider a B2B operations agent: 250K sessions/month, average 3.2s active per turn (one Code Interpreter call + one external API call), 8K active users, 20 facts retained per user with 12-month recall. Plug the same shape into the AgentCore pricing calculator. The relative weight of each line — not absolute dollars — looks like this:

The pattern repeats across deployment shapes. Runtime + long-term Memory together land at roughly 20–30% on top of the model spend, with the remaining lines individually under 5%. This is why the first optimization passes always focus on Runtime active seconds and Memory retention — every other line item is rounding error by comparison.

Common Bill Surprises

When AgentCore Is and Is Not the Right Fit

AgentCore is the right platform when you need persistent state across sessions, audit-grade observability, Gateway Policy on tools, or managed Browser/Code Interpreter. It is not the right platform when a single-turn Converse/InvokeModel call or Knowledge Bases RAG already solves the problem — or when Amazon Quick Suite wins for employee-only knowledge work (decision guide).

Modeling AgentCore Cost Before You Build

The single highest-impact pre-build exercise: produce a token-volume estimate and use it as the anchor for everything else.

1. Anchor on model spend. Estimate input + output tokens per turn × sessions per month × your chosen model’s per-token rate. Use the Bedrock token cost calculator to lock in the number.
2. Run the AgentCore calculator. Enter sessions/month, average active seconds, vCPU, peak memory GB, Gateway volume, and Memory events/retrievals on the AgentCore pricing calculator.
3. Sanity-check with multipliers. Lean Runtime-and-Memory often lands ~1.15× model spend; full Browser + Code Interpreter + Gateway + Identity closer to ~1.4×. If the calculator diverges sharply, fix your active-seconds or Memory event assumptions first.
4. Layer retention. Estimate active users × retained facts × TTL. Without TTL, Memory typically lands at 5–10% of model spend at moderate scale and 10–20% at B2C scale.
5. Add a 20% contingency. AgentCore line items can be adjusted by AWS between your estimate and your production date. Build in headroom.

The output is a defensible monthly cost estimate accurate within ±25% before the first production session. That accuracy is enough to make the build/buy decision and to commit to a budget envelope.

More in This Series

Part of the AWS Service Pricing series (June 2026).

• Next: Part 2
• Browse all: Cost Optimization & FinOps category
• FinOps pillar: FinOps shift-left: cost feedback in the pull request

What This Post Doesn’t Cover

• Every Identity / Evaluations / Payments unit — those lines are opt-in and less stable than Runtime/Memory; confirm on the AWS Bedrock AgentCore pricing page.
• Bedrock model spend itself — see our Bedrock cost optimization guide for token-level optimization.
• Provisioned throughput vs on-demand for the underlying model — covered separately in Bedrock provisioned throughput vs on-demand.
• Multi-region replication of long-term Memory — supported but pricing is still evolving; treat anything we wrote here as us-east-1-anchored.
• Calculator coverage gaps — the public calculator models Runtime, Browser, Code Interpreter, Gateway, and Memory; it does not yet model Identity, Observability, Evaluations, or Payments line items.

If You Only Do One Thing This Week

Set a TTL on long-term Memory items. 90 days is the right starting default for B2C agents; 180–365 days for B2B agents with intermittent user engagement. This is the single change that prevents the most common AgentCore bill-growth pattern — LTM events and retrievals silently compounding month over month with no user-visible benefit. Add a monthly compaction job that consolidates duplicate facts per user/tenant and the Memory lines stay flat regardless of user growth.

For deeper context on Harness vs Runtime, Gateway, and Identity, the AgentCore production guide walks through the same surface from the design side rather than the bill side.