Skip to content

SYSTEM Cited by 1 source

Amazon Bedrock application inference profiles

What it is

Amazon Bedrock application inference profiles are application-owned Bedrock resources that expose an ARN pointing at a foundation model and accept resource tags. An application invokes the profile ARN as modelId instead of the raw model identifier; Bedrock continues to serve the selected underlying model while AWS records usage against the profile's cost-allocation tags. The profile is therefore a resource-level indirection layer for attribution, not a separate model deployment. (Source: sources/2026-08-13-aws-track-generative-ai-costs-with-amazon-bedrock-inference-profiles)

Shared-role cost attribution

The canonical use case is a shared Bedrock application with one IAM role. IAM-principal attribution identifies that application, but cannot distinguish its HR, Accounting, and IT traffic. The application first authenticates the user, resolves a trusted department value, and selects the matching tagged profile:

trusted department → application profile ARN → same foundation model
                    └── Team=<department> → Cost Explorer group-by

The profile turns the application-selected resource into the billing dimension. It does not pass the individual user's identity to AWS and it does not replace application authorization. This is the core mechanism of patterns/tagged-inference-profile-cost-attribution.

Invocation and authorization shape

The API call shape remains unchanged except for modelId:

response = client.converse(
    modelId=department_profile_arn,
    messages=messages,
    inferenceConfig={"maxTokens": 300},
)

The caller needs bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream on both the application-inference-profile ARN and the referenced foundation-model ARN. A policy wildcard over profile ARNs supports low-friction department onboarding; enumerating specific ARNs is the least-privilege alternative. (Source: sources/2026-08-13-aws-track-generative-ai-costs-with-amazon-bedrock-inference-profiles)

Operational lifecycle

  • Create one profile per reporting boundary and tag it, for example Team=HR.
  • Activate the tag in the payer account before it is usable as a Cost Explorer group-by dimension; the source gives a 24–48-hour reporting delay and notes that key casing matters.
  • Provision many profiles through AWS::Bedrock::ApplicationInferenceProfile rather than a manual console workflow.
  • Profile resources have no standalone charge and keep the same per-token model rate.
  • Do not delete an active profile casually: clients using its ARN fail immediately, and recreating it yields a different ARN that must be deployed to application configuration.

Trade-offs

Choice Benefit Cost / limitation
One shared role + tagged profiles No per-user AWS sessions; simple application credential model Application must securely derive and validate the department mapping
One IAM principal per team Native caller-identity attribution More session, role, and application identity management
Wildcard profile IAM permission New profiles work without a policy update Broader than necessary invocation authority
Specific profile ARNs Tighter least privilege Adding a department requires coordinated IAM and application changes
Cost Explorer tags One billing-plane view across AWS services 24–48-hour delay; not immediate safety enforcement

Caveats

The source does not disclose resource limits, cross-Region profile behavior, profile update semantics, tag-governance controls, or a real production reporting reconciliation. A Team tag provides attribution, not budget enforcement, data isolation, model authorization, or real-time anomaly detection. Multi-cost-center users and shared background workloads require an explicit application ownership rule.

Seen in

Last updated · 622 distilled / 1,953 read