---
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.joinhorizon.co/blog/amazon-bedrock-agentcore-pricing-12-components/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: kevin-w
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.

> **AWS lifecycle notice (June 30, 2026):** Amazon Bedrock Agents is now **Bedrock Agents Classic**, in maintenance for new customers after **July 30, 2026**. Net-new agent builds should use [Bedrock AgentCore](https://www.joinhorizon.co/blog/amazon-bedrock-agentcore-production/). Full matrix: [lifecycle roundup](https://www.joinhorizon.co/blog/aws-service-lifecycle-updates-june-2026/).

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 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](https://www.joinhorizon.co/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 session. Work the numbers on the [AgentCore pricing calculator](https://www.joinhorizon.co/tools/amazon-bedrock-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 records/retrievals are the dominant lines for most production agents. Most surprises come from cross-session Memory growing without a retention TTL.

| Component                  | Typical bill share     | Primary trap                        |
| -------------------------- | ---------------------- | ----------------------------------- |
| Bedrock model tokens       | Largest line           | Model choice dominates              |
| Runtime active compute     | ~15–22% of model spend | Tool latency extends billed seconds |
| Long-term Memory           | ~6–10% of model spend  | No TTL on cross-session facts       |
| Browser / Code Interpreter | ~3–6% each             | Enabled for every turn              |

<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 vCPU/GB-hour + long-term Memory: ~75 to 85% of AgentCore-attributable spend, excluding model tokens',
    },
    {
      value: '1.2–1.4×',
      label: 'Multiplier on model spend',
      note: 'Lean (Runtime + Memory only) vs full-feature (everything on)',
    },
    { value: '3–4×', label: 'Memory bill growth in six months', note: 'When no retention policy is set on cross-session memory' },
  ]}
  caption="Indicative ratios. Validate with the [AgentCore pricing calculator](https://www.joinhorizon.co/tools/amazon-bedrock-agentcore-pricing-calculator/). Source: [AWS Pricing page](https://aws.amazon.com/bedrock/agentcore/pricing/), us-east-1; calculator rates as of 2026-07-04."
/>

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.

<PricingDimensionTable
  title="AgentCore line items and cost drivers (model spend is metered separately)"
  intro="Pricing structure aligned with the AgentCore calculator (2026-07-04, us-east-1 list). Verify exact unit prices against the AWS Bedrock AgentCore pricing page for your region."
  region="us-east-1"
  dimensions={[
    {
      name: 'Runtime compute',
      unitPrice: 'vCPU-hour + GB-hour (active session time)',
      example: '500K sessions × ~4s active × configured vCPU/GB',
      monthly: 'Dominant',
      note: 'List: $0.0895/vCPU-hr + $0.00945/GB-hr (calculator, 2026-07-04)',
      highlight: true,
    },
    {
      name: 'Runtime session volume (cost driver, not a separate meter)',
      unitPrice: 'Sessions × active seconds (drives compute)',
      example: 'Tool-heavy agent averaging 4s/turn',
      monthly: 'Co-dominant',
      note: 'Browser / Code Interpreter time extends billed seconds',
      highlight: true,
    },
    {
      name: 'Browser tool',
      unitPrice: 'Same compute shape on browser minutes',
      example: 'Research agent, 8 page loads / 90s per turn',
      monthly: 'Moderate',
      note: 'Managed Chromium; model as minutes × vCPU/GB',
    },
    {
      name: 'Code Interpreter',
      unitPrice: 'Same compute shape on sandbox seconds',
      example: 'Data-analysis agent, 12s sandbox / turn',
      monthly: 'Moderate',
      note: 'Sandboxed Python/JS/TS execution',
    },
    {
      name: 'Gateway invocation',
      unitPrice: 'Per 1k invokes (+ search + tool index)',
      example: 'Policy-mediated tool routing, 3 calls/turn',
      monthly: 'Low to Moderate',
      note: 'Only billed when you route tools via Gateway',
    },
    {
      name: 'Identity (OIDC/JWT)',
      unitPrice: 'Per authenticated principal-session (opt-in)',
      example: 'B2B agent with SSO, 12K sessions/day',
      monthly: 'Low',
      note: 'Only billed when AgentCore Identity handles auth',
    },
    {
      name: 'Memory: short-term (in-session)',
      unitPrice: 'Per GB ingested / retrieved / stored',
      example: 'Conversation events within a session',
      monthly: 'Low to Moderate',
      note: '$1.00/GB in, $0.20/GB out, $0.10/GB-month (since 2026-10-06)',
    },
    {
      name: 'Memory: long-term (cross-session)',
      unitPrice: 'Per 1k LTM records/month + per 1k retrievals',
      example: '500K users × 30 facts × monthly recall',
      monthly: 'Dominant at scale',
      note: 'Grows without retention/TTL; calculator $0.75/1k LTM + $0.50/1k retrieval',
      highlight: true,
    },
    {
      name: 'Observability traces',
      unitPrice: 'Per million trace events (free tier)',
      example: 'Full step traces on every session',
      monthly: 'Low (often free tier)',
      note: 'OTEL-compatible, exported to CloudWatch; ingest 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 (Gateway semantic / retrieval)',
      unitPrice: 'Per 1k Gateway search queries',
      example: 'Tool discovery at 200K searches/month',
      monthly: 'Moderate',
      note: 'Distinct from Bedrock 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. Calculator rates: see /tools/amazon-bedrock-agentcore-pricing-calculator/."
/>

_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 to 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, so 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. 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 record. 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 long-term records by month six, with retrieval traffic on every session start.

<BillSurpriseCallout
  variant="surprise"
  title="Memory bill grows 3 to 4× in six months on B2C agents"
  amount="3 to 4× growth, no usage change"
>
  Long-term Memory records do not expire by default. A consumer-facing agent at 500K MAU silently grows its
  long-term record count and retrieval volume every month even when the active user count is flat. Old users still
  have memory that incurs storage and retrieval charges until something explicitly deletes or expires it. The fix is a
  TTL on long-term records (90 to 180 days is typical) plus a monthly compaction job that consolidates duplicate facts.
</BillSurpriseCallout>

## 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](https://www.joinhorizon.co/tools/amazon-bedrock-agentcore-pricing-calculator/). The relative weight of each line, not absolute dollars, looks like this:

<PricingDimensionTable
  title="Cost contribution by line (B2B ops agent, 250K sessions/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: 'vCPU-hour + GB-hour',
      example: '250K × 3.2s active',
      monthly: '~15–22% of model spend',
      highlight: true,
    },
    {
      name: 'AgentCore long-term Memory',
      unitPrice: 'LTM records/mo + retrievals',
      example: '8K users × 20 facts × recall',
      monthly: '~6–10% of model spend',
      highlight: true,
    },
    {
      name: 'Code Interpreter',
      unitPrice: 'Sandbox seconds × compute',
      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 published AWS list prices and common deployment shapes (hypothetical). Always model your own workload on the calculator, because multipliers shift with chat-style vs research-style traffic."
/>

The pattern repeats across deployment shapes. Runtime + long-term Memory together land at roughly 20 to 30% on top of the model spend, with the remaining lines mostly under 5% each (Browser and Code Interpreter can reach about 6% when enabled on every turn). The first optimization passes therefore focus on Runtime active seconds and Memory retention, since every other line item is small 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 to 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 as active browser time on the same vCPU/GB-hour shape as Runtime. Many agent designs use
  it to fetch JSON from a structured API the team already maintains. Replace with a Gateway/OpenAPI or HTTPS tool;
  per-turn active seconds drop from ~4 to 8s to under 1s, cutting both Browser and Runtime compute.
</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 to 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 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](https://www.joinhorizon.co/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)).

<PricingDecisionCard
  headline="Choose AgentCore when state, Gateway tools, or session isolation is non-negotiable; choose direct Bedrock APIs when the workload is single-turn and burstable."
  useWhen={[
    'Agent needs cross-session memory of user preferences, project context, or prior decisions',
    'Regulated industry where a full agent-reasoning audit trail is mandatory',
    'Multi-tool agent where Gateway + Policy (Cedar) gates writes before execution',
    '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 single-turn Converse/InvokeModel with no recall across visits',
    'Internal-only agents with &lt;20K sessions/month where Lambda + direct Bedrock is cheaper',
    'Employee ACL RAG where Quick Suite connectors beat a custom agent stack',
    'Hard sub-second first-token SLAs without warm-session design (microVM cold starts)',
    'Workloads where the model spend is so small that AgentCore line items would be a high relative percentage',
  ]}
  footnote="When in doubt, prototype on Converse/InvokeModel first, then move to Harness or Runtime once persistent state, Gateway tools, or observability becomes a hard requirement."
/>

## 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](https://www.joinhorizon.co/tools/aws-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](https://www.joinhorizon.co/tools/amazon-bedrock-agentcore-pricing-calculator/).
3. **Sanity-check with multipliers.** Lean Runtime-and-Memory often lands ~1.2 to 1.3× 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 to 10% of model spend at moderate scale and 10 to 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 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](https://www.joinhorizon.co/blog/amazon-ebs-pricing-orphaned-volumes-snapshots/)
- Browse all: [Cost Optimization & FinOps category](https://www.joinhorizon.co/category/cost-optimization-and-finops/)
- FinOps pillar: [FinOps shift-left: cost feedback in the pull request](https://www.joinhorizon.co/blog/aws-finops-shift-left-engineering-cost-ownership/)

## 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](https://aws.amazon.com/bedrock/agentcore/pricing/).
- **Bedrock model spend itself:** see our [Bedrock cost optimization guide](https://www.joinhorizon.co/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](https://www.joinhorizon.co/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.
- **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 records. 90 days is the right starting default for B2C agents; 180 to 365 days for B2B agents with intermittent user engagement. This is the single change that prevents the most common AgentCore bill-growth pattern: long-term records and retrievals silently compounding month over month with no user-visible benefit.

Since **October 13, 2026** this is a native setting ([long-term record TTL](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)):

- Set `recordExpirySpecification.recordExpiryDurationDays` (minimum **31**) on each strategy in `CreateMemory` / `UpdateMemory`, or on a `BatchCreateMemoryRecords` / `BatchUpdateMemoryRecords` request. Self-managed strategies are excluded; `action: REMOVE` clears a TTL.
- Semantic and user-preference strategies must share one value; summary and episodic must share another.
- A change applies only to records created **after** it. Existing records keep their old expiry, so set it before launch, or plan a one-time cleanup.
- Deletion can lag a few days after expiry, and expired records can still come back from read APIs in that window. Do not rely on TTL alone for erasure requests.
- Grant `bedrock-agentcore:UpdateMemoryRecordExpirySpecification` only to the role that owns retention policy. 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](https://www.joinhorizon.co/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 active compute and long-term Memory. Runtime (and Browser / Code Interpreter when enabled) bills primarily on active session time as vCPU-hour and GB-hour. Every agent turn burns wall-clock seconds, and tool latency extends that window. Long-term Memory bills on retained events plus retrievals; left untuned, event volume grows with user history. For most enterprise agents at production scale, these two lines are 75 to 85% of the AgentCore-attributable spend, before the underlying Bedrock model cost. Model sessions × active seconds × vCPU/GB on our AgentCore pricing calculator.

### Is short-term Memory free or billed separately?
Short-term (in-session) Memory is metered on data volume since 2026-10-06: GB ingested, GB retrieved, and GB-month stored, replacing the earlier per-1k STM event rate. It is not "included for free in Classic Agents pricing." Long-term Memory is a separate stored-records/month line plus retrievals. If your workload is purely per-session with minimal data volume, Memory stays small; if you enable cross-session strategies without TTL, LTM and retrieval lines compound. Confirm current units on the AWS AgentCore pricing page; our calculator (as of 2026-10-17, us-east-1) uses $1.00/GB STM ingested, $0.20/GB STM retrieved, $0.10/GB-month STM stored, $0.75/1k LTM events/month, and $0.50/1k retrievals.

### 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 active browser time on the same compute shape as Runtime (vCPU-hour + GB-hour for session minutes). For agents that need brief navigation (one or two page loads per turn), the managed Browser tool is often cheaper once you factor in 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 user/tenant identity; every retained fact becomes a billable long-term record and future retrievals. Without a retention policy, a B2C agent serving 500K users with 30 retained facts per user accumulates a huge record footprint indefinitely, because long-term records never expire by default. Retrievals at session start dominate cost at scale. The fix is a TTL on cross-session memory (since October 13, 2026, set recordExpirySpecification on the strategy; minimum 31 days, 90 or 180 days for most use cases) and a monthly compaction job that consolidates redundant facts. Without TTL, Memory line items can compound quickly. For example, a 500K-user agent with 30 facts per user and no retention can triple Memory line items within a quarter (hypothetical workload, not from a client engagement).

### 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 AgentCore Gateway (invocations, semantic search, indexed tools). Direct tools that never hit Gateway do not create Gateway line items. Identity is metered only when you use AgentCore Identity for agent/user auth and credential brokering. Many production agents use Runtime and Memory but handle auth in API Gateway or Cognito upstream and call a small set of Lambdas without Gateway, sidestepping both lines.

### How do I model AgentCore cost before I build?
Start from the model spend, then layer AgentCore platform lines. Use the [Bedrock token cost calculator](https://www.joinhorizon.co/tools/aws-bedrock-token-cost-calculator/) for tokens, then the [AgentCore pricing calculator](https://www.joinhorizon.co/tools/amazon-bedrock-agentcore-pricing-calculator/) with sessions/month, average active seconds, vCPU, peak memory GB, Gateway volume, and Memory events/retrievals. Directionally, lean Runtime-and-Memory deployments often land ~1.15× model spend and full-feature (Browser, Code Interpreter, Gateway, Identity) closer to ~1.4×. Validate with your own traffic shape.

### 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 (CloudWatch agent-trace events). Compute-shaped lines (Runtime, Browser, Code Interpreter) settled on active vCPU/GB-hour style metering rather than a simple Classic-style per-invocation story. Memory moved to event/retrieval metering rather than a DIY DynamoDB GB-month mental model. 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.joinhorizon.co/blog/amazon-bedrock-agentcore-pricing-12-components/*