Claude with EU data residency: Bedrock, Foundry or the direct API

What each platform actually guarantees, in its own words

The guarantees differ in who processes the data, not only in where the GPUs sit. That distinction is what survives a legal review, and it is the one most comparison tables skip.

On Bedrock, AWS operates the inference stack. Anthropic's documentation is explicit that Claude in Amazon Bedrock runs with zero operator access, meaning Anthropic personnel have no access to the inference infrastructure. AWS is your processor, your existing AWS data processing agreement applies, and Anthropic is not in the chain for inference at all. That is a genuinely different contractual shape from every other option on the list.

The AWS documentation is also honest about the edges, which is why it is worth quoting rather than summarising. Requests to a geographic inference profile are kept within the AWS regions that form that geography. But by default the data remains stored only in the source region, while input prompts and output results might move outside the source region during cross-region inference, and to the extent AWS stores data for abuse detection, those prompts and results are stored in the destination region. So the abuse-detection copy follows the routing, not your source region choice.

Foundry's position is documented just as clearly, and it is the one that surprises Azure-first organisations. Microsoft states that for both hosting options, Anthropic is the seller and operator of Claude models in Microsoft Foundry and acts as an independent data processor for prompts and outputs. Even on the Azure-hosted option, where ingress, API services and GPU inference all run on Azure, automatic safeguards flag content that might be sent to Anthropic Trust and Safety, and Anthropic personnel review customer content on an exceptions-only basis. Foundry also provides no built-in content filtering for Claude at deployment time, so the safety layer you may have assumed was inherited from Azure OpenAI is not there.

The first-party API is the simplest to assess because there is nothing to assess. Workspace geo, which controls storage at rest and endpoint processing, currently offers one value: us.

Four sentences are worth demanding in writing before any of this goes to a works council:

• Which legal entity is the processor for inference, and which contract covers it.
• Which exact regions the chosen profile or endpoint can route to, enumerated, not summarised as a geography name.
• Where abuse-detection or trust-and-safety copies of prompts and outputs are stored, and for how long.
• Whether human review of flagged content can happen outside the EU, and under whose terms.

Latency is the weakest argument in this decision

Moving inference to Frankfurt shortens the network leg for European users, and for most workloads that saving disappears into the noise of token generation. A single chat turn spends the bulk of its wall-clock time producing tokens, not crossing the Atlantic. Choosing a platform on latency alone is optimising the smallest term.

Physics is not the bottleneck. Contracts and rate limits are.

The strongest counterargument is agentic work, and it is a fair one. An agent that makes thirty sequential model calls to finish one task pays the network leg thirty times, and a fixed per-request cost that is irrelevant in chat becomes visible in an agent loop. If that is your workload, the argument for European inference gets a second, independent justification beyond compliance.

It still does not change the platform choice, because the loop is dominated by what sits between the calls. Retrieval against a data store in another region, a tool call to an on-premise ERP, an MCP server in a third network: each of those adds a hop that the model provider does not control. Co-locate the retrieval and tool layer with the model, and the ordering of the platform decision stays where it belongs, with data residency and feature coverage.

The constraint that actually caps throughput is the rate limit, and the spread there is dramatic. Foundry's pay-as-you-go tier gives Claude Opus 5 forty requests per minute and 40,000 uncached input tokens per minute; the same model on an Enterprise or MCA-E agreement gets 2,000 requests and two million tokens per minute. Bedrock starts at two million input tokens per minute by default and can be raised to four million without additional Anthropic approval. Pick the wrong tier and your architecture is throttled long before physics gets a say.

What Bedrock cannot do, and why EU residency forces you into that choice

The features below are missing from Bedrock at every routing setting, global included. They are the price of the platform, not the price of the region — and EU residency is what makes you pay it, because the only two platforms that keep inference in Europe today are Bedrock and Vertex. Choose Europe, inherit their feature set. That chain is the part most business cases skip, and getting it backwards costs you the argument in front of an architect who already runs Bedrock globally and has never had the Files API.

It is not priced in tokens either. It is priced in the code your team writes to replace a managed feature: batch jobs become a queue you operate, and cost attribution that the Usage and Cost API would hand you has to be rebuilt from CloudWatch and CloudTrail.

Vertex AI is barely better. It keeps the web search tool and drops most of the rest.

The list below comes from Anthropic's own feature matrix for the Bedrock integration, which is a platform-level list with no regional qualifier:

• Files API and URL sources for images and documents.
• Server-side tools: code execution, web search, web fetch, advisor.
• Agent infrastructure: Agent Skills, the MCP connector, programmatic tool calling.
• API endpoints: Message Batches, Models, Admin, Compliance, Usage and Cost.
• The anthropic-beta header, so new capabilities arrive on AWS's release schedule rather than Anthropic's.

# Two lanes behind one gateway. The lane is a property of the data class,
# not of the feature a developer happens to want this week.
from anthropic import Anthropic, AnthropicBedrockMantle

# Lane A - EU-resident. Regional endpoint, 10% premium, AWS is the processor.
eu = AnthropicBedrockMantle(aws_region="eu-central-1")

# Lane B - everything lane A cannot do: Agent Skills, code execution,
# web search, Message Batches. Anthropic is the processor.
open_lane = Anthropic()

RESIDENT = {"personal-data", "works-council", "customer-contract", "hr-record"}

def complete(prompt: str, data_class: str):
    if data_class in RESIDENT:
        return eu.messages.create(
            model="anthropic.claude-sonnet-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": prompt}],
        )
    return open_lane.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        inference_geo="global",
        messages=[{"role": "user", "content": prompt}],
    )