Bedrock application inference profiles, explained (2026).

IWhat application inference profiles are

They solve a governance problem, not a performance one. A plain Bedrock bill shows what each model cost, not which app or team drove the spend.

When you call a model by its bare model ID, usage is attributed to that model only. If three apps and two teams call the same Claude or Amazon Nova model, their spend lands in one bucket. On a shared account with several GenAI features, that makes the Bedrock line impossible to govern.

An application inference profile is a resource in your account that wraps a model (or another inference profile) and carries tags you define, such as application=support-bot, team=growth, environment=prod or cost-center=4012. You call the profile instead of the bare model. The model, request and response are the same, but every token of usage carries your tags. It changes the accounting, not the result. You can create one per app, per team, per environment or a mix. See the Bedrock inference profiles guide.

Profiles do not make inference faster or cheaper. They make spend attributable: "what did the support bot cost last month?" and "which team drives our Bedrock growth?" become answerable.

IIApplication vs system-defined inference profiles

Bedrock uses "inference profile" for two related things. AWS publishes one kind; you create the other.

System-defined inference profiles are published by AWS per model: geographic ones (US, EU, APAC) and, for some models, a global one. Their job is cross-region routing: Bedrock serves the request from a Region in the profile with capacity, which raises throughput and resilience. You reference them; you do not create them. See cross-region inference.

Application inference profiles are ones you create in your account. Their job is cost attribution and governance through your tags. You control their lifecycle.

They compose. An application profile's source can be a single-Region model or a system-defined profile. Point it at a system-defined cross-region profile and one ARN gives you routing and your tags (section VI).

IIIHow they work, and how to create one

You name a source, attach tags, and get back an ARN. Calling that ARN is what produces tagged usage.

• The source: Set at creation as the copyFrom ARN: a foundation model (single-Region tagging) or a system-defined profile (cross-region routing plus tagging).
• The tags: Cost-allocation key/value pairs such as application, team, environment and cost-center. These label the usage in your cost tools.
• The ARN: CreateInferenceProfile returns it. Pass it as the modelId in your inference calls.

CreateInferenceProfile is in the Bedrock API and SDKs, the AWS CLI and the console (see creating an application inference profile). Create a few by hand, then move them into infrastructure as code once the tagging scheme settles. Delete profiles with DeleteInferenceProfile when an app is retired. Tags follow standard AWS tagging limits.

One step people miss: tags on the profile make usage carry them, but a tag does not appear in Cost Explorer or the Cost and Usage Report until you activate it in the Billing console (section V).

IVUsing a profile in InvokeModel and Converse

Wherever your code passes a model ID, pass the profile ARN instead. Nothing else changes.

In InvokeModel and Converse, the target is the modelId parameter. Set it to the profile's ARN. The request body, parameters, streaming and response are the same as for the underlying model. It works across InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream, and is usually a one-line config change.

Make the model identifier a config value per app or environment. The support bot points at the support-bot profile ARN; the analytics job at the analytics ARN. Both can resolve to the same model, but their usage is separated. Grant IAM permission to invoke the profile and the model it wraps. The rule that makes it work: each workload calls its own profile. If everything calls one shared profile or the bare model, you get no split.

VSeeing the cost in Cost Explorer and the CUR

Once the tags are active, profile usage shows up split by your tags in Cost Explorer and the Cost and Usage Report.

First, activate the cost-allocation tags on the Cost Allocation Tags page of the Billing console (see the AWS guide to activating tags). A tag shows in cost reports only from activation onward, not back in time. Activate the keys when you roll out the profiles.

In Cost Explorer you can then group Bedrock spend by application, filter to one team, or split by environment. AWS Budgets can alert per tag value, so a team crossing its limit gets a notice instead of a month-end surprise.

In the Cost and Usage Report (CUR), activated tags appear as columns. You can query Bedrock spend by tag in Athena or load it into a FinOps tool to build showback or chargeback reports. Cost Explorer is for exploring; the CUR is for reporting and automation.

VICombining with cross-region inference

You do not have to choose between tagging and cross-region routing.

Set an application profile's copyFrom source to a system-defined cross-region profile. The application profile then routes requests across that geography's Regions for capacity and stamps usage with your tags. For example, a support bot can run on an application profile that wraps the US cross-region profile for Claude, getting US-wide headroom and a clean application=support-bot line in Cost Explorer.

Wrapping does not change where data is processed: requests stay within the wrapped profile's Regions (one geography for a geographic profile, any supported commercial Region for a global one). If your rules pin data to a single Region, wrap a single-Region model instead. You keep the tags and give up cross-region routing on that path.

VIIThe FinOps and chargeback use case

Profiles turn shared Bedrock spend into numbers each team owns.

Showback shows each team what its Bedrock use costs. Chargeback moves that cost into the team's or business unit's budget. Both need spend tagged by team and cost center, with the tags activated. With profiles in place, the single Bedrock line becomes a set of numbers, each with an owner.

Attributable spend allows per-team budgets and alerts. A team that sees its own GenAI bill tends to use the cost levers (right-size models, caching, Batch) that an unaccountable team ignores.

The same tags support governance: knowing which apps use which models, requiring workloads to go through approved profiles, and fitting Bedrock into the tag-based policies you already run elsewhere on AWS.

Scope: profiles give you the attribution layer. They do not reduce the bill by themselves (see the cost-optimization page) or build the reports (that is your FinOps tooling).

VIIIWho can fund Bedrock FinOps work

Calls through a profile are billed at the model's normal rate, so they draw down AWS credits like any Bedrock usage. Setting up attribution properly is real engineering work.

The work includes a tagging scheme that holds up as the company grows, wiring each workload to its profile, activating and checking the tags, building the showback reports, and adding cross-region routing where needed.

Partner-filed funding: a vetted AWS partner can file POC (proof of concept) funding for a new GenAI workload, or incremental workload (IW) funding if you already run on AWS and are launching new work. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.

AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.

CloudRoute matches you with one vetted AWS partner with FinOps experience who can build the attribution and check which funding fits. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.