How to Track Generative AI Costs by Department Using Amazon Bedrock Inference Profiles

One of the most consistent friction points in enterprise AI rollouts is the inability to answer a simple question: which team is spending how much on LLM inference? Amazon Bedrock’s application inference profiles solve this without requiring separate model deployments or changes to per-token pricing.

The Framework

An application inference profile functions as a tagged wrapper around a foundation model. Multiple departments invoke the same underlying model, but each does so through a unique profile that carries a cost allocation tag (e.g., Team=Engineering or Team=HR). When that tag is activated in AWS Billing and Cost Management, every inference invocation through that profile appears as a separate line item in Cost Explorer.

The five-step implementation:

1. Create a profile per department. Each profile is an ARN — a unique resource identifier — pointing to the same foundation model endpoint. No model duplication occurs.

2. Tag each profile. Use the Team tag key (or any tag consistent with your AWS cost allocation schema). The tag is what drives Cost Explorer disaggregation.

3. Activate the tag in AWS Billing. Cost allocation tags must be explicitly activated in the Billing and Cost Management console before they appear in reports. This is a one-time per-account step that’s frequently missed.

4. Route application requests by department. A single IAM role and single application can serve all departments; the routing logic determines which profile ARN the request invokes based on the authenticated user’s department attribute. No user identity is passed to AWS — attribution is purely profile-based.

5. View disaggregated spend in Cost Explorer. Group by tag value to see per-department inference spend. Integrate with AWS Budgets for alerts and Cost Anomaly Detection for variance monitoring.

Why This Matters

The zero-additional-cost aspect is significant. Inference profiles use the same per-token pricing as direct model invocation — the cost attribution is purely an accounting layer, not a service premium. For organizations that have been deferring this problem because it seemed like it would require a separate metering system or model deployment, the profile approach removes the technical barrier.

The architecture also scales cleanly with organizational complexity. A single profile per cost center, business unit, or application works; mixing granularities (e.g., team-level profiles for some departments, application-level for others) is equally supported. This is similar to the tagging strategy patterns discussed in Bedrock’s broader agentic architecture documentation, where resource-level tags propagate cost visibility through distributed workloads.

Where It Doesn’t Apply

Inference profiles attribute cost at the invocation level, not at the session or task level within an invocation. If a single workflow spans departments — an HR agent that calls a shared knowledge base maintained by engineering, for example — the attribution follows the profile the request was routed through, not the organizational origin of each sub-component. For cross-functional workflows, additional tagging at the application layer is required to achieve full granularity.

The approach also assumes consistent routing discipline in the application layer. If engineers short-circuit to direct model invocation (bypassing profile ARNs) during development or testing, that spend is invisible to the cost attribution system. Enforcing profile-only invocation through IAM policy denial is possible and recommended for organizations where accuracy matters.

Source: AWS Architecture Blog

Content created with AI assistance and reviewed for accuracy.