# How do I allocate Amazon Bedrock costs by department?

Published 2026-10-07 · Brian Diamond

Track: finops

Segment: controller

**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?](https://www.onaro.io/blog/how-to-account-for-ai-agent-spend-in-the-general-ledger) · [How do I do chargeback for AI usage?](https://www.onaro.io/blog/how-to-do-chargeback-for-ai-usage) · [Is there an open standard for AI agent spend data?](https://www.onaro.io/blog/is-there-an-open-standard-for-ai-agent-spend-data) · [OASA ↔ FOCUS 1.4 mapping, section 10b](https://github.com/onaro-io/agent-spend-attribution/blob/main/docs/focus-mapping.md#10b-worked-example-cloud-hosted-model-with-provider-side-attribution-amazon-bedrock)

*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.*

Onaro Meridian is [FinOps for agentic AI](https://www.onaro.io/finops-for-agentic-ai): the system of record that attributes, controls and books what AI agents spend.

Canonical: https://www.onaro.io/blog/how-to-allocate-amazon-bedrock-costs-by-department