---
title: Amazon Bedrock AgentCore Pricing: The 12 Components Behind Your Agent Bill
description: Bedrock AgentCore is metered across twelve distinct components — Runtime, Browser, Code Interpreter, Gateway, Identity, Memory (two tiers), Observability, Evaluations, Payments, Search, and the underlying model spend. Two of them drive 80% of the bill.
url: https://www.factualminds.com/blog/amazon-bedrock-agentcore-pricing-12-components/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-06-13T00:00:00.000Z
author: palaniappan-p
category: Cost Optimization & FinOps
tags: aws-bedrock, bedrock-agentcore, aws-pricing, cost-optimization, finops, generative-ai
---

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

> Bedrock AgentCore is metered across twelve distinct components — Runtime, Browser, Code Interpreter, Gateway, Identity, Memory (two tiers), Observability, Evaluations, Payments, Search, and the underlying model spend. Two of them drive 80% of the bill.

import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';

Amazon Bedrock AgentCore is the production runtime that wraps the Bedrock Agents API with persistent memory, managed tool execution, and observability. The architecture story is covered in our [AgentCore production guide](/blog/amazon-bedrock-agentcore-production/). 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 invocation.

<PricingHeroStats
  stats={[
    {
      value: '12',
      label: 'Metered components',
      note: 'Runtime, Browser, Code Interpreter, Gateway, Identity, 2 Memory tiers, Observability, Evaluations, Payments, Search, model spend',
    },
    {
      value: '~80%',
      label: 'From two lines',
      note: 'Runtime invocation/duration + long-term Memory dominate most enterprise bills',
    },
    {
      value: '1.15–1.4×',
      label: 'Multiplier on model spend',
      note: 'Lean (Runtime + Memory only) vs full-feature (everything on)',
    },
    { value: '4×', label: 'Memory bill at 6 months', note: 'When no retention policy is set on cross-session memory' },
  ]}
  caption="Indicative ratios. Validate with your own workload using the linked calculators."
/>

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.

## The 12 Metered 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.

<PricingDimensionTable
  title="The 12 AgentCore-attributable line items"
  intro="Pricing structure as of June 2026. Verify exact unit prices against the AWS Bedrock AgentCore pricing page for your region."
  region="us-east-1"
  dimensions={[
    {
      name: 'Runtime invocation',
      unitPrice: 'Per request (per agent turn)',
      example: 'Production agent at 500K invocations/month',
      monthly: 'Dominant',
      note: 'Every InvokeAgent call is one Runtime invocation',
      highlight: true,
    },
    {
      name: 'Runtime duration',
      unitPrice: 'Per second of execution',
      example: 'Tool-heavy agent averaging 4s/turn',
      monthly: 'Co-dominant',
      note: 'Browser / Code Interpreter time extends duration',
      highlight: true,
    },
    {
      name: 'Browser tool',
      unitPrice: 'Per minute of browser session',
      example: 'Research agent, 8 page loads / 90s per turn',
      monthly: 'Moderate',
      note: 'Managed Chromium session lifecycle',
    },
    {
      name: 'Code Interpreter',
      unitPrice: 'Per second of sandbox execution',
      example: 'Data-analysis agent, 12s sandbox / turn',
      monthly: 'Moderate',
      note: 'Sandboxed Python execution environment',
    },
    {
      name: 'Gateway invocation',
      unitPrice: 'Per tool call through Gateway',
      example: 'Policy-mediated tool routing, 3 calls/turn',
      monthly: 'Low–Moderate',
      note: 'Only billed when you route tools via Gateway',
    },
    {
      name: 'Identity (OIDC/SAML)',
      unitPrice: 'Per authenticated principal-session',
      example: 'B2B agent with SSO, 12K sessions/day',
      monthly: 'Low',
      note: 'Only billed when AgentCore handles auth',
    },
    {
      name: 'Memory — short-term (in-session)',
      unitPrice: 'Included in Bedrock Agents pricing',
      example: 'Conversation history within a session',
      monthly: 'Bundled',
      note: 'Not a separate AgentCore line item',
    },
    {
      name: 'Memory — long-term (cross-session)',
      unitPrice: 'Per GB-month + RCU/WCU on retrieval',
      example: '500K users × 30 facts × monthly recall',
      monthly: 'Dominant at scale',
      note: 'DynamoDB-backed; grows without retention policy',
      highlight: true,
    },
    {
      name: 'Observability traces',
      unitPrice: 'Per million trace events (free tier)',
      example: 'Full step traces on every invocation',
      monthly: 'Low (often free tier)',
      note: 'CloudWatch Logs ingestion rate after free tier',
    },
    {
      name: 'Evaluations',
      unitPrice: 'Per evaluation run + judge model spend',
      example: 'Nightly regression on 200 prompts',
      monthly: 'Low (CI/CD usage)',
      note: 'Optional automated quality scoring',
    },
    {
      name: 'Payments mediation',
      unitPrice: 'Per transaction mediated',
      example: 'Commerce agents settling on user behalf',
      monthly: 'Use-case specific',
      note: 'Specialized; only for agents that move money',
    },
    {
      name: 'Search (retrieval)',
      unitPrice: 'Per query + result ingest',
      example: 'Hybrid retrieval at 200K queries/month',
      monthly: 'Moderate',
      note: 'Distinct from Knowledge Bases retrieval',
    },
  ]}
  footnote="The 12th line — Bedrock model invocation — is billed separately on the per-model token rate sheet and typically dwarfs all AgentCore lines combined."
/>

## The Two Lines That Quietly Dominate

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

### Runtime (invocation + duration)

Every agent turn is at minimum one Runtime invocation. That number is fixed by the product — you cannot reduce the count without reducing user interactions. What you _can_ reduce is the average billed duration per turn. Three factors compound it:

1. **Tool latency** — every Browser, Code Interpreter, or external API call extends the agent's 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 action groups** — Lambda action groups that return large payloads force the agent to process more tokens before responding, extending the turn.

The leverage is in reducing per-turn duration, not per-turn count. Streamlined action groups, tighter system prompts, and disabling self-reflection for low-stakes turns are the levers.

### Long-term Memory

Long-term Memory looks cheap per item. It compounds because every user accumulates facts forever in the default configuration, and every new session retrieves the relevant slice. A B2C agent at 500K monthly active users with 30 retained facts per user is storing roughly 15M items by month six, all backed by DynamoDB read units at session-start time.

<BillSurpriseCallout
  variant="surprise"
  title="Memory bill triples in three months on B2C agents"
  amount="3–4× growth, no usage change"
>
  Long-term Memory items have no default TTL. A consumer-facing agent at 500K MAU silently grows its DynamoDB footprint
  and RCU consumption every month even when the active user count is flat — old users still have memory that incurs
  storage charges until something explicitly deletes it. The fix is a TTL on memory items (90–180 days is typical) plus
  a monthly compaction Lambda that consolidates duplicate facts.
</BillSurpriseCallout>

## How the Bill Compounds: A Worked Example

Consider a B2B operations agent: 250K invocations/month, average 3.2s per turn (one Code Interpreter call + one external API call), 8K active users, 20 facts retained per user with 12-month recall. The shape of the bill — relative weight of each line, not absolute dollars — looks like this:

<PricingDimensionTable
  title="Cost contribution by line (B2B ops agent — 250K invocations/mo)"
  intro="Relative cost share, not absolute dollars. Multiply your model spend by these ratios to get a directional estimate."
  region="indicative"
  dimensions={[
    {
      name: 'Bedrock model spend',
      unitPrice: 'Token rate × input+output',
      example: 'Underlying model invocation',
      monthly: '100% baseline',
    },
    {
      name: 'AgentCore Runtime',
      unitPrice: 'Invocation + duration',
      example: '250K × 3.2s',
      monthly: '~15–22% of model spend',
      highlight: true,
    },
    {
      name: 'AgentCore long-term Memory',
      unitPrice: 'GB-month + retrieval RCU',
      example: '8K users × 20 facts × 12mo',
      monthly: '~6–10% of model spend',
      highlight: true,
    },
    {
      name: 'Code Interpreter',
      unitPrice: 'Sandbox-second',
      example: '~12s per turn × 250K',
      monthly: '~3–6% of model spend',
    },
    {
      name: 'Observability',
      unitPrice: 'Trace events past free tier',
      example: 'Full step traces enabled',
      monthly: '~1–2% of model spend',
    },
    {
      name: 'Identity, Gateway, Payments, Search',
      unitPrice: 'Each metered separately',
      example: 'Off in this deployment',
      monthly: '~0%',
    },
  ]}
  footnote="Indicative ratios from production deployments we have reviewed. Always model your own workload — the multipliers shift significantly with chat-style vs research-style agent traffic."
/>

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 duration and Memory retention — every other line item is rounding error by comparison.

## Common Bill Surprises

<BillSurpriseCallout
  variant="trap"
  title="Code Interpreter left as 'always on' for trivial turns"
  amount="~25% wasted duration"
>
  Code Interpreter is convenient and many teams enable it for the whole agent. The bill includes the sandbox duration
  even for turns where the model never actually executes code. Either route through a per-turn allowlist (only enable
  when the prompt suggests computation) or use a tool-selection step that decides whether to spin up the sandbox at all.
  Common saving: 20–30% of total Code Interpreter spend.
</BillSurpriseCallout>

<BillSurpriseCallout
  variant="trap"
  title="Browser tool used for what an API call could do"
  amount="Multi-second per turn"
>
  The Browser tool is metered per minute of browser session and extends Runtime duration. Many agent designs use it to
  fetch JSON from a structured API the team already maintains. Replace with a direct HTTPS action group; per-turn
  duration drops from ~4–8s to under 1s, cutting both Browser minutes and Runtime seconds.
</BillSurpriseCallout>

<BillSurpriseCallout
  variant="trap"
  title="Observability traces ingested into multiple destinations"
  amount="2× CloudWatch ingest"
>
  Teams sometimes enable AgentCore traces to CloudWatch *and* also ship them to Datadog/New Relic via the CloudWatch
  Logs subscription filter. The duplicate path adds the third-party ingest charge plus the data-transfer-out cost — and
  the third-party tool often only retains a fraction of the trace structure that the native CloudWatch view shows. Pick
  one primary destination per environment and use the AgentCore-native view for incident debugging.
</BillSurpriseCallout>

<BillSurpriseCallout
  variant="optimization"
  title="Switch nightly evaluations to a cheaper judge model"
  amount="60–80% lower eval spend"
>
  AgentCore Evaluations are useful in CI/CD but the judge model defaults are often heavier than necessary for
  regression-style scoring. A Claude Haiku or Nova Lite judge model gives stable enough scores for daily regression on a
  fixed prompt suite, reserving Claude Sonnet/Opus judges for the weekly comprehensive run.
</BillSurpriseCallout>

## When AgentCore Is and Is Not the Right Fit

AgentCore is the right runtime when you need persistent state across sessions, audit-grade observability, or managed tool execution with retry and circuit-breaker semantics. It is not the right runtime when your agent is stateless within a session, your tools are already idempotent, and your traffic is intermittent enough that the per-invocation Runtime price exceeds what a Lambda-with-direct-Bedrock-API setup would cost.

<PricingDecisionCard
  headline="Choose AgentCore when state, observability, or tool reliability is non-negotiable; choose direct Bedrock API when the workload is stateless and bursty."
  useWhen={[
    'Agent needs cross-session memory of user preferences, project context, or prior decisions',
    'Regulated industry — full agent-reasoning audit trail is mandatory',
    'Multi-tool agent where tool reliability (retry, circuit breaker, timeout) is operationally critical',
    'Browser-based or sandboxed-code workflows where managing the underlying infrastructure is not a core competency',
    'B2B agent with SSO requirements where AgentCore Identity simplifies auth',
  ]}
  avoidWhen={[
    'Stateless agents that only respond within a single session and never recall prior visits',
    'Internal-only agents with <20K invocations/month where Lambda + direct Bedrock InvokeModel is cheaper',
    'Workloads where you have already built robust tool execution infrastructure (Step Functions, retry queues) and would duplicate functionality',
    'Highly bursty traffic with low monthly volume — Runtime invocation pricing favors steady throughput',
    'Workloads where the model spend is so small that AgentCore line items would be a high relative percentage',
  ]}
  footnote="When in doubt, prototype on the direct Bedrock API first, then migrate to AgentCore once persistent state or observability becomes a hard requirement."
/>

## Modeling AgentCore Cost Before You Build

The single highest-leverage 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 × invocations per month × your chosen model's per-token rate. Use the [Bedrock token cost calculator](/tools/aws-bedrock-token-cost-calculator/) to lock in the number.
2. **Add a Runtime multiplier.** For a lean Runtime-and-Memory deployment, multiply the model spend by ~1.15×. For a full-feature deployment with Browser, Code Interpreter, Gateway, Identity, multiply by ~1.4×.
3. **Layer in Memory.** Estimate active users × retained facts per user × planned retention months. Apply a small per-GB-month rate on the storage and a per-RCU rate on the retrieval. Memory typically lands at 5–10% of model spend at moderate scale, 10–20% at B2C scale without a retention policy.
4. **Sanity-check observability and evaluations.** If you enable full step traces and nightly evaluations, add another 2–4% on top. If you keep traces off and only run weekly evaluations, this rounds to zero.
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 invocation. That accuracy is enough to make the build/buy decision and to commit to a budget envelope.

## What This Post Doesn't Cover

- **Exact unit prices** are intentionally omitted because the AgentCore rate sheet changes more often than any blog post can keep pace with — always cross-check the [AWS Bedrock AgentCore pricing page](https://aws.amazon.com/bedrock/agentcore/pricing/).
- **Bedrock model spend itself** — see our [Bedrock cost optimization guide](/blog/aws-bedrock-cost-optimization-token-budgets-model-selection/) for token-level optimization.
- **Provisioned throughput vs on-demand** for the underlying model — covered separately in [Bedrock provisioned throughput vs on-demand](/blog/aws-bedrock-provisioned-throughput-vs-on-demand-break-even-2026/).
- **Multi-region replication** of long-term Memory — supported but pricing is still evolving; treat anything we wrote here as us-east-1-anchored.

## 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 — Memory storage and RCU silently compounding month over month with no user-visible benefit. Add a monthly compaction Lambda that consolidates duplicate facts within each `memoryId` and the bill stays flat regardless of user growth.

For deeper context on how the Runtime, Memory, and tool execution layers fit together, the [AgentCore production architecture guide](/blog/amazon-bedrock-agentcore-production/) walks through the same surface from the design side rather than the bill side.

## FAQ

### Which AgentCore components drive most of the bill?
Two: Runtime invocation/duration and long-term Memory. Runtime is the per-request execution charge — every agent turn is at minimum one Runtime invocation, and Code Interpreter or Browser tool calls extend the billed duration. Long-term Memory is the DynamoDB-backed cross-session store priced per GB-month plus read/write units; left untuned, it grows quadratically with retained user history. For most enterprise agents at production scale, these two lines are 75–85% of the AgentCore-attributable spend, before the underlying Bedrock model cost.

### Is in-session Memory free or billed separately?
In-session memory — the conversation context within a single agent invocation — is part of the standard Bedrock Agents pricing and is not metered separately as an AgentCore line item. The AgentCore Memory bill kicks in for cross-session persistent memory, which is the DynamoDB-backed store keyed by user/account identifier. If your workload is purely per-session (no recall across visits), you can run AgentCore without ever incurring the long-term memory charge.

### When does the Browser tool cost more than running Selenium on Lambda?
The Browser tool is convenient — managed Chromium, JavaScript execution, screenshots — but it bills per-minute of browser session time plus the underlying Runtime duration. For agents that need brief navigation (one or two page loads per turn), the managed Browser tool is cheaper once you factor in the cost of cold-starting a Lambda with headless Chromium. For agents that browse for 30+ seconds per turn at high volume (research agents, scraping workflows), a self-hosted browser farm on EC2 Spot or Fargate Spot can become cheaper once you cross roughly 100K minutes/month of browser session time. The break-even point depends on your Spot capacity stability and the operational cost of maintaining the farm.

### What happens to my Memory bill if I do not set a retention policy?
It grows. Long-term Memory is keyed by memoryId (usually a user ID); every retained fact accumulates as DynamoDB storage plus its associated read/write units. Without a retention policy, a B2C agent serving 500K users with 30 retained facts per user will store roughly 15M items indefinitely. The DynamoDB storage bill is small per item but read units dominate at retrieval time, and every new session retrieves the relevant slice. The fix is to set a TTL on cross-session memory items (90 or 180 days for most use cases) and run a monthly compaction job that consolidates redundant facts. We have seen Memory bills triple in three months on agents with no retention policy.

### Do AgentCore Gateway and Identity charges apply even if I do not use them?
No. Both are opt-in. Gateway is metered only when you route tool calls through the AgentCore Gateway (the policy-enforced API mediation layer) — direct Lambda action groups invoked from the agent do not hit the Gateway price line. Identity is metered only when you delegate auth to AgentCore Identity (the OIDC/SAML layer for user-scoped agent access). Many production agents use AgentCore for Runtime and Memory but route tools directly to Lambda and handle auth in API Gateway or Cognito upstream, sidestepping both line items entirely.

### How do I model AgentCore cost before I build?
Start from the model spend, not the AgentCore lines. For a given expected token volume (input + output) on your chosen Bedrock model, AgentCore-attributable cost is typically 10–25% on top of the model spend for a Runtime-and-Memory-only deployment, and 25–45% on top once you add Browser, Code Interpreter, Gateway, and Identity. Multiply your Bedrock model estimate by 1.15× for a lean deployment or 1.4× for a full-feature deployment, then layer in storage (Memory) using a per-user retention assumption. Cross-check with our [Bedrock token cost calculator](/tools/aws-bedrock-token-cost-calculator/) for the model spend baseline.

### What changed at GA versus the preview pricing?
The shift from preview to GA flattened a few line items and introduced a free tier on Observability traces (a generous monthly allotment per account for CloudWatch agent-trace events). Code Interpreter pricing moved to a per-second duration model rather than per-invocation, which is friendlier for short tool calls and roughly neutral for long-running data analysis tasks. Long-term Memory pricing remained essentially unchanged from the preview. Always verify against the [AWS Bedrock AgentCore pricing page](https://aws.amazon.com/bedrock/agentcore/pricing/) as line items can be adjusted at any time.

---

*Source: https://www.factualminds.com/blog/amazon-bedrock-agentcore-pricing-12-components/*