← Agent Frameworks 🕐 16 min read
Agent Frameworks

Bedrock AgentCore — Cost Patterns and FinOps Governance (2026)

Overview · March 2026

AWS offers two architecturally distinct agent products under the Bedrock umbrella: **Bedrock Agents** (the original 2023 managed-orchestration service) and **Bedrock AgentCore** (the 2025/2026 infrast

AWS offers two architecturally distinct agent products under the Bedrock umbrella: Bedrock Agents (the original 2023 managed-orchestration service) and Bedrock AgentCore (the 2025/2026 infrastructure platform for deploying agents built with any framework). They share a brand name but differ sharply in billing model, CUR footprint, and cost risk profile. Conflating them is the first FinOps mistake teams make with agentic workloads.

This note covers billing mechanics for both products, the token-multiplication dynamic that drives agentic cost explosion, cost-control primitives, LiteLLM attribution patterns, Athena analytics queries, and the make-vs-buy cost decision at scale.

1. Product Taxonomy: Two Distinct Services

1.1 Bedrock Agents (legacy managed orchestration)

Released late 2023, generally available 2024. A fully managed, no-code orchestration layer that wraps a Bedrock-hosted foundation model, connects to action groups (Lambda-backed APIs), and optionally attaches a managed Knowledge Base for RAG. AWS owns the entire orchestration loop. You configure, AWS runs.

Key constraints:

  • Only works with models hosted on Bedrock (no external providers)
  • Orchestration logic is opaque — AWS reasons-acts-observes internally
  • Billing is entirely token-based; no infrastructure charges surface separately
  • CUR product code: AmazonBedrock

1.2 Bedrock AgentCore (new infrastructure platform, GA October 2025)

A set of managed infrastructure services for teams that build their own agent loops using any framework (LangGraph, CrewAI, LlamaIndex, Strands Agents, custom Python). AgentCore provides the scaffolding — secure runtime, stateful memory, tool gateway, identity federation, code execution sandbox, browser automation — without dictating orchestration logic or model choice.

Key characteristics:

  • Framework-agnostic; supports any model provider via Gateway
  • Billing is infrastructure-style: compute time + per-operation charges
  • Twelve distinct billing components, each with its own CUR usage type
  • CUR product code: AmazonBedrockAgentCore

1.3 Decision frame

Dimension Bedrock Agents AgentCore
Model scope Bedrock-only Any provider via Gateway
Framework AWS-managed Your code, any framework
Billing model Pure token charges Compute time + per-operation
Cost predictability Moderate (token count varies) Complex (12 components)
Ops burden Low Higher
Cost at low volume Lower Higher (fixed overhead per session)
Cost at high volume Scales linearly with tokens Compute efficiency at scale
CUR product code AmazonBedrock AmazonBedrockAgentCore

2. Bedrock Agents Billing — The Token-Only Model

2.1 Core billing mechanics

Bedrock Agents does not charge a separate orchestration fee. The InvokeAgent API call itself carries no line-item charge. All costs flow through standard Bedrock model inference pricing — you pay for the tokens consumed across every internal step the agent takes.

The four token types that appear in CUR:

Token type CUR usage type pattern Notes
Input tokens *-input-tokens or *-mantle-input-tokens-* System prompt + history + user turn
Output tokens *-output-tokens or *-mantle-output-tokens-* Agent reasoning + response
Cache read tokens *-cache-read-input-token-count Much cheaper than input
Cache write tokens *-cache-write-input-token-count More expensive than input

All four must be summed for accurate reconciliation. Teams that sum only input + output will have a persistent gap in their numbers, especially for agents with static system prompts that benefit from prompt caching.

2.2 Action groups and knowledge base queries — how they inflate costs

Action group invocations (Lambda calls) are not billed as separate Bedrock line items. The AWS service that executes the action (Lambda, API Gateway, DynamoDB) bills normally. What Bedrock bills is the token cost of every reasoning step that precedes and follows each action invocation.

A typical agent turn with one action invocation generates:

  1. Observation step: agent receives user query (input tokens: system prompt + history + user query)
  2. Reasoning step: agent decides which tool to call (output tokens: chain-of-thought + tool selection)
  3. Observation ingestion: agent receives tool result (input tokens: prior context + tool output)
  4. Final response: agent synthesizes answer (output tokens: final answer)

The system prompt and full conversation history are re-sent on every step. For a three-step agent, a task that would cost X tokens as a direct model call can easily cost 4–8X. At five steps, the multiplier reaches 8–12X. AWS documentation acknowledges a “5 to 8× amplification for typical agentic workloads.”

Knowledge base queries add a vector-search charge ($0.70 per 1,000 queries for the default OpenSearch Serverless backend at 2026 pricing) plus the token cost of injecting retrieved chunks into context.

2.3 CUR for Bedrock Agents — what to look for

-- Bedrock Agents cost by model and token type
SELECT
  line_item_usage_start_date,
  line_item_usage_type,
  product_region,
  SUM(line_item_usage_amount) AS token_count,
  SUM(line_item_unblended_cost)  AS cost_usd
FROM cur_database.cur_table
WHERE product_product_code = 'AmazonBedrock'
  AND line_item_usage_type LIKE '%-input-tokens%'
     OR line_item_usage_type LIKE '%-output-tokens%'
     OR line_item_usage_type LIKE '%-cache-%'
GROUP BY 1, 2, 3
ORDER BY cost_usd DESC;

Because CUR does not carry per-request identifiers, correlating a Bedrock Agents cost spike to a specific agent run requires joining CUR to model invocation logs (enabled via CreateModelInvocationLoggingConfiguration). Invocation logs carry sessionId from the InvokeAgent call, which is the correct join key for task-level attribution.

3. AgentCore Billing — The 12-Component Model

3.1 Full pricing table (as of June 2026)

Component GA Billing unit Rate
Runtime (compute) ✓ vCPU-hour (active) $0.0895
Runtime (memory) ✓ GB-hour (peak, continuous) $0.00945
Browser (compute) ✓ vCPU-hour (active) $0.0895
Browser (memory) ✓ GB-hour (peak, continuous) $0.00945
Code Interpreter (compute) ✓ vCPU-hour (active) $0.0895
Code Interpreter (memory) ✓ GB-hour (peak, continuous) $0.00945
Gateway — API invocations ✓ Per 1,000 invocations $0.005
Gateway — Search API ✓ Per 1,000 searches $0.025
Gateway — Tool indexing ✓ Per 100 tools/month $0.02
Memory — short-term (events) ✓ Per 1,000 new events $0.25
Memory — LTM automatic strategy ✓ Per 1,000 records/month $0.75
Memory — LTM override strategy ✓ Per 1,000 records/month $0.25
Memory — retrieval ✓ Per 1,000 retrievals $0.50
Policy authorization ✓ Per request $0.000025
Evaluations input ✓ Per 1,000 input tokens $0.0024
Evaluations output ✓ Per 1,000 output tokens $0.012
Web Search ✓ Per 1,000 queries $7.00
Observability (CloudWatch) Pass-through Per GB ingested $0.35
Browser profiles (S3) ✓ S3 Standard rates From April 2026

Model inference is billed separately at standard Bedrock rates and does not appear as an AgentCore line item.

3.2 CUR usage type patterns for AgentCore

AgentCore charges surface under product code AmazonBedrockAgentCore with the following line_item_usage_type patterns:

Usage type What it measures
AmazonBedrockAgentCore:RuntimeCPU vCPU-seconds of active agent execution
AmazonBedrockAgentCore:RuntimeMemory GB-seconds of peak memory (includes idle)
AmazonBedrockAgentCore:GatewayInvocations Tool invocations routed through Gateway
AmazonBedrockAgentCore:MemoryStorage LTM records stored per month
AmazonBedrockAgentCore:MemoryEvents Short-term session events written
AmazonBedrockAgentCore:PolicyAuthorization Authorization checks per request
AmazonBedrockAgentCore:CodeInterpreterCPU vCPU-seconds of sandbox execution
AmazonBedrockAgentCore:CodeInterpreterMemory GB-seconds of sandbox memory

Inference costs from model calls made by the agent still appear under AmazonBedrock with the standard token-type patterns. An AgentCore deployment therefore generates CUR entries across two product codes in the same query window.

3.3 Infrastructure multiplier on model spend

For budget estimation, apply these multipliers to the expected Bedrock model spend:

Deployment profile Multiplier on inference cost
Runtime + short-term memory only 1.10–1.15×
Runtime + LTM automatic + Gateway 1.25–1.35×
Full feature set (Browser, Code Interpreter, Gateway, Identity, LTM) 1.35–1.45×

Infrastructure is typically 10–30% of total agent cost at moderate traffic (10K–100K turns/month). The ratio inverts at micro-scale: a lightly used agent accumulates idle memory charges that can exceed inference costs.

4. Multi-Step Agent Cost Explosion

4.1 Why agentic workloads have non-linear cost profiles

Every orchestration step in a ReAct-style agent loop (Reason → Act → Observe → Reason) carries the entire accumulated context as input. The prompt for step N contains:

  • System prompt (static, cacheable)
  • All prior user turns
  • All prior model reasoning steps
  • All prior tool results (which grow with each step)

Let S = system prompt tokens, U = user query tokens, r_i = reasoning output at step i, t_i = tool result tokens at step i.

Input tokens for step N:

I_N = S + U + Σ(r_i + t_i) for i in [1..N-1] + r_{N-1}

Total input token cost across N steps:

Total_input = N·S + N·U + Σ(k·(r_k + t_k)) for k in [1..N]

For a 5-step agent with S=2000, U=200, average r_i=300, average t_i=500:

Steps Total input tokens Vs. direct call
1 2,500 1×
3 12,200 4.9×
5 28,500 11.4×
10 107,000 42.8×

The implication: a 10-step agent task costs roughly 43× the tokens of a single direct model call for the same inputs. Even without prompt caching, the quadratic growth of context across steps makes step-count the primary cost lever, not model choice.

4.2 Prompt caching breaks the multiplier — partially

Prompt caching on the static system prompt (S) changes the per-step cost for the stable prefix. On Claude Sonnet 4.6 via Bedrock, cache reads cost ~$0.30/MTok vs. $3.00/MTok for standard input — a 10× reduction on the cacheable portion.

At S=2000 tokens and 5 steps: caching saves approximately 5 × 2000 × ($3.00 - $0.30) / 1,000,000 = $0.027 per run — meaningful at scale but not transformative when the dynamic context is growing.

Tool result accumulation is not cacheable (it changes every step). Strategies to control it:

  • Truncate tool results to the top N most relevant tokens before injecting
  • Use structured summaries instead of raw API responses
  • For knowledge base RAG: return top-2 chunks, not top-5

5. AgentCore Memory Billing — Persistent vs. Session

5.1 Short-term (in-session) memory

Billed at $0.25 per 1,000 new events. An “event” is a message or tool interaction stored to the session buffer. For a 10-turn agent session with 3 tool calls: approximately 23 events × $0.00025 = $0.000575 per session. Negligible individually, but at 100K sessions/month: ~$57.50/month in short-term memory charges.

Short-term memory is cleared at session end by default. There is no storage charge after the session closes.

5.2 Long-term memory (cross-session persistence)

Two strategies with meaningfully different cost profiles:

Automatic extraction ($0.75/1,000 records/month): AWS runs its own model to extract and structure memories from session history. The $0.75 rate bundles the inference cost. Records compound monthly — every session that creates new LTM entries adds to the stored record count permanently unless a TTL policy is set.

Override strategy ($0.25/1,000 records/month): You supply the memory extraction logic. AWS stores only what you write. The storage charge is 3× cheaper, but you now pay the inference cost at standard Bedrock rates for your extraction model.

The override strategy is almost always cheaper for high-volume deployments unless your extraction model is expensive. For most workloads, Nova Lite or Haiku handles extraction adequately at $0.04–0.08/MTok.

Memory retrieval: $0.50 per 1,000 retrievals. Every agent turn that queries LTM (typically via semantic search) adds this charge.

5.3 The silent accumulation trap

LTM records accumulate across all users, all sessions, indefinitely — unless you configure explicit TTL expiration. A deployment with 50,000 active users, each accumulating 20 LTM records over 6 months, reaches 1,000,000 records × $0.75/1K = $750/month in storage alone, growing every month.

Mitigation:

  • Set memoryConfiguration.retentionDays in CloudFormation
  • Use override strategy to control what gets persisted
  • Run monthly Athena queries on AmazonBedrockAgentCore:MemoryStorage to catch accumulation before it compounds

Runtime memory (GB-hour) has a separate billing risk: it charges for peak memory footprint for every second the session is alive, including idle time. CPU charges stop during I/O wait (the 30–70% of session time the agent spends awaiting LLM responses or tool calls); memory charges do not stop. The default idle session timeout is 15 minutes. Tuning idleRuntimeSessionTimeout to 2–5 minutes is the single highest-leverage cost control for low-traffic deployments.

6. Code Interpreter Cost — Execution Environment Billing

AgentCore Code Interpreter provisions an isolated sandbox per agent invocation at the same compute rates as Runtime:

  • CPU: $0.0895/vCPU-hour (active processing only)
  • Memory: $0.00945/GB-hour (continuous for session duration)

CUR usage types: AmazonBedrockAgentCore:CodeInterpreterCPU and AmazonBedrockAgentCore:CodeInterpreterMemory

6.1 Cost estimation for code execution tasks

A data analysis task running 30 seconds of active Python computation with a 512MB memory footprint:

CPU: 30s / 3600 × $0.0895 = $0.000746
Memory: (512/1024 GB) × (45s / 3600) × $0.00945 = $0.0000591
Total: ~$0.00081 per execution

At 10,000 executions/day: ~$8.10/day or ~$243/month — manageable. The risk is long-running notebooks or iterative analysis loops where the session stays open for minutes while the user reviews intermediate output. A 10-minute idle Code Interpreter session at 512MB:

Memory: 0.5 GB × (600s / 3600h) × $0.00945 = $0.000788

Multiply by 1,000 concurrent sessions: $0.79/day just in idle memory. Set codeInterpreterTimeout to the minimum viable value for your workload.

6.2 Code Interpreter vs. Lambda for compute tasks

Lambda charges for allocated resources during the entire function duration, including time spent awaiting Bedrock API responses. AgentCore Code Interpreter charges CPU only during active computation. For tasks dominated by Python computation rather than waiting, the cost difference is modest. For tasks that mix computation with LLM reasoning, Code Interpreter’s active-only CPU billing wins by 2–3×.

7. AgentCore Gateway — API Proxy Cost Implications

Gateway is AgentCore’s managed tool-call router. It indexes available tools and routes tool invocations from agents to the appropriate API endpoints, handling authentication, retries, and circuit-breaking.

7.1 Billing components

Operation Rate
API invocations (ListTools, InvokeTool, Ping) $0.005/1,000
Search API $0.025/1,000
Tool indexing $0.02/100 tools/month
VPC data egress $0.006/GB

At 50 tool invocations per agent session and 10,000 sessions/month:

  • 500,000 tool invocations × $0.005/1K = $2.50/month in Gateway invocations
  • Tool indexing for 20 tools: $0.02 × (20/100) = $0.004/month

Gateway costs are negligible as a fraction of total agent spend. The substantive risk is VPC egress when agents call internal APIs across AZ boundaries — $0.006/GB compounding on high-throughput tool responses (e.g., large document retrievals, database dumps).

7.2 Gateway as a cost attribution point

Every tool invocation through Gateway generates a requestId that can be correlated to agent session IDs in CloudWatch. This makes Gateway the recommended attribution anchor for multi-step agent cost analysis: join Gateway invocation logs (which carry agentId, sessionId, toolName) to CUR’s AgentCore usage data on the session_id dimension.

8. Cost Controls for Agents

8.1 AgentCore native controls

Three parameters on the harness invocation control per-run costs:

Parameter What it controls Default Recommended
maxIterations Reasoning/action cycles per invocation 75 10–25 for most tasks
timeoutSeconds Wall-clock timeout per invocation 3600 120–600 for interactive
maxTokens Token budget per invocation None Set explicitly

These can be overridden at invoke time:

response = bedrock_agentcore.invoke_harness(
    agentAliasId="XXXXXXXXXX",
    sessionId=session_id,
    inputText=user_query,
    invocationConfig={
        "maxIterations": 15,
        "timeoutSeconds": 180,
        "maxTokens": 8192
    }
)

The maxIterations cap is the most important cost control for runaway loops. A default of 75 allows an agent to consume 75× the tokens of a minimal execution. For most production tasks, 10–20 iterations is adequate; 15 is a reasonable default with a 25-iteration ceiling for complex tasks.

8.2 Infrastructure-level circuit breaker

AWS Bedrock has no native spend cap or circuit breaker. The recommended pattern for production environments uses Lambda as a pre-flight proxy:

# Lambda pre-flight check
def check_session_budget(session_id: str, estimated_cost: float) -> bool:
    item = dynamodb.get_item(
        TableName="agent-session-budgets",
        Key={"session_id": {"S": session_id}}
    )
    if not item.get("Item"):
        return True
    spent = float(item["Item"]["spent_usd"]["N"])
    limit = float(item["Item"]["budget_usd"]["N"])
    return (spent + estimated_cost) <= limit

# In API Gateway Lambda authorizer
if not check_session_budget(session_id, estimated_step_cost):
    return {"statusCode": 429, "body": "budget_exceeded"}

DynamoDB provides sub-millisecond reads for this check. Track cumulative session spend by updating the record after each successful invoke.

8.3 Human-in-the-loop cost gates

For tasks above a cost threshold, insert a human approval step before continuing. The pattern:

  1. After N iterations, surface intermediate results to the user
  2. Compute estimated cost to completion (remaining steps × average step cost)
  3. If estimated remaining cost > threshold, pause and request confirmation
  4. Resume or abort based on user response

This is especially important for tasks with unpredictable step counts (document processing, research agents, code generation with iterative testing).

8.4 Model routing by task complexity

Stratifying model selection by task complexity produces 30–60% cost reductions on mixed workloads:

Task type Recommended model Relative cost
Simple slot-filling / routing Claude Haiku / Nova Micro 1×
Tool selection + reasoning Claude Sonnet / Nova Pro 8–15×
Complex multi-step reasoning Claude Opus (gated) 50–80×

Implement routing in your agent’s orchestration layer, not in the model itself. Reserve Opus for tasks that explicitly require it, protected by a budget guardrail.

9. LiteLLM Agent Cost Tracking

LiteLLM’s proxy layer provides the most tractable path for attributing multi-step agent costs to a single logical task when the agent makes calls across multiple model providers.

9.1 Session-level attribution

Every LLM call within an agent session passes a session_id via the x-litellm-trace-id header or metadata.session_id field. LiteLLM accumulates costs across all calls sharing a session ID and exposes the aggregate through the Admin UI and via the spend tracking API.

import litellm

response = litellm.completion(
    model="bedrock/anthropic.claude-sonnet-4-6-20261001",
    messages=messages,
    metadata={
        "session_id": agent_run_id,       # groups all steps under one run
        "user_id": user_id,
        "feature": "document-analysis",
        "agent_step": step_number,
        "task_id": task_id
    }
)

The minimum useful metadata set for multi-step agent attribution:

  • session_id / agent_run_id: groups the entire agent run
  • user_id: per-account attribution
  • feature: product surface (e.g., contract-review, financial-analysis)
  • customer_id: for B2B multi-tenant chargeback
  • agent_step: enables step-level cost breakdown within a run

9.2 Iteration budgets

LiteLLM provides hard budget controls per session:

{
  "litellm_params": {
    "require_trace_id_on_calls_by_agent": true,
    "max_iterations": 25,
    "max_budget_per_session": 5.00
  }
}

When max_iterations or max_budget_per_session is exceeded, LiteLLM returns HTTP 429 with budget_exceeded. Session counters reset after 1 hour by default (configurable via LITELLM_MAX_ITERATIONS_TTL).

9.3 Cost rollup queries via LiteLLM API

# Get agent-level spend for a date range
spend_data = litellm_client.get_spend(
    start_date="2026-06-01",
    end_date="2026-06-18",
    group_by="metadata.feature"
)

# Per-session cost distribution (detects outliers)
session_costs = litellm_client.get_spend(
    start_date="2026-06-01",
    group_by="metadata.session_id",
    aggregate=["p50", "p95", "p99", "max"]
)

The p99 / p50 ratio is the key outlier indicator for agentic workloads. A ratio above 5 indicates runaway sessions that dwarf typical runs.

10. Athena Queries for Agent Cost Analysis

10.1 Prerequisites

  • CUR 2.0 (AWS Data Exports) configured with daily granularity
  • CUR exported to S3, cataloged in Glue, queried via Athena
  • AgentCore usage logs exported to a separate table (agentcore_usage_logs) via CloudWatch Vended Logs
  • Cost allocation tags activated: agent_id, session_id, feature, environment

10.2 Cost-per-task from CUR

-- Cost per agent task, combining AgentCore infrastructure and Bedrock inference
WITH agentcore_infra AS (
  SELECT
    resource_tags_agent_id        AS agent_id,
    resource_tags_session_id      AS session_id,
    SUM(line_item_unblended_cost) AS infra_cost_usd
  FROM cur_database.cur_table
  WHERE product_product_code = 'AmazonBedrockAgentCore'
    AND line_item_usage_start_date >= DATE '2026-06-01'
  GROUP BY 1, 2
),
bedrock_inference AS (
  SELECT
    resource_tags_agent_id        AS agent_id,
    resource_tags_session_id      AS session_id,
    SUM(line_item_unblended_cost) AS inference_cost_usd,
    SUM(CASE WHEN line_item_usage_type LIKE '%-input-tokens%'
             THEN line_item_usage_amount ELSE 0 END) AS input_tokens,
    SUM(CASE WHEN line_item_usage_type LIKE '%-output-tokens%'
             THEN line_item_usage_amount ELSE 0 END) AS output_tokens
  FROM cur_database.cur_table
  WHERE product_product_code = 'AmazonBedrock'
    AND resource_tags_session_id IS NOT NULL
    AND line_item_usage_start_date >= DATE '2026-06-01'
  GROUP BY 1, 2
)
SELECT
  COALESCE(a.agent_id, b.agent_id)       AS agent_id,
  COALESCE(a.session_id, b.session_id)   AS session_id,
  COALESCE(infra_cost_usd, 0)            AS infra_cost_usd,
  COALESCE(inference_cost_usd, 0)        AS inference_cost_usd,
  COALESCE(infra_cost_usd, 0)
    + COALESCE(inference_cost_usd, 0)    AS total_cost_usd,
  input_tokens,
  output_tokens
FROM agentcore_infra a
FULL OUTER JOIN bedrock_inference b
  ON a.agent_id = b.agent_id
  AND a.session_id = b.session_id
ORDER BY total_cost_usd DESC
LIMIT 1000;

10.3 Average steps per task (from usage logs)

-- Average tool invocations and reasoning steps per session
SELECT
  agent_name,
  COUNT(DISTINCT session_id)               AS session_count,
  AVG(tool_invocation_count)               AS avg_tools_per_session,
  APPROX_PERCENTILE(tool_invocation_count, 0.5)   AS p50_tools,
  APPROX_PERCENTILE(tool_invocation_count, 0.95)  AS p95_tools,
  APPROX_PERCENTILE(tool_invocation_count, 0.99)  AS p99_tools,
  AVG(billed_vcpu_seconds) / 3600.0       AS avg_vcpu_hours,
  SUM(billed_vcpu_seconds) / 3600.0
    * 0.0895                              AS estimated_cpu_cost_usd
FROM agentcore_usage_logs
WHERE event_date BETWEEN date '2026-06-01' AND date '2026-06-18'
  AND deployment_environment = 'prod'
GROUP BY agent_name
ORDER BY avg_tools_per_session DESC;

10.4 Outlier detection — runaway sessions

-- Sessions with cost > 3× the daily p95
WITH daily_p95 AS (
  SELECT
    DATE(line_item_usage_start_date) AS usage_date,
    APPROX_PERCENTILE(session_cost, 0.95) AS p95_cost
  FROM (
    SELECT
      DATE(line_item_usage_start_date) AS dt,
      resource_tags_session_id         AS session_id,
      SUM(line_item_unblended_cost)    AS session_cost
    FROM cur_database.cur_table
    WHERE product_product_code IN ('AmazonBedrock', 'AmazonBedrockAgentCore')
      AND resource_tags_session_id IS NOT NULL
    GROUP BY 1, 2
  )
  GROUP BY usage_date
),
session_totals AS (
  SELECT
    DATE(line_item_usage_start_date) AS usage_date,
    resource_tags_session_id         AS session_id,
    resource_tags_agent_id           AS agent_id,
    SUM(line_item_unblended_cost)    AS session_cost
  FROM cur_database.cur_table
  WHERE product_product_code IN ('AmazonBedrock', 'AmazonBedrockAgentCore')
    AND resource_tags_session_id IS NOT NULL
    AND line_item_usage_start_date >= DATE '2026-06-01'
  GROUP BY 1, 2, 3
)
SELECT
  s.usage_date,
  s.session_id,
  s.agent_id,
  s.session_cost,
  d.p95_cost,
  s.session_cost / d.p95_cost AS cost_multiple_of_p95
FROM session_totals s
JOIN daily_p95 d ON s.usage_date = d.usage_date
WHERE s.session_cost > 3 * d.p95_cost
ORDER BY cost_multiple_of_p95 DESC;

10.5 AgentCore memory accumulation trend

-- Monthly LTM record growth — catch silent accumulation early
SELECT
  DATE_TRUNC('month', line_item_usage_start_date) AS month,
  resource_tags_agent_id                          AS agent_id,
  SUM(line_item_usage_amount)                     AS records_stored,
  SUM(line_item_unblended_cost)                   AS memory_cost_usd
FROM cur_database.cur_table
WHERE product_product_code = 'AmazonBedrockAgentCore'
  AND line_item_usage_type = 'AmazonBedrockAgentCore:MemoryStorage'
GROUP BY 1, 2
ORDER BY month, memory_cost_usd DESC;

11. AgentCore vs. Self-Built Agent Loop (Lambda + Bedrock)

11.1 Architecture comparison

Self-built stack:

  • Lambda (agent orchestration loop)
  • Bedrock InvokeModel (direct inference)
  • DynamoDB (session state)
  • S3 + OpenSearch Serverless (knowledge base, optional)
  • Custom memory layer or none
  • CloudWatch (observability)

AgentCore stack:

  • AgentCore Runtime (replaces Lambda)
  • Bedrock inference (same)
  • AgentCore Memory (replaces DynamoDB + custom code)
  • AgentCore Gateway (replaces custom tool routing)
  • AgentCore Observability → CloudWatch (replaces custom instrumentation)

11.2 Cost comparison at scale

Volume tier Lambda + Bedrock AgentCore Notes
1K sessions/month ~$5–15 infra ~$15–45 infra AgentCore overhead dominates at low volume
10K sessions/month ~$40–120 infra ~$80–200 infra Break-even zone begins
100K sessions/month ~$300–900 infra ~$400–800 infra AgentCore competitive
1M sessions/month ~$2,500–7,500 infra ~$3,000–6,000 infra AgentCore advantage in memory + tooling

(Infrastructure cost only, excluding Bedrock inference which is identical for both. Ranges reflect variation in session length, tool usage, and memory utilization.)

Lambda charges for the entire execution duration including I/O wait (time spent awaiting Bedrock responses). AgentCore Runtime charges CPU only during active computation, not during I/O wait. Typical agent sessions spend 30–70% of time in I/O wait. At 70% I/O wait, AgentCore’s effective CPU cost is approximately 3.3× more efficient than Lambda per unit of real work performed.

Break-even formula:

Monthly_turns × (C_lambda − C_agentcore) > migration_cost / payback_months

Where C_lambda includes Lambda duration cost at 100% allocation (including wait time), DynamoDB session state, and custom observability engineering amortized over the fleet. Most teams see AgentCore become cost-neutral or cheaper between 50K and 200K turns/month, with the crossover depending heavily on session duration and memory usage patterns.

11.3 Self-hosting becomes attractive when

  • Traffic is stable and high-volume (hundreds of thousands of turns/month at predictable patterns)
  • You can reserve GPU capacity and amortize fixed costs
  • Your orchestration logic requires capabilities AgentCore does not expose
  • Regulatory requirements prohibit managed-service data handling

The operational cost of maintaining a self-built agent infrastructure (on-call rotation, framework upgrades, observability maintenance) typically ranges from 0.5–1.5 engineering FTE. At standard fully-loaded engineer cost, this amortizes to approximately $75K–$225K/year in hidden cost that pure compute comparisons omit.

11.4 The model is not the optimization target

A common mistake: optimizing model selection before addressing step count and context management. The token-multiplication dynamic in section 4 means reducing average steps from 8 to 4 delivers a larger cost reduction than switching from Sonnet to Haiku. Work the step count first, then the model tier, then the provider.

12. FinOps Governance Checklist

Minimum viable cost governance for production agentic workloads:

Tagging (do before deploying)

  • [ ] Tag every application inference profile with agent_id, feature, environment, cost_center
  • [ ] Activate tags as cost allocation tags in AWS Billing console
  • [ ] Enable CUR 2.0 (AWS Data Exports) with daily granularity
  • [ ] Enable Bedrock model invocation logging for session-level attribution

Hard limits

  • [ ] Set maxIterations ≤ 20 for interactive agents, ≤ 50 for batch
  • [ ] Set timeoutSeconds appropriate to task (not default 3600)
  • [ ] Configure idleRuntimeSessionTimeout ≤ 300 seconds for production
  • [ ] Set LTM retentionDays — no open-ended accumulation

Memory strategy selection

  • [ ] Default to override strategy ($0.25/1K) unless automatic extraction is genuinely needed
  • [ ] Set embedding refresh schedules — daily unless your use case requires real-time

Monitoring

  • [ ] CloudWatch alarm on AmazonBedrockAgentCore:RuntimeCPU anomaly detection
  • [ ] Weekly Athena query for LTM storage growth (section 10.5)
  • [ ] Daily runaway session query (section 10.4) with SNS alert on p99/p50 > 5
  • [ ] Monthly cost-per-feature rollup reviewed by product owner

Architecture

  • [ ] Prompt cache breakpoints after system prompt and tool definitions
  • [ ] Tool result truncation to control context growth per step
  • [ ] Model routing: Haiku/Nova for routing steps, Sonnet for reasoning, Opus behind guardrail
  • [ ] LiteLLM session-level budget cap on all interactive agents

Sources