Bedrock Application Inference Profiles: Track AI Costs per Project With Tags, Create in CLI, Python, Terraform and CloudFormation, IAM, and Errors

A Bedrock application inference profile is a model ID you create yourself, so that you can track the cost and usage of one workload separately from everything else on your AWS bill. You create it from a foundation model (one Region) or from a system-defined cross-Region profile such as us.amazon.nova-pro-v1:0 (several Regions), attach tags such as project=support-bot, and then call the profile's ARN as the modelId in Converse, InvokeModel, knowledge bases, Prompt Management and Flows. Activate the tag keys as cost allocation tags in Billing, and Cost Explorer splits Bedrock spending by them. Profiles cost nothing extra; you pay the model's normal price for the Region you call from. Only tags can change after creation, so a different model means a new profile. Not to be confused with the system-defined inference profiles (the us., eu., global. IDs) that route requests across Regions, which are the cause of the common "on-demand throughput isn't supported" error. Below: profile types compared, create with the console, CLI, Python, Terraform and CloudFormation, IAM policies (including forcing teams to use their profile), cost reports, and the errors you will meet.

Jake's computer shop now uses Amazon Bedrock for three things: the front-desk warranty assistant, a nightly job that tags repair notes, and a script that reads screenshots of error messages. All three show up on the AWS bill as one line, "Amazon Bedrock," and when that line doubled one month, nobody could say which of the three had done it. Ethan fixed that in an afternoon with three application inference profiles and three tags. The next month's bill came with a breakdown. This page is how.

New to Bedrock? Our plain-English Bedrock explainer covers the service and how it bills, and the cards below cover the rest.

Inference profile vs application inference profile vs foundation model

Three kinds of ID can go in the modelId field of a Bedrock call, and most confusion about inference profiles comes from mixing them up:

System-defined profiles are the ones behind the most searched error. Many current models have no single-Region option, so calling the plain foundation model ID fails with "Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile," and the fix is to put us., eu., global. or another prefix in front of the model ID. Our throughput error guide walks through that fix, and our model IDs list shows which prefixes each model supports.

Application inference profiles are the subject of this page. They do not change how requests are routed: an application profile copied from us.amazon.nova-pro-v1:0 routes exactly like that system profile. What they add is identity: every request through the profile is recorded against it, and through its tags, against your project, team or customer.

Jake: "So it's the same model, just with our name on it?"

Ethan: "Exactly. Same model, same price, same speed. But the bill can finally tell the three jobs apart."

Why use application inference profiles

• Cost per workload. Split one Bedrock line into "support bot," "nightly tagging" and "screenshot reader," or per team, per customer, per environment.
• Chargeback. In a company with several departments, bill each department for its own AI use with tags they already use for other AWS costs.
• Usage metrics per workload. Invocations through a profile are attributed to it, so you can watch one application's volume, tokens and errors without filtering through everyone else's.
• Access control. IAM policies can allow a team to use only its own profile, and even forbid calling the underlying model any other way.
• Budgets and alerts. AWS Budgets can filter on cost allocation tags, so the support bot can have its own monthly budget and alert.

Profiles add no charge of their own, and no latency: you pay the normal token price of the model, at the rate for the Region you call from, exactly as you would calling the model directly.

Create an application inference profile

First decide the source. To keep the workload in one Region, copy from the foundation model's ARN in that Region. To get cross-Region routing (needed for models that require an inference profile, and useful for capacity), copy from the system-defined profile's ARN.

With the AWS CLI, from a foundation model in one Region:

aws bedrock create-inference-profile \
  --region us-east-1 \
  --inference-profile-name repair-notes-nova-lite \
  --description "Nightly repair-note tagging" \
  --model-source copyFrom=arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-lite-v1:0 \
  --tags key=project,value=repair-notes key=env,value=prod

And from a system-defined cross-Region profile, whose ARN includes your account ID:

aws bedrock create-inference-profile \
  --region us-east-1 \
  --inference-profile-name support-bot-nova-pro \
  --model-source copyFrom=arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.amazon.nova-pro-v1:0 \
  --tags key=project,value=support-bot

The response contains inferenceProfileArn, ending in application-inference-profile/ and a random ID. Save it: that ARN is what your code will call. To find the system profile ARNs available in a Region, run aws bedrock list-inference-profiles --type-equals SYSTEM_DEFINED.

With Python (boto3):

import boto3

bedrock = boto3.client("bedrock", region_name="us-east-1")   # control plane, not bedrock-runtime
resp = bedrock.create_inference_profile(
    inferenceProfileName="screenshot-reader-nova-lite",
    description="Reads screenshots of error messages",
    modelSource={"copyFrom": "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.amazon.nova-lite-v1:0"},
    tags=[{"key": "project", "value": "screenshot-reader"}],
)
print(resp["inferenceProfileArn"])

In the console: open Amazon Bedrock, find Inference profiles under the inference settings in the left menu (or the cross-Region inference page), switch to the application profiles tab, and create one by choosing the model or system profile to copy, a name, and tags.

Use the profile in your code

Wherever a Bedrock API takes a model ID, pass the profile's ARN. For application profiles, the ARN is required; the short ID alone is not accepted the way us.amazon.nova-pro-v1:0 is for system profiles.

brt = boto3.client("bedrock-runtime", region_name="us-east-1")
PROFILE = "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/a1b2c3d4e5f6"

resp = brt.converse(
    modelId=PROFILE,
    messages=[{"role": "user", "content": [{"text": "Is a swollen battery covered by warranty?"}]}],
    inferenceConfig={"maxTokens": 400},
)
print(resp["output"]["message"]["content"][0]["text"])

The same ARN works in:

• Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream, the modelId field.
• Knowledge bases: RetrieveAndGenerate's modelArn, and the parsing model for non-text data sources.
• Prompt Management and Flows: the modelId of a prompt or a flow's prompt node.
• Model evaluation jobs: the model identifier being evaluated.
• Batch inference: as the job's model, so overnight jobs are tracked too; our batch inference guide covers the job setup.
• Frameworks: in LangChain, ChatBedrockConverse(model=PROFILE); some libraries also ask which provider the ARN points to, since they cannot tell from an ARN, via a provider setting.

Keep the ARN in configuration (an environment variable or parameter), not in code: then moving a workload to a new profile, for example when you change models, is a configuration change.

See costs per profile: cost allocation tags

Tags on the profile only show up in billing once you turn them into cost allocation tags:

1. Tag the profiles when you create them (or later, with TagResource), using one consistent key such as project.
2. Send some traffic through each profile, so the tag key has been used.
3. Activate the tag key: in the Billing and Cost Management console, open Cost allocation tags, find project under user-defined tags, select it and choose Activate. This must be done in the management (payer) account if you use AWS Organizations.
4. Wait up to about a day. Activation is not retroactive: costs are tagged from activation onward, and the data takes up to 24 hours to appear.
5. Open Cost Explorer, filter by service Amazon Bedrock, and group by Tag: project. Each workload now has its own line.
6. Add budgets: in AWS Budgets, create a cost budget filtered on project=support-bot, with an email alert at 80% of the amount you expect.

Two things to expect. Requests made with plain model IDs, outside any profile, land in an "untagged" group, which is a useful way to find code nobody moved over. And a profile's cost covers on-demand token usage; it is a tracking label, not a discount. For lowering the numbers themselves, see our Bedrock pricing guide and prompt caching guide.

Jake: "So the bill that doubled, which one was it?"

Ethan: "Next month we'll know. My money's on the screenshot reader: images are expensive tokens."

Watching usage per profile, not just cost

Cost Explorer answers "how much"; for "how many requests, how many tokens, how fast," turn on Bedrock's model invocation logging (Bedrock console → Settings), which writes a record of every call to CloudWatch Logs, S3 or both. Each record names the model or profile that was called and the token counts, so one CloudWatch Logs Insights query gives you a per-workload usage table:

fields modelId, input.inputTokenCount, output.outputTokenCount
| stats count(*) as calls,
        sum(input.inputTokenCount) as input_tokens,
        sum(output.outputTokenCount) as output_tokens
  by modelId
| sort input_tokens desc

Run it over the last day or week. Rows whose modelId is a profile ARN are your tracked workloads; rows showing a plain model ID are calls still made outside any profile. Invocation logs can include the full prompts and answers, so decide deliberately whether to log text or only metadata, and restrict who can read the log group, especially if prompts contain customer data.

Which Region to create a profile in

A profile belongs to the Region you create it in, and you call it from that Region. Three rules keep this simple:

• Create the profile in the Region your application calls Bedrock from, usually the same Region as the app itself.
• For cross-Region routing, copy from the system profile in that same Region (for example, the us. profile as listed in us-east-1). The profile then routes across the Regions that system profile covers.
• Pricing follows the calling Region. You pay the model's price for the Region you send the request from, whichever Region ends up serving it.

An application running in two Regions needs a profile in each, which is a good thing: the two show up separately in your reports, so a spike in one Region is obvious.

One profile per customer: cost tracking for SaaS apps

If you sell a product with AI features to many customers, the most valuable question is often "what does each customer cost us in AI?" Application profiles answer it with a pattern that scales:

• When a customer signs up, create a profile for them, tagged customer=acme, from the model your product uses.
• Store the profile ARN in the customer's record, next to their plan.
• When your backend calls Bedrock for that customer, use their ARN.
• Group Bedrock costs by the customer tag each month, and compare with what each customer pays.

The result shows which customers are profitable at their plan's price and which use far more AI than they pay for, information that is otherwise very hard to get. Check the Service Quotas console for the number of application inference profiles your account may create, and request an increase before onboarding thousands of customers. For very large customer counts, a profile per plan tier plus your own per-customer metering from invocation logs is a lighter alternative.

Other ways to split AI costs, compared

These combine well. Profiles give you the bill-level split with almost no work; your own metering, built from the usage fields every Bedrock response already returns, adds per-user detail when you need it.

Moving a live app onto profiles without downtime

1. Create the profile from the same model (or system profile) the app already calls, so behavior does not change.
2. Add IAM permission for the app's role on the new profile ARN, keeping the old permissions for now.
3. Change the app's configuration from the model ID to the profile ARN, and deploy.
4. Confirm in the invocation logs (or the usage query above) that calls now show the profile ARN.
5. Tighten IAM: replace the direct model permission with the conditioned version, so the model can only be reached through the profile.
6. Check Cost Explorer after a day that the new tag appears and the untagged line shrinks.

Because a profile copied from the same source routes identically and costs the same, users notice nothing at all. The only visible change is in your reports.

IAM: permissions, and forcing teams to use their profile

Two sets of permissions are involved: managing profiles, and invoking through them.

Managing profiles (for the people or pipelines that create them):

{
  "Effect": "Allow",
  "Action": [
    "bedrock:CreateInferenceProfile",
    "bedrock:GetInferenceProfile",
    "bedrock:ListInferenceProfiles",
    "bedrock:DeleteInferenceProfile",
    "bedrock:TagResource",
    "bedrock:UntagResource",
    "bedrock:ListTagsForResource"
  ],
  "Resource": [
    "arn:aws:bedrock:*:*:inference-profile/*",
    "arn:aws:bedrock:*:*:application-inference-profile/*",
    "arn:aws:bedrock:*::foundation-model/*"
  ]
}

Invoking through a profile needs permission on the profile and on the foundation model in every Region the profile can route to. Missing the model part is the most common reason a profile works for one person and fails for another:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/a1b2c3d4e5f6"
    },
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0",
        "arn:aws:bedrock:us-east-2::foundation-model/amazon.nova-pro-v1:0",
        "arn:aws:bedrock:us-west-2::foundation-model/amazon.nova-pro-v1:0"
      ],
      "Condition": {
        "StringLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/a1b2c3d4e5f6"
        }
      }
    }
  ]
}

The bedrock:InferenceProfileArn condition is the clever part. It allows the model only when the request comes through that profile, so the team cannot call the model directly and dodge cost tracking. Give each team a role with its own profile in this pattern, and untagged Bedrock spending stops appearing.

Keeping traffic out of global routing. If your data must stay within a geography, you can block the global. profiles with an explicit deny: a Deny on bedrock:InvokeModel* for all resources when the condition aws:RequestedRegion equals unspecified, which is how global routing appears in the request context. Because explicit denies override allows, no policy elsewhere can reopen it.

Terraform, CloudFormation and the CDK

Profiles are long-lived resources that belong in infrastructure as code alongside the rest of the workload.

Terraform (AWS provider), with the ARN exported for your application:

resource "aws_bedrock_inference_profile" "support_bot" {
  name        = "support-bot-nova-pro"
  description = "Front-desk warranty assistant"

  model_source {
    copy_from = "arn:aws:bedrock:us-east-1:${data.aws_caller_identity.current.account_id}:inference-profile/us.amazon.nova-pro-v1:0"
  }

  tags = {
    project = "support-bot"
  }
}

data "aws_caller_identity" "current" {}

output "support_bot_profile_arn" {
  value = aws_bedrock_inference_profile.support_bot.arn
}

CloudFormation uses the AWS::Bedrock::ApplicationInferenceProfile resource:

SupportBotProfile:
  Type: AWS::Bedrock::ApplicationInferenceProfile
  Properties:
    InferenceProfileName: support-bot-nova-pro
    Description: Front-desk warranty assistant
    ModelSource:
      CopyFrom: !Sub arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:inference-profile/us.amazon.nova-pro-v1:0
    Tags:
      - Key: project
        Value: support-bot

Reference its ARN with !GetAtt SupportBotProfile.InferenceProfileArn in your function's environment variables and in its IAM policy. In the AWS CDK, the same resource is available as CfnApplicationInferenceProfile, and newer versions of the Bedrock constructs add a higher-level wrapper.

Because the model source cannot be edited (next section), changing the model in code means Terraform or CloudFormation replaces the profile with a new one and a new ARN. Wire the ARN through outputs and environment variables, and that replacement is invisible to your application.

What you can and cannot change

• Tags: yes. Add or remove them any time with TagResource and UntagResource on the profile's ARN.
• Model and Regions: no. The model source is fixed at creation. To switch models, create a new profile, move traffic to its ARN, and delete the old one.
• Name: no. Choose names you will be happy reading in cost reports, such as support-bot-nova-pro, and put the model in the name so a model change visibly means a new profile.
• Deletion is immediate: aws bedrock delete-inference-profile --inference-profile-identifier ARN. Any code still calling the ARN starts failing, so move traffic first.

To review what exists: aws bedrock list-inference-profiles --type-equals APPLICATION lists your profiles, and aws bedrock get-inference-profile --inference-profile-identifier ARN shows one profile's source model and Regions.

Everyday profile management from the command line

A handful of commands cover almost everything you will do with profiles after creating them:

# Your application profiles, as a table of name, ARN and status
aws bedrock list-inference-profiles --type-equals APPLICATION \
  --query "inferenceProfileSummaries[].[inferenceProfileName,inferenceProfileArn,status]" --output table

# The AWS-defined cross-Region profiles you can copy from
aws bedrock list-inference-profiles --type-equals SYSTEM_DEFINED \
  --query "inferenceProfileSummaries[].inferenceProfileId" --output text

# One profile: its source model and the Regions it routes to
aws bedrock get-inference-profile --inference-profile-identifier PROFILE_ARN

# Add or change a tag, then remove one
aws bedrock tag-resource --resource-arn PROFILE_ARN --tags key=team,value=front-desk
aws bedrock untag-resource --resource-arn PROFILE_ARN --tag-keys team

# Delete (move traffic off it first)
aws bedrock delete-inference-profile --inference-profile-identifier PROFILE_ARN

Run them in the Region where the profile lives (add --region if it is not your default). A monthly look at the list is worth the minute: profiles nobody calls any more are harmless, but they clutter reports and permission policies.

A budget alert for one workload

Once the tag is active, AWS Budgets can watch a single workload's spending and email you before it surprises you. From the CLI, a monthly $50 budget for the support bot with an alert at 80%:

aws budgets create-budget --account-id 111122223333 \
  --budget '{
    "BudgetName": "bedrock-support-bot",
    "BudgetLimit": {"Amount": "50", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "CostFilters": {"TagKeyValue": ["user:project$support-bot"]}
  }' \
  --notifications-with-subscribers '[{
    "Notification": {"NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN",
                     "Threshold": 80, "ThresholdType": "PERCENTAGE"},
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "you@example.com"}]
  }]'

The tag filter is written as user:KEY$VALUE, so user:project$support-bot matches costs tagged project=support-bot. Add a second notification with NotificationType set to FORECASTED, and Budgets warns you when the month is on course to exceed the limit, days before it actually does. The console's Budgets page builds the same thing with a form, if you prefer.

Jake: "So if the screenshot reader goes wild again, I get an email?"

Ethan: "Before the month is out, not after the bill arrives. That's the whole point of giving it its own name."

Naming and tagging patterns that work

A little planning makes the reports readable for years:

Use the same tag keys you already use on other AWS resources, so Bedrock costs appear in the reports your company already reads. A separate profile per environment (prod and test) is cheap insurance: a runaway test script shows up as a test cost, not a mysterious production spike.

Common inference profile errors and fixes

Setting up cost tracking for a new workload: the checklist

1. Pick the model and decide: one Region (copy the foundation model) or cross-Region (copy the system profile).
2. Create the application profile with a clear name and your standard tags, in Terraform or CloudFormation if you have them.
3. Store the profile ARN in the application's configuration.
4. Give the application's role invoke permission on the profile and on the model in each Region, with the bedrock:InferenceProfileArn condition.
5. Activate the tag keys as cost allocation tags in the payer account, once.
6. Create a budget for the workload's tag value with an alert.
7. After a day of traffic, check Cost Explorer grouped by the tag, and look for any untagged Bedrock spending left over.

Frequently asked questions

The next month's bill came with three lines instead of one. The screenshot reader was the culprit, as Ethan had guessed: staff had started photographing whole screens at full phone resolution instead of cropping the error. A one-line change to resize images cut its cost by more than half. Jake looked at the three lines for a while, then asked if they could do the same for the electricity bill. "Different service," Ethan said, "same idea: you can only fix what you can see."

Revision note. Written October 19, 2026. A bill with one line is a mystery; a bill with one line per workload is a to-do list.