An inference profile is Bedrock's routing construct: it pairs a foundation model with a set of AWS regions that requests may be served from. Instead of invoking Claude in exactly one region, you invoke the profile, and Bedrock picks a destination region dynamically. Two flavors exist: geographic profiles, which keep requests within one geography (US, EU, APAC and similar groupings), and global profiles, which may route to any supported commercial region.
Which combinations Bedrock supports
You do not compose arbitrary region lists — you pick from the combinations AWS defines. On the current "Claude in Amazon Bedrock" surface, that means a Global endpoint (dynamic routing across all available regions), geographic inference profiles for the US, EU, JP, and AU geographies, or a Regional endpoint pinned to one region for data-residency needs. On the legacy InvokeModel/Converse surface the same idea appears as a prefix on the model ID itself: global.anthropic.claude-opus-4-6-v1 routes globally, while us., eu., jp., or apac. prefixes constrain routing to that geography.
Coverage is broad but not uniform. The global endpoint is available from 27 AWS regions — including us-east-1, us-east-2, us-west-2, eu-west-1, eu-central-1, ap-northeast-1, and ap-southeast-2 — and covers Claude Fable 5, Opus 4.8, Opus 4.7, Sonnet 5, and Haiku 4.5. Direct single-region ("in-region only") access is a shorter list: us-east-1, us-east-2, us-west-2, eu-west-1, eu-north-1, ap-northeast-1, and ap-southeast-4. Model availability varies by region, so check AWS's models-by-region documentation before committing an architecture to a specific region.
Designating a home region
Even with cross-region routing, every request has a source region — the region whose Bedrock endpoint you call. Treat this as your home region. It matters for three reasons:
Billing. Pricing is based on the region from which you call the inference profile, with no additional routing charge — the destination region Bedrock picks does not change your bill.
Auditing. All cross-region requests are logged in CloudTrail in the source region; the additionalEventData.inferenceRegion field records where each request was actually processed. Your audit trail lives at home even when compute doesn't.
Quotas. Cross-region capacity is governed by quotas such as "Cross-Region InvokeModel tokens per minute" in the account and region you call from, so home-region choice determines which quota pool you draw on.
Pick the home region closest to your application servers, confirm your target Claude model is reachable from it, and route all traffic through that single entry point.
Latency versus throughput
| Choice | You gain | You trade |
|---|---|---|
| Global profile | Largest capacity pool; AWS cites ~10% cost savings vs geographic/standard pricing | Requests may be served far from users; data leaves the geography |
| Geographic profile (US / EU / JP / AU) | Multi-region capacity while data stays in the geography | Smaller pool than global |
| Regional (single region) | Strict residency; predictable locality | One region's capacity only; 10% pricing premium over global for Sonnet 4.5 and later models |
The intuition: the wider the routing scope, the more throughput headroom you get during demand spikes, because Bedrock can shift load to whichever region has capacity. The narrower the scope, the more predictable your data location — at a price. Note the pricing asymmetry runs opposite to what many teams expect: global routing is the cheaper option, and pinning to a single region costs a premium on recent Claude models.
Two setup details that bite later
Service control policies (SCPs). Geographic profiles need every destination region in the geography allowed by your SCPs; global profiles additionally require allowing "aws:RequestedRegion": "unspecified". Cross-region routing can send requests to regions you never manually enabled in the account, so review this with whoever owns your AWS organization policies. Traffic stays on the AWS network, encrypted in transit — it never crosses the public internet.
Provisioned Throughput. Inference profiles do not support Provisioned Throughput. If you buy dedicated capacity, it is pinned to a region, and your routing design has to account for that separately — see the Provisioned Throughput guide.
Where to go next
Designing failover with inference profiles builds on this setup for high availability, and the cross-region inference overview covers the routing mechanics in more depth.