Stop Guessing Which Workload Owns Your Agent Costs.
AgentCore spend spans Runtime, Memory, and Code Interpreter, billed across multiple components, none attributed to a workload by default. FinOps Center closes that gap: governed onboarding, resource-ARN claiming, and per-component spend accountability, entirely within your own AWS estate.
The AgentCore Attribution Gap
AgentCore attribution is different from Bedrock.
The claiming model has to change.
Standard Bedrock attribution uses line_item_iam_principal, and the IAM role that called the model becomes the attribution anchor. FinOps Center claims that role in Spaces and every invocation routes to the right workload. AgentCore breaks this pattern in a critical way.
The IAM role the application assumes when calling the model appears in every CUR row. FinOps Center claims that role in Spaces and all invocations route to the right workload automatically.
AgentCore CUR rows do not emit a principal. Attribution is resource-ARN-based: the AgentCore Runtime ARN, Memory ARN, and Code Interpreter session identifier are the attribution anchors. A Product Owner claims component ARNs, not IAM roles.
line_item_resource_id: arn:aws:bedrock:us-east-1:341...agent-runtime/abc123
Which AI application or workload owns this AgentCore Runtime?
Is that Memory spend from the customer support agent or the document platform?
What is the per-component cost breakdown: Runtime vs Memory vs Code Interpreter?
If two workloads share the same AWS account, which one pays for which agent components?
Who is the budget owner accountable for approving this spend?
Why did Code Interpreter cost spike 40% this week, and which agent caused it?
How AgentCore Bills
One product code. Multiple components.
No workload attribution by default.
AgentCore spend lands in CUR under AmazonBedrockAgentCore, completely separate from standard Bedrock (AmazonBedrock). FinOps Center handles both product codes, unified through a single attribution layer. One workload claim covers all component rows.
| Component | usage_type (us-east-1) | Pricing Unit | Rate |
|---|---|---|---|
| Memory Short-Term | USE1-Memory:Consumption-based:Short-Term-Memory | Events | $0.00025 / event |
| Memory LTM Retrieval | USE1-Memory:Consumption-based:Long-Term-Memory-Retrieval | Memory-Retrieved | $0.0005 / retrieval |
| Code Interpreter vCPU | USE1-CodeInterpreter:Consumption-based:vCPU | vCPU-Hours | $0.0895 / hr |
| Code Interpreter Memory | USE1-CodeInterpreter:Consumption-based:Memory | GB-Hours | $0.00945 / hr |
| Runtime (vCPU) | USE1-AgentRuntime:Consumption-based:vCPU | vCPU-Hours | TBCpending validation |
| Runtime (Memory) | USE1-AgentRuntime:Consumption-based:Memory | GB-Hours | TBCpending validation |
Memory and Code Interpreter rows confirmed against live CUR data. Runtime billing dimensions pending CUR validation.
The Lambda function, ECS service, or EC2 instance running the agent application. This is the workload the Product Owner creates in Spaces, the named budget owner and the entity that receives the weekly Spend Card.
type: Infrastructure
owner: BeckiSmith
AgentCore components (Runtime, Memory, Code Interpreter) attach to the Infrastructure workload as AI Operations. One Infrastructure workload can have many AI Operations. Finance sees a combined spend view with the per-component breakdown preserved.
ai_operation: Memory arn:...memory-store/xyz
ai_operation: Code Interpreter (session)
Governed Onboarding Flow
Four steps. Four role owners.
From untracked spend to claimed workload.
The same governance model as Bedrock applies here: Business Request, FinOps Lead approval, Cloud Engineer execution, Product Owner claim, applied to the AgentCore component lifecycle. No AgentCore resource goes live without an approved Business Request and a named budget owner.
Reviews AgentCore applications surfaced from CUR. Approves the application for use with rationale. Approves the component configuration: which AgentCore services the application may use: Runtime, Memory, Code Interpreter.
Picks up the enablement task. Creates the AgentExecutionRole with appropriate Bedrock and AgentCore permissions. Deploys the AgentCore Runtime, Memory store, and any other approved components. Records ARNs in the Developer Handoff block.
Opens the Add Workload wizard in Spaces. Claims the AgentCore component ARNs from the Developer Handoff block. Sets per-component estimates: Memory events, Code Interpreter hours, Bedrock token volumes. Workload becomes active.
Spend Cards surface per-component actuals vs estimates weekly. Product Owner accepts or disputes. Portfolio Owner approves the rolled-up portfolio spend. Variance is highlighted; disputed cards route to the FinOps Lead.
The Cloud Engineer creates the AgentExecutionRole, the IAM role assumed by the AgentCore Runtime when invoking Bedrock models. Unlike standard Bedrock workloads where this role is the attribution anchor, AgentCore uses this role for model invocation permissions only. Component-level attribution uses resource ARNs, not the principal. The Developer Handoff block records both the role ARN and all component ARNs for the Product Owner to claim in Spaces.
Component Attribution and Estimates
AgentCore estimates are not token budgets.
They are component budgets.
Tokens apply to the underlying Bedrock model invocations, captured separately. AgentCore component estimates use the native billing dimensions: Memory events, vCPU-hours, GB-hours. Or the Product Owner enters a dollar budget per period and FinOps Center back-calculates the implied component volumes using current AWS pricing.
Each agent interaction that reads or writes to Memory generates billable events. A support bot with 1,000 daily sessions generates a predictable event volume the Product Owner can estimate from expected usage.
Code Interpreter sessions are ephemeral sandbox executions. Cost is driven by session frequency and duration. A data analysis agent running 100 sessions/day at 2 minutes average is a predictable estimate.
Runtime compute is the agent execution environment. Billing dimensions are pending CUR validation. FinOps Center will expose Runtime estimates using native vCPU-hours and GB-hours once dimensions are confirmed.
Model invocations from an AgentCore runtime appear in CUR as standard AmazonBedrock rows. FinOps Center unifies these under the same workload claim. One claim covers both product codes for the same agent application.
AgentCore Allocation Gaps
Five AgentCore-specific gap scenarios.
Each with a named remediation action.
AgentCore generates its own class of attribution gaps, distinct from standard Bedrock gaps because the attribution anchor is a resource ARN, not an IAM principal. FinOps Center detects each scenario and surfaces it for FinOps Lead action.
AmazonBedrockAgentCore CUR rows with a Runtime ARN that no Product Owner has claimed in Spaces. The resource exists and is spending; nobody owns it in the FinOps Center hierarchy.
Memory ARN present in CUR with spend but not attached to any claimed workload as an AI Operation component. Memory stores may serve multiple agents, and one Memory ARN can have complex ownership.
AgentCore application running with no approved Business Request for this account. The spend exists but was never through the governance workflow. Real resources, real cost, no approval on record.
AgentCore runtime or memory detected in an account or region outside the approved scope in the Business Request. The approval boundary has been exceeded.
Code Interpreter vCPU-Hours or GB-Hours in CUR with no workload claim. Sessions are ephemeral and may not carry the same ARN as the Runtime that invoked them, requiring explicit FA assignment.
Agent Bill for AgentCore
AgentCore billing in plain language.
Role-scoped. No AWS knowledge required.
Agent Bill surfaces AgentCore spend through natural language queries, scoped to each person's role and financial hierarchy. Budget owners ask questions in plain English and get component-level answers, without needing to know what a usage_type is.
“Am I tracking on or over my Memory estimate this period?”
Your Customer Support Bot has consumed 42,000 Memory events this period against your estimate of 50,000. You are at 84% with 6 days remaining. Short-term retrieval is running 12% above baseline, likely tied to the new session persistence feature shipped last week.
“Which workload has the highest Code Interpreter cost this month?”
The Data Insights Copilot is leading at $1,240 in Code Interpreter spend this month, representing 68% of total Code Interpreter cost across all claimed workloads. Session duration is averaging 4.2 minutes, up from 2.8 minutes in the prior period.
“Are any of my AgentCore runtimes running without a claimed workload?”
Yes. One Runtime ARN in account 820723250459 (us-east-1) has $48.50 in spend this period with no workload claim in Spaces. It first appeared May 19. This is an open Unclaimed AgentCore Runtime gap in your Allocation Gaps view.
“Break down my portfolio AgentCore costs by component this month.”
Across 4 AgentCore workloads: Runtime $205, Memory $380, Code Interpreter $1,240, underlying Bedrock models $2,940. Code Interpreter is 52% of total agent costs, driven primarily by the Data Insights Copilot. All 4 workloads have confirmed estimates and claimed components.
Deployed on AWS
| Capability | FinOps Center | Vantage / nOps / Finout |
|---|---|---|
| Deployed in customer AWS account | ✓ | ✗ |
| AmazonBedrockAgentCore product code recognition | ✓ | ✗ |
| Workload-level AgentCore attribution (not account-level) | ✓ | ✗ |
| Per-component breakdown: Runtime, Memory, Code Interpreter | ✓ | ✗ |
| Resource-ARN claiming for AgentCore components | ✓ | ✗ |
| Infrastructure + AI Operations workload model | ✓ | ✗ |
| Governed onboarding: BR → CE Task → PO Claim | ✓ | ✗ |
| AgentCore Allocation Gaps detection (5 scenarios) | ✓ | Partial |
| Per-component estimates (Events, vCPU-Hours, GB-Hours) | ✓ | ✗ |
| Agent Bill natural language AgentCore queries | ✓ | ✗ |
| PPA/EDP spend retirement eligible (Deployed on AWS) | ✓ | ✗ |
Your CUR stays in your S3. Your AgentCore attribution data lives in your DynamoDB. No cross-account IAM to a vendor. No third-party data processor. No compliance review required.
From AgentCore Runtime to budget owner, in one governed flow.
Every AgentCore component. Owned. Attributed. Governed. Entirely within your own AWS estate.