Insights

How do I allocate Amazon Bedrock costs by department?

By Brian Diamond

Published October 7, 2026

Allocate Amazon Bedrock costs by department by creating one application inference profile per cost object, tagging each profile with the department (and, if you want it, the agent), activating those tags as cost allocation tags in Billing, and having every application invoke models through its profile instead of by model ID. Bedrock then carries the tag onto every on-demand inference line in Cost Explorer and the Cost and Usage Report, which is as far as AWS takes it. The rest, handling the usage that arrives untagged, accruing before the bill, and booking the result, is the accounting work this article covers.

Why Bedrock is the easy case

Most model providers invoice one line per model with no information about who used it. Bedrock is different: since late 2024 you can attach AWS resource tags to inference profiles, and the tags flow into billing. That makes Bedrock the one place where attribution can exist in the invoice data itself, provided you set it up before the usage happens.

Set up once

  1. Decide the cost object. Department is the usual choice. If agents matter to you, add a second tag for the agent so one department can run several agents and still see them separately.
  2. Create application inference profiles. One per department-and-agent pair. A profile wraps a model or a system-defined cross-region profile; applications call the profile ARN.
  3. Tag the profiles. For example CostCenter=CustomerSuccess and Agent=support-agent. Use the same tag keys everywhere; mixed keys (Department here, cost-center there) are the most common reason allocation reports come up short.
  4. Activate the tags for cost allocation. In the Billing console, cost allocation tags have to be activated before they appear on cost rows. Tags on the resource alone are not enough. Activation applies going forward, but a management account user can request a backfill of up to twelve months; backfilled months only pick up tag values that were already on the profile at the time.
  5. Set AWS Budgets by tag. A budget per department, filtered on the tag, with alerts to the department owner rather than to the platform team.
  6. Enforce invocation through profiles. Invoking through a profile needs IAM permission on both the inference-profile ARN and the underlying foundation-model ARNs in each Region the profile routes to, so the policy cannot simply leave the models out. Add a condition on the foundation-model statement using the bedrock:InferenceProfileArn key, so a model can only be invoked through one of your profiles. That condition is what blocks direct model calls and keeps usage from leaking in untagged.

What arrives in the bill

In the Cost and Usage Report (and in AWS's FOCUS-format export), each Bedrock line carries the service, the inference-profile ARN as the resource, the token meter (input, output, cached input) as the SKU, the token count, the cost, and the activated tags. One request becomes two or three rows, one per meter, all with the same tags.

Column (FOCUS) Example
ServiceName Amazon Bedrock
ResourceId arn:aws:bedrock:us-east-1:…:application-inference-profile/support-agent
SkuMeter Output tokens
ConsumedQuantity / ConsumedUnit 900,000 / Tokens
BilledCost 13.50
Tags CostCenter=CustomerSuccess, Agent=support-agent

What does not get tagged

Three kinds of Bedrock usage arrive with no profile tag, and every allocation plan needs a rule for each:

  • Direct model-ID invocations. Any application that bypassed the profile. The IAM policy above prevents it going forward; whatever already happened lands in an unattributed bucket.
  • Provisioned throughput. Billed by model units, not by invocation, so there is no profile on the line. Allocate it by measured share of invocations through the profiles that used it.
  • Batch and evaluation jobs. Same problem; allocate by the project that ran them, from the job metadata.

Unattributed usage should stay visible as its own line until a rule assigns it. Spreading it by headcount hides the gap and teaches teams that tagging is optional.

Month-end: from tags to entries

Accrue before the invoice. Bedrock usage is visible in Cost Explorer within a day; the AWS invoice arrives after period end. Price the tagged usage at your effective rate and post the accrual by department.

Worked example. September usage, three profiles: Support agent $25.50 (Customer Success), Research agent $7.50 (Product), Shared assistant $9.00 (tagged with the agent but no department), plus $3.00 of direct model-ID calls with no tags.

Account Debit Credit Cost center
AI services expense 25.50 Customer Success
AI services expense 7.50 Product
AI services expense (unattributed) 12.00 AI Platform suspense
Accrued AI services 45.00

The $12.00 sits in suspense with its agent name and the reason ("no CostCenter tag"; "invoked by model ID"), not blended into the departments. When the owner assigns the shared assistant's $9.00 by request share (Finance 40 / HR 35 / Legal 25) and the $3.00 is traced to a team that bypassed the profile, the suspense clears to those cost centers.

When the AWS invoice arrives, reverse the accrual, book the actual, and post the difference to the same cost centers pro rata. Bedrock corrections for a prior period arrive as separate adjustment lines; book them as true-ups against the original cost object, not as current-period expense.

Checks a controller should run

  • Total tagged plus unattributed Bedrock cost equals the Bedrock line on the AWS invoice. If not, tags were activated mid-period without a backfill or some usage is in another account.
  • Unattributed share is falling month over month. If it is flat, the IAM policy is not enforced.
  • Every department's Bedrock cost reconciles to a profile ARN list that the department owner has seen.

Related

How do I account for AI agent spend in the general ledger? · How do I do chargeback for AI usage? · Is there an open standard for AI agent spend data? · OASA ↔ FOCUS 1.4 mapping, section 10b

Worked examples are illustrative; costs are not AWS pricing. AWS feature names reflect Amazon Bedrock as of this writing. Confirm account structure with your controller.

Not sure which of your AI costs are being booked? Run the free Agent Spend Assessment.

Onaro Meridian is FinOps for agentic AI: the system of record that attributes, controls and books what AI agents spend.

Brian Diamond

Brian Diamond

Brian Diamond is a fractional Chief AI Officer and founder of Onaro. He has spent 30 years running infrastructure operations and founded LANStatus, a Connecticut managed services provider and Microsoft partner, in 2001. He holds a Chief AI Officer certification and writes the CAIO Brief on AI leadership for finance and operations.

LinkedIn · CAIO Brief · Author page

Markdown version