Bedrock, Vertex or Foundry — and 1 of the 3 has no EU option.
Claude runs on three enterprise platforms: Amazon Bedrock, Google Cloud Vertex AI and Microsoft Foundry. Verified 4 August 2026, 1 of the 3 has no EU option — Foundry offers Global Standard and US Data Zone deployments only. Pexon selects the platform against your residency, feature and contract requirements, then deploys that platform inside your own cloud account.
The comparison
Where Claude actually runs, and who processes it
| Platform | EU inference today | The identifier that pins it | Who processes it, who invoices |
|---|---|---|---|
| Amazon Bedrock | Yes — an EU endpoint type in eight European Regions | The EU geography inference profile, or direct in-region routing in Ireland and Stockholm, which the region table marks in-region only | AWS operates the inference infrastructure with zero operator access for Anthropic personnel, and AWS invoices it as a native service |
| Google Cloud Vertex AI | Yes — the eu multi-region endpoint | Region set to eu, which resolves to aiplatform.eu.rep.googleapis.com; single EU Regions only for Claude Sonnet 4.6 and earlier | Google Cloud governs data handling for the offering and invoices it on the Google Cloud bill |
| Microsoft Foundry | No — Global Standard or Data Zone Standard (US) only | Selecting Data Zone creates a US Data Zone Standard deployment, which Anthropic documents as equivalent to inference_geo us | Anthropic is seller, operator and independent data processor on both hosting options; Microsoft bills Claude Consumption Units on the Azure invoice |
All three platforms sell the same enterprise story: your identity provider, your invoice, your network boundary, your security questionnaire. One of them will process a works council document in the United States while telling that story truthfully, because the vendor relationship and the processing location are separate questions and only one of them is what a data protection officer is asking about.
Our own position, from the deployments we run: the last column is the one that decides the argument. Residency is configuration and can be changed in an afternoon. The processor, the invoice and the support path are contracts, and changing those means going back through procurement with a project that is already live.
Checked against vendor documentation on 4 August 2026: Anthropic, Claude in Amazon Bedrock for the EU endpoint type, the in-region Regions and the 10 percent premium on regional endpoints, which the same page distinguishes from the EU geography inference profile it publishes no premium for; Anthropic, Claude on Google Cloud for the eu multi-region endpoint and the model cut-off on single-Region endpoints; and Microsoft Learn, Compare hosting options for Claude models in Microsoft Foundry for the deployment types and the processor chain. All three change. Re-read them before this table is quoted in a contract.
The starting point
The platform gets picked by whichever cloud the company already runs.
It is a reasonable instinct, and it produces the one outcome that is expensive to reverse. An Azure-first estate deploys Claude in Microsoft Foundry because identity, billing and governance are already there — and finds out in the works council meeting that Foundry offers Global Standard and a US data zone, and nothing else. In the rollouts we run, a pilot on the wrong platform is never reconfigured. It is migrated, along with every application that has learned its endpoint, its SDK client and its feature set.
What we build
What we do before anything is deployed
- The residency test, against your requirement. EU, EEA, or one named country are three different constraints and they eliminate different platforms. We test each against the vendor documentation on the day we do it, not against a comparison table from last quarter — regional availability moves, and the sentence you put in front of a data protection officer has to be true this week.
- The endpoint identifier, not the vendor name. The deliverable is the exact string your applications will call: an inference profile ID, a multi-region hostname, a Foundry deployment name and its region scope. A platform name is a procurement answer. An identifier is the thing an auditor can check and a policy can constrain.
- The contract chain, per platform, in writing. Who operates inference, who invoices you, who takes the support call and which agreement covers the processing. These differ across the three, and the difference does not show up anywhere in the code. It shows up in legal review, usually late.
- Deployment in your own account, with the destinations enumerated. The chosen platform deployed against one real workload inside your cloud account: every permitted destination Region named in the IAM or Entra policy rather than implied by a profile name, mirrored where the platform supports it, and invocation logs landing where your security team already looks.
- A second lane for what the EU platforms cannot do. Amazon Bedrock and Google Cloud both drop the Files API, Agent Skills, the MCP connector, programmatic tool calling and the Message Batches, Admin and Usage and Cost endpoints. Choosing Europe means inheriting that, so the work that provably touches no personal data gets its own lane and its own routing rule.
What changes
- The platform decision is made against a written requirement instead of against whichever cloud contract was signed first.
- Where inference runs becomes an identifier your applications call, which means it can be tested, logged and constrained by policy.
- The processor, the invoice and the support path are known per platform before procurement discovers them.
- Feature gaps arrive as a routing decision at design time rather than as a blocked release six months in.
- Changing platform later stops being a migration project, because the applications were never pointed at one directly.
The artefact
Five questions that settle the platform, in this order
This is the sequence we work through in the blueprint. Answer them in order and the shortlist collapses on its own, usually by question three. Answer them out of order and you end up defending a platform that was chosen for a reason nobody wrote down.
- Is the requirement the EU, the EEA, or one named country? Bedrock's EU endpoint type covers eight European Regions, two of which — London and Zurich — sit outside both the EU and the EEA, so the geography name and the legal perimeter are not the same object.
- Does one workload need a single pinned Region, or is a geography enough? That question alone removes Google Cloud for the newest models, where specific regional endpoints stop at Claude Sonnet 4.6.
- Which legal entity do you want as the processor for inference, and does an existing agreement already cover it? On Amazon Bedrock that is AWS, on Google Cloud it is Google Cloud, and in Microsoft Foundry it is Anthropic on both hosting options.
- Which features does the workload actually use? Bedrock and Google Cloud both drop the Files API, Agent Skills, the MCP connector, programmatic tool calling and the Message Batches, Admin and Usage and Cost endpoints; Google Cloud keeps the web search tool, Bedrock does not.
- Who pays, on which invoice, in which unit? Bedrock and Google Cloud bill tokens as native cloud services; Foundry bills Claude Consumption Units through Azure Marketplace, which is a procurement path rather than a line item.
Question one has a machine-readable half. On two of the three platforms the processing location is visible in the hostname your application calls, which means it can be grepped out of a repository and diffed against your record of processing. On the third it is not:
# Where the request actually goes. Checked against vendor docs, 4 August 2026.
# Amazon Bedrock — the Region is in the hostname
https://bedrock-mantle.eu-central-1.api.aws/anthropic/v1/messages
# Google Cloud Vertex AI — the eu multi-region endpoint
https://aiplatform.eu.rep.googleapis.com/v1/projects/$PROJECT/locations/eu/publishers/anthropic/models/claude-opus-5:rawPredict
# Microsoft Foundry — one hostname for every deployment type. Residency lives
# in the deployment's region scope, not in anything a client can read back.
https://$RESOURCE.services.ai.azure.com/anthropic/v1/messagesThat asymmetry is the practical cost of the Foundry path: residency there is a property of the deployment's region scope, so it is audited by screenshot rather than by reading the code.
Related
- Claude in your own cloud tenant — covers the IAM and logging shape once the platform is chosen
- The LLM gateway — how a second lane stops being a second integration
Questions the platform decision raises
Which of Bedrock, Vertex and Foundry can run Claude inside the EU?
Amazon Bedrock and Google Cloud Vertex AI can. Microsoft Foundry cannot, as of 4 August 2026. Anthropic's region table for Amazon Bedrock lists an EU endpoint type in eight European AWS Regions, Google Cloud offers an eu multi-region endpoint that resolves to aiplatform.eu.rep.googleapis.com, and Microsoft documents exactly two deployment types for Claude in Foundry: Global Standard and Data Zone Standard (US).
Who is our data processor on each of the three platforms?
It differs per platform, and that is the part procurement usually misses. On Amazon Bedrock, AWS runs the inference infrastructure and Anthropic documents zero operator access, meaning Anthropic personnel have no access to it. On Google Cloud, data handling for the offering is governed by Google Cloud. In Microsoft Foundry, Anthropic is the seller, the operator and an independent data processor on both hosting options, while Microsoft bills you and takes the support calls.
Can we pin Claude to one single EU region?
On Amazon Bedrock, in two Regions today. Anthropic's region table marks eu-west-1 (Ireland) and eu-north-1 (Stockholm) as in-region only, which the same page defines as supporting direct single-region routing without an inference profile; Frankfurt is reachable through the EU geography profile rather than as a pinned single Region. On Google Cloud, specific regional endpoints support Claude Sonnet 4.6 and earlier, so the newer models are global or eu multi-region only.
What does EU routing cost on top of token prices?
Ten percent on the paths the vendor actually prices that way, and an open question on one that matters. Anthropic documents a 10 percent premium over global endpoints for regional endpoints on Amazon Bedrock and for regional and multi-region endpoints on Google Cloud, for Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 and later models. On Google Cloud the eu multi-region endpoint is a priced path, so 10,000 euros a month of model spend becomes 11,000. On Amazon Bedrock a regional endpoint exists in only two European Regions, Ireland and Stockholm; Frankfurt, Paris, Milan, Spain, London and Zurich are reachable only through the EU geography inference profile, and neither Anthropic nor the Amazon Bedrock pricing page publishes a premium for that profile. Get that line in writing before you budget it.
Does choosing Microsoft Foundry mean giving up Claude features?
On the Azure-hosted option, yes, and the list is published rather than folklore. Anthropic states that deployments hosted on Azure do not support structured outputs, server-side tools such as web search and code execution, the MCP connector, Agent Skills, programmatic tool calling or the Files API, and that requests using them return 400 Bad Request by design. Microsoft separately notes that Foundry provides no built-in content filtering for Claude at deployment time.
Do we have to pick one platform for the whole company?
No, and committing everything to one is usually the expensive answer. The platform is a per-workload property once a gateway sits in front of it, so regulated data can route to an EU endpoint while agentic or batch work that provably never touches personal data runs where the feature set is complete. What has to be single is the place the routing rule is written down and reviewed.
What does Pexon deliver on this decision?
A two-week Readiness Blueprint at €4,900 fixed price: we test your residency, feature and contract requirements against all three platforms, deploy the winner against one real workload in your own cloud account, and hand back the endpoint identifier, the policy that enforces it and the processor chain per platform in writing. Model consumption is billed to you directly by AWS, Google or Microsoft — we do not resell tokens. All prices are net and exclude VAT.
Next step
Start with the two-week Readiness Blueprint.
Fixed at €4,900. We test your residency, feature and contract requirements against all three platforms, deploy the winner against one real workload in your own cloud account, and hand back the endpoint identifier, the policy that enforces it and the processor chain per platform. The document is yours to keep, whoever builds the rest. All prices are net and exclude VAT.