Open the model matrix, filter to eu-west-3, and you will find a healthy list of
models marked available in Paris. Every one of those calls will succeed. For
23 of the 31, the prompt will be processed
outside France.
This is not a bug and AWS is not hiding it. It is simply that Bedrock answers a question nobody asked — can this model be invoked from here — and the console never volunteers the one people actually care about: where does the inference run.
Two questions that look like one
A Bedrock model is callable in a region in one of two ways. Either the bare model ID works
on-demand, in which case the region you addressed is the region that serves you. Or it is
reachable only through a cross-region inference profile — an ID with a
us., eu., apac. or global. prefix — and
Bedrock routes the request to whichever region in that profile's scope has capacity.
Both appear as "available". Only the first is a residency guarantee. The second is a routing policy, and its destinations are published — just not anywhere near the place you choose a model.
What that costs you, by jurisdiction
Counting every model in the catalogue against the routes AWS declares, the picture is lopsided in a way that is hard to unsee:
| Constraint | Available | Stays put | Leaves or unverifiable |
|---|---|---|---|
| United States | 113 | 113 | 0 |
| the European Union | 73 | 68 | 5 |
| France | 31 | 8 | 23 |
| Germany | 41 | 18 | 23 |
In the United States, every single available model — all 113 of them — can be called without the request leaving the country. In France, 8 can. That gap is not about model popularity or launch order. It is structural.
Why the US gets something Europe does not
The reason is in the scopes themselves. A profile's prefix defines a closed set of destination regions, and those sets do not respect borders equally:
- us., au., jp., in., ca. never leave a single country. The four US regions are all in the United States, both Canadian regions are in Canada, and so on. Country-level residency comes free.
-
eu.is bounded to the European Union — but it spans 6 member states: France, Germany, Ireland, Italy, Spain, Sweden. It satisfies "our data stays in the EU" and directly contradicts "our data stays in France". -
global.declares no closed destination set at all.
So an American team asking for national residency gets it by default. A German team asking the
same question gets 18 models instead of 41. And a French team
writing "les données restent en France" into a contract, while calling
eu.anthropic.…, has written something that is not true — the request may be
served from Ireland, Spain, Italy or Sweden depending on capacity that minute.
An eu- region code is not a jurisdiction
The second trap is smaller and catches more people. Two AWS regions carry an
eu- prefix without being in the European Union:
eu-west-2 is London and eu-central-2 is
Zurich. The United Kingdom left the Union in 2020; Switzerland was never a
member.
Both countries hold a European Commission adequacy decision, which makes transferring personal
data there lawful. That is a genuinely useful thing and it is not the same claim as the data
never leaving the Union. On an architecture diagram, eu-west-2 reads as "EU" to
almost every reviewer who has not been burned by it before.
The jurisdictions with nothing at all
There is a worse case than a reduced list. In Israel , Malaysia , Taiwan , Thailand , Mexico , New Zealand and South Africa , the count of models that stay in-country is zero. Every model the matrix offers is profile-only, routed elsewhere. A team in one of those markets that reads the availability column as a residency answer is not choosing badly between options — it has no options, and does not know it.
Why global. gets no verdict here
It would be convenient to report global profiles as "processed in the US". The Bedrock API, asked what a global profile routes to, currently names a single region. But AWS documents global routing as going to any region where the model is deployed. Both statements cannot describe a complete destination list.
So the honest output is neither "compliant" nor "leaves" but unverifiable: there is no published set to check a constraint against. If you need to defend a residency position in writing, a global profile is not a risk you have measured — it is one you have not.
What to actually do
- Decide whether your constraint is a bloc or a country. This is the question that changes the answer most, and it is usually decided by someone who is not in the room when the model gets picked. EU-level is largely fine on Bedrock; country-level is severe.
- Prefer the bare model ID. Where a model is on-demand in your region, calling it directly is the only route that needs no argument about routing policy.
- Treat the profile prefix as a reviewed configuration value. Swapping
anthropic.…forglobal.anthropic.…is a one-word change in a config file that silently moves where your data is processed. It deserves the same scrutiny as a change to a security group. - Check the model, not the vendor. Residency is per model and per region, and it changes when AWS opens capacity. It is not a property of a provider.
The per-jurisdiction verdicts — which models qualify, which exact ID to call, and where each route is declared to go — are on the residency pages, rebuilt daily from the AWS APIs.
This describes where inference executes according to what AWS declares. It is not legal advice, and it does not cover logs, retention, model-improvement terms or where your own application tier runs — all of which belong in the same assessment.