Bedrock's cross-region inference profiles come in two ownership models. The profiles AWS predefines — geographic (US, EU, APAC and similar) and global — are managed objects: every account sees the same ones, and they exist to spread traffic across regions. An application inference profile, by contrast, is a profile you create in your own account. It wraps a foundation model (directly or via one of the AWS-managed routing profiles) in a resource that carries your account ID, your chosen name, and your tags. Functionally you invoke it the same way; organizationally it becomes a unit you can name, permission, and meter per application.
Why bother creating your own profile?
Cost attribution. When three internal products all call anthropic.claude-sonnet-5 through the same account, their spend is indistinguishable on the bill. Give each product its own application inference profile and tag it, and Bedrock usage can be broken out per workload using AWS's standard tag-based cost tooling. For a finance team running chargeback, this is usually the whole motivation. (See cost allocation tags for Bedrock.)
Region control. An application profile lets you decide what sits underneath: a single-region model for residency-sensitive workloads, or an AWS-managed multi-region profile when throughput matters more than location. The choice is made once, in the profile, rather than scattered through application code.
Cleaner IAM. Because a profile is a first-class resource with an ARN of the form arn:aws:bedrock:{region}:{account-id}:inference-profile/*, you can write IAM policies that grant a service role access to its profile and nothing else. Remember the documented requirement that profile-based invocation needs bedrock:InvokeModel allowed on both the inference-profile ARN and the underlying foundation-model ARN.
Creating and using one
Application inference profiles are created through Bedrock's control-plane APIs or the console — you supply a name, the model or managed profile to wrap, and tags. The exact API parameters and console flow evolve, so follow the current Amazon Bedrock user guide for the creation steps rather than a blog snapshot. Once created, the profile's ARN or ID takes the place of the model ID in your invocation call on the classic Bedrock surface, and CloudTrail records invocations against it like any other Bedrock call.
Limits worth knowing before you standardize on them
Three boundaries from the official documentation shape how far this pattern stretches:
- Endpoint scope. Custom (application) inference profile quotas apply only to the legacy
bedrock-runtimeendpoint — they are not a feature of the newerbedrock-mantleendpoint that serves the current "Claude in Amazon Bedrock" Messages API. If your stack is on the new surface withAnthropicBedrockMantle, plan cost attribution around tagging and account boundaries instead. - No Provisioned Throughput. Inference profiles are an on-demand mechanism; they do not support Provisioned Throughput. Reserved capacity is a separate arrangement.
- Account quotas still govern. A profile doesn't grant capacity — your account's per-model, per-region quotas still apply, and there are per-account limits on custom profiles themselves. Check the Service Quotas console for current values.
Managed profile or your own: a quick decision
| Situation | Use |
|---|---|
| One team, one workload, needs throughput | AWS-managed geographic or global profile |
| Multiple workloads sharing an account, need per-app cost lines | Application inference profile per workload |
| Residency-pinned workload in one region | Application profile wrapping a single-region model |
| Guaranteed reserved capacity | Provisioned Throughput (not profiles) |
Where to go next
Pair this with Bedrock in Cost Explorer for the reporting side, and IAM condition keys for restricting which principals may touch which profiles. The platform overview compares cost-attribution approaches across clouds.