Claude data residency for UK organisations: what you can and cannot keep in region

The first-party Claude API cannot keep your data in the UK or the EU. Anthropic's own documentation limits inference geography to us or global, and workspace geography, which governs data at rest, to the United States only. UK organisations that need in-region processing have to reach Claude through a partner cloud instead: AWS Bedrock or Google Cloud Vertex AI. Both carry a pricing premium, both drop a substantial list of features, and neither offers a UK-only option in the way most buyers assume.

This guide is for the people who have to sign that decision off: compliance leads, data protection officers, IT directors and managing partners at UK firms in regulated sectors. Every product claim below is taken from Anthropic's, Amazon's or Microsoft's own published documentation and is dated, because this area is moving quickly.

It also sets out the point that saves most of the work: UK GDPR does not require personal data to be stored in the UK. Several residency requirements we are asked to design around turn out, on inspection, to be transfer-risk requirements wearing a residency costume.

Data residency and inference residency are not the same thing

Anthropic separates the two concepts, and conflating them is the most common error in this area. Data residency controls where prompts, outputs and conversation history are stored. Inference residency controls where Claude actually processes the request and generates the response. A deployment can satisfy one and not the other, and a procurement question that asks only about storage will miss half the picture.

Anthropic states that regional endpoints on the partner clouds guarantee that both data storage and model processing remain within the specified geographic region. That is the property regulated buyers are actually purchasing, and it is only available on the partner-cloud routes.

What the first-party Claude API offers, and what it does not

On the Claude API bought directly from Anthropic, the inference_geo parameter accepts two values: global, meaning the request may run in any available geography, and us. Anthropic's documentation is explicit under its current limitations: "Inference geo: Only 'us' and 'global' are available." There is no EU value and no UK value.

Workspace geography is more restrictive still. It governs data at rest and endpoint-side processing such as image transcoding and code execution, and Anthropic states that it "is set when you create a workspace and can't be changed afterwards. Currently, 'us' is the only available workspace geo." So even a US-pinned first-party deployment stores data in the United States, and the decision cannot be reversed later without a new workspace.

US-only inference also costs more. Anthropic prices it at 1.1 times the standard rate across every token category: input tokens, output tokens, cache writes and cache reads. Under a Priority Tier commitment, each such token draws down 1.1 tokens from committed throughput rather than one.

Three further constraints matter at implementation time. The parameter returns a 400 error on Claude Opus 4.5, Sonnet 4.5, Haiku 4.5 and earlier models. It is unavailable through the OpenAI SDK compatibility endpoint. And rate limits are shared across geographies, so pinning buys you no additional capacity. Workspace-level controls (allowed_inference_geos and default_inference_geo) can be set in the Console or through the Admin API, which is the practical way to stop a developer defaulting a workload back to global.

One surface has no regional route at all. Claude Managed Agents cannot use inference_geo; Anthropic states it respects the workspace geography configured in the Console, which is US-only. It is also listed among the unsupported features on both partner clouds, so there is currently no in-region path for that surface on any route.

The partner-cloud routes: what each one actually gives you

AWS Bedrock and Google Cloud Vertex AI are the two routes to genuine in-region deployment. Microsoft Foundry is a third platform but has no European option yet.

Route	UK or EU option	Premium	Key limitation
Claude API, first party	None. Inference us or global; storage US only	1.1x standard rates for US-only inference	Workspace geography is immutable once set
AWS Bedrock	Yes. EU inference profile, plus single-region routing in Ireland and Stockholm	10% over global endpoints for regional endpoints	London is not an in-region-only endpoint; large feature list unsupported
Google Cloud Vertex AI	Yes. EU multi-region endpoint; single-region only up to Sonnet 4.6	10% over global endpoints	Newest models cannot be pinned to one region; EU multi-region excludes the UK
Microsoft Foundry	Not yet. Anthropic lists Europe as coming in 2026	Not applicable	Deployments run Global Standard, so inference can happen anywhere

Note that the premiums sit on different bases and should never be combined into a single figure. The 1.1x applies to first-party US-only inference. The 10% applies to regional endpoints on the partner clouds. What they have in common is the underlying point: on every route currently available, keeping Claude in a region costs more than letting it run globally.

The London problem, and why it matters

This is the detail most UK buyers are getting wrong, including in guidance circulating inside government.

Amazon Bedrock lists eu-west-2 (Europe, London) with endpoint types "Global, EU". It does not mark it "in-region only". Only eu-west-1 (Ireland) and eu-north-1 (Stockholm) carry that designation, and Anthropic's documentation states that regions marked in-region only "support direct single-region routing without an inference profile". In other words, the closest thing to true single-region pinning in Europe is Ireland or Stockholm, not London.

A UK firm that specifies "AWS London" believing it has bought single-region processing has bought something else. What it has is access through the EU inference profile, which routes across European regions collectively.

That collective routing carries a second trap for anyone writing a transfer risk assessment. Bedrock's EU-tagged region list includes eu-central-2 (Zurich). Switzerland is not in the EEA. Any assessment that treats "EU" as synonymous with "EEA" and stops there will have missed a transfer. The full EU-tagged list runs London, Ireland, Paris, Frankfurt, Zurich, Stockholm, Milan and Spain.

On Google Cloud the constraint is different but no less awkward: Anthropic states that specific regional endpoints support Claude Sonnet 4.6 and earlier, while newer models use the global or multi-region endpoints. If you want Claude Opus 5 or Sonnet 5, single-region pinning is not available to you. The strictest option is the EU multi-region endpoint, and the EU multi-region does not include the United Kingdom.

What in-region deployment costs you in features

The premium is the visible cost. The feature losses are the one that derails projects after the contract is signed, because they are usually discovered during build rather than during procurement.

On Bedrock, Anthropic lists the following as unsupported: the Files API, URL input sources, all server-side tools (code execution, web search, web fetch and the advisor tool), Agent Skills, the MCP connector, programmatic tool calling, Message Batches, the Admin, Usage and Cost APIs, and Claude Managed Agents. Google Cloud loses the same list with one exception: web search is supported there.

Read that list against your intended architecture before you choose a route. A workflow designed around the MCP connector and Agent Skills, which is a common shape for internal knowledge assistants, does not survive a move to Bedrock without redesign. If connecting Claude to business systems is central to your plan, our guide to connecting Claude to business systems sets out what that layer normally involves.

There is a compensating benefit worth naming, because it is the substantive thing regulated buyers are buying. Anthropic states that Claude on Bedrock "runs on AWS-managed infrastructure with zero operator access", meaning Anthropic personnel have no access to the inference infrastructure. For a firm whose concern is third-party operator access rather than geography as such, that property may matter more than the region label.

What UK GDPR actually requires, which is not what most briefs assume

UK GDPR does not require personal data to be stored in the United Kingdom. It regulates restricted transfers, which the ICO defines as making personal information accessible to a separate organisation outside the UK. A restricted transfer is lawful where it rests on adequacy regulations, on appropriate safeguards such as the UK International Data Transfer Agreement or the Addendum to the EU Standard Contractual Clauses, or on a derogation. Where a safeguard is relied on, a transfer risk assessment is required.

This distinction is worth several weeks of project time. A requirement expressed as "our data must stay in the UK" is frequently, on examination, a requirement that the transfer be properly assessed and contractually covered. That is a different and usually cheaper problem, and it does not necessarily push you onto a partner cloud at a 10% premium with a truncated feature set.

On the contractual side, Anthropic's Data Processing Addendum contains a dedicated UK Addendum at Schedule 3, Part B, applying to processing subject to UK GDPR and layered on the EU Standard Contractual Clauses, with fifteen days' notice on new sub-processors. That is the instrument a UK transfer risk assessment would be built around. Our guide to whether Claude is GDPR compliant covers the wider retention and training position plan by plan, and the briefing on the Data (Use and Access) Act 2025 covers the automated-decision rules that sit alongside.

How to decide, in practice

A workable sequence for a UK firm, in the order that saves the most wasted effort:

• Establish whether you have a residency requirement or a transfer requirement. Ask what the requirement is protecting against and where it came from. If it originates in a client contract, read the clause: many specify safeguards rather than geography. This one question decides the rest.
• If it is genuinely residency, decide between storage and processing. The partner-cloud regional endpoints cover both. Nothing else does.
• Check your model requirement against the route before you commit. If you need the newest Opus or Sonnet models on Google Cloud, single-region pinning is off the table.
• Check your feature requirement against the unsupported list. Do this before contract, not during build. The MCP connector, Agent Skills and the Files API are the ones that most often turn out to be load-bearing.
• Price the premium honestly. Add 10% to the token line for regional endpoints, or 1.1x for first-party US-only, and carry it into the business case rather than discovering it in month two.
• Write the transfer risk assessment against the actual region list. If you are using the Bedrock EU inference profile, the assessment covers eight regions including Zurich, not one.

What not to do: do not specify "AWS London" as shorthand for single-region UK processing, because it is not that. Do not assume the EU multi-region endpoint covers the UK, because it does not. And do not let a residency requirement be adopted into a project charter without anyone checking whether UK GDPR actually imposes it, because more often than not it does not.

Where The AI Consultancy fits

Establishing whether a stated residency requirement is real, choosing between the routes, and pricing the premium and the feature losses honestly is the analysis stage of our Claude implementation engagements. For firms in regulated sectors the same question usually arrives alongside a wider governance review, which our AI readiness assessment covers, and our guide to Claude for UK financial services sets out how it lands under FCA expectations. Where the answer is that no cloud route satisfies the requirement, the private AI concierge service covers on-premises deployment instead.

All product claims verified on 31 July 2026 against Anthropic's platform documentation (platform.claude.com), Anthropic's regional compliance page, Amazon's and Google's Claude platform pages, and Microsoft's Foundry documentation. Anthropic lists Europe as "coming 2026" for Microsoft Foundry, so this position is expected to change. Confirm current availability before committing to a route. This article is general information, not legal advice; confirm your own transfer obligations with a qualified adviser.