Inference profiles, decoded: what us., eu. and global. actually do

The prefix on a Bedrock model ID decides where your prompt is processed, what it costs, and whether the call works at all. Here is what each one means.

Dorian Richard 8 min read

Every figure below is recomputed from the AWS APIs at build time, not typed into the text. Data Aug 27, 2026 , snapshot Aug 27, 2026.

Sooner or later a Bedrock call fails with a validation error saying the model requires an inference profile, and you paste a prefix in front of the model ID until it works. It works. You move on. What you have just changed is where your prompt is processed, what it costs, and how many regions can absorb your traffic — three decisions made by one string.

There are 8 distinct scopes in the catalogue today and 52 of the 116 models carry at least one profile. Here is what each prefix actually means.

What a profile is

A cross-region inference profile is an alias that points at the same model deployed in several regions. You call the alias; Bedrock picks a destination from its set based on available capacity. That buys two things — burst headroom beyond a single region's quota, and access to models that are not deployed on-demand where you are — and it costs you the certainty of knowing which region served the request.

You cannot opt out selectively. For 37 models there is no region at all where the bare ID works: a profile is the only way in.

Every scope, and where it routes

Prefix Models Destinations Crosses a border?
us. 49 4 regions · United States no — one country
eu. 21 6 regions · France, Germany, Ireland, Italy, Spain, Sweden yes — 6 countries
global. 18 not published unknown
apac. 11 10 regions · Australia, India, Indonesia, Japan, Singapore, South Korea, Taiwan yes — 7 countries
au. 8 2 regions · Australia no — one country
jp. 6 2 regions · Japan no — one country
in. 2 2 regions · India no — one country
ca. 1 2 regions · Canada no — one country
Destinations are the regions each profile declares through ListInferenceProfiles.

The asymmetry in the last column is the part worth internalising. Some prefixes are geography and some are jurisdiction, and they look identical.

A concrete one

Nova 2 Lite ships with 4 profiles:

  • eu.amazon.nova-2-lite-v1:0 → Germany, Sweden, Italy, Spain, Ireland, France
  • global.amazon.nova-2-lite-v1:0 → United States
  • jp.amazon.nova-2-lite-v1:0 → Japan
  • us.amazon.nova-2-lite-v1:0 → United States

Four IDs for one model, differing by three characters, resolving to different countries. Nothing in the SDK signature suggests they are anything other than interchangeable.

The global. special case

Global profiles are the newest and the most misunderstood. They route to whichever region worldwide can serve the request, which is exactly what you want for a latency-insensitive workload that must never queue — and exactly what you cannot use under any residency constraint, because there is no published destination list to check against.

They are also, for the models that have both, the cheaper option: regional profiles like us. and eu. carry roughly a 10% premium over the global. rate on recent models. That pricing gradient quietly pushes toward the variant with the weakest guarantees, which is worth knowing before someone optimises the bill without being told what they traded.

Where you will actually hit this

Profile-only access is not evenly spread. In us-east-1 it is close to irrelevant; in several regions it is the majority of the catalogue:

Region Available Profile-only Share
US West (N. California) us-west-1 24 24 100%
Canada West (Calgary) ca-west-1 17 17 100%
Mexico (Central) mx-central-1 11 11 100%
Asia Pacific (Taipei) ap-east-2 20 20 100%
Asia Pacific (Melbourne) ap-southeast-4 20 20 100%
Asia Pacific (Malaysia) ap-southeast-5 20 20 100%
Regions with at least ten models available, ranked by profile-only share.

Four rules that save arguments later

  1. Treat the prefix as configuration, not syntax. It belongs in a reviewed config value with a comment explaining the choice — not appended by whoever was debugging the validation error.
  2. Prefer the bare model ID where it works. It is the only form whose destination is not a policy decision, and it is what makes a residency claim checkable.
  3. Do not assume the prefix matches the region code. eu-west-2 is United Kingdom and eu-central-2 is Switzerland — neither is in the European Union, whatever the eu- suggests.
  4. Re-check after every model launch. A model that was profile-only in your region at launch often becomes on-demand there later. The constraint you designed around may have quietly lifted.

Which models need a profile in which region is on the availability matrix, the exact IDs are on each model page, and the jurisdictional consequences are worked out on the residency pages.

All notes · RSS