Which data centre processes Claude? Trace the connection and restrict processing to Switzerland or the EU

Anyone using Claude via claude.ai, Claude Code or the API cannot determine which data centre processes the request. Only the first segment of the connection, up to the nearest edge node, is visible. For companies that submit personal data or confidential content to a language model, this is insufficient: they need to be able to demonstrate to customers, data protection advisers or auditors where processing takes place.

This article shows how far the connection itself can be traced, what is publicly known about Anthropic’s data centres and which routes can reliably restrict processing to the EU or the EU-plus-Switzerland area. Prices and regions are current as of 2 October 2026.

Switzerland focus: The revised Federal Act on Data Protection (revFADP) is decisive. Disclosure of personal data abroad is permitted under Art. 16 revFADP if the Federal Council certifies that the destination state provides adequate protection (Annex 1 of the Data Protection Ordinance, DPO) or if suitable safeguards such as standard contractual clauses are in place. EU and EEA states are on this list, while the US is included only for companies certified under the Swiss-U.S. Data Privacy Framework. A processing location in the EU therefore makes the justification considerably easier, but does not replace the other obligations (data processing agreement, informing data subjects, data security).

EU note: Companies based in the EU are instead subject to Arts. 44 et seq. GDPR. The European Commission has recognised Switzerland as providing an adequate level of data protection (adequacy decision 2000/518/EC, confirmed in January 2024); processing in Zurich is therefore not a problematic third-country transfer for EU companies.

Which stages a request to Claude passes through

A request to claude.ai or api.anthropic.com passes through three stages:

The host names claude.ai and api.anthropic.com both resolve to address 160.79.104.10. It belongs to prefix 160.79.104.0/23, which is registered to Anthropic (AS399358) and is validly originated by Anthropic according to RPKI. In global routing, however, the prefix is advertised exclusively via Cloudflare (AS13335): Anthropic brings its own IP addresses into Cloudflare’s anycast network. The same address is therefore answered from every Cloudflare location worldwide, and the connection reaches the nearest edge node.

Determine the edge node itself

Cloudflare reveals the serving location on a diagnostic page and in the cf-ray header. The abbreviation after the Ray ID is an IATA airport code: ZRH stands for Zurich, GVA for Geneva, FRA for Frankfurt and MRS for Marseille.

curl -s https://api.anthropic.com/cdn-cgi/trace

The relevant lines in the output are colo= (edge location) and loc= (the country to which Cloudflare assigns your source address). On Windows, PowerShell provides the same result:

$trace = Invoke-WebRequest -Uri "https://api.anthropic.com/cdn-cgi/trace" -UseBasicParsing
$trace.Content

Read the header with a HEAD request:

curl -sI https://api.anthropic.com/ \
  | grep -i -E '^(server|cf-ray):'

Options explained

Option	Effect
-s	Suppresses curl’s progress meter and error messages
-I	Sends a HEAD request and outputs only the response headers
grep -i	Searches without regard to upper or lower case
-E '^(server|cf-ray):'	Extended regular expression: only lines beginning with server: or cf-ray:

From a Swiss network, ZRH or GVA can generally be expected. If the internet egress is elsewhere, for example in a corporate network with central egress abroad, the edge node there responds, such as with colo=FRA or colo=MRS. The edge location thus follows your network egress, not the processing location.

Why traceroute ends at the edge

A traceroute shows the route as far as the edge node, and no further:

Test-NetConnection -ComputerName api.anthropic.com -TraceRoute -Hops 20

Options explained

Option	Effect
-ComputerName api.anthropic.com	Measurement target host
-TraceRoute	Determines the router hops on the route to the destination
-Hops 20	Maximum number of hops to check

On Linux and macOS, the equivalent is traceroute -n api.anthropic.com (-n suppresses DNS resolution of the hops). In the measurement, the final hops before 160.79.104.10 were in address range 162.158.0.0/15, which belongs to Cloudflare. The trace then ends: the connection is terminated at the edge node, while forwarding to the backend occurs over a new internal connection that is not visible externally.

RIPEstat shows who owns the prefix and through which network it is advertised:

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=160.79.104.10"
curl -s "https://stat.ripe.net/data/bgp-state/data.json?resource=160.79.104.0/23"

In the second result, all AS paths end at 13335 399358: Cloudflare is the sole upstream for Anthropic’s prefix.

According to my research, no public measurement traces the route through to an inference data centre, and because of termination at the edge, this is not possible with network tools either. Measurement services such as llmlatency.dev capture only the time to first byte at the edge (as of September 2026: median 96 ms from US Central, 199 ms from Germany). While time to first token could be compared across several locations, it depends more on the model, prompt length and load than on distance. It therefore cannot reliably indicate a location.

What is known about Anthropic’s data centres

Anthropic does not yet operate a dedicated inference data centre with a publicly assigned address. The compute capacity comes from partnerships compiled by Tim Cadenbach in the TCDEV blog:

Training and inference do not necessarily take place in the same location. Inference can run in any AWS or Google Cloud region, and Anthropic does not disclose which location computes the response for a user in Switzerland. The only confirmed information is in the privacy policy: Anthropic Ireland, Limited in Dublin is the contracting party and controller for customers in the EEA, the United Kingdom and Switzerland; data is transferred to servers in the US or other countries outside the EEA, based on standard contractual clauses.

Control directly at Anthropic: US or global only

Since generation 4.6 models, the Claude API has supported parameter inference_geo. It has exactly two values:

There is no value for the EU or Switzerland. The Workspace storage location (workspace geo) can currently only be set to us. The response reports in field usage.inference_geo which setting was applied, but not a specific region. For Haiku 4.5 and older models, the API acknowledges the parameter with a 400 error.

For claude.ai and Claude Code with a subscription (Pro, Max, Team, Enterprise), there is no processing-location setting. Through Anthropic’s direct offerings, processing can therefore be restricted neither to the EU nor to Switzerland. This is possible only through cloud providers that operate Claude in their own regions.

AWS Bedrock: EU-plus-Switzerland area from Zurich

AWS Bedrock runs Claude on AWS infrastructure. According to AWS, Anthropic has no access to customers’ prompts, responses or logs. You choose the region through the source region of your API call and through the Inference Profile:

For Switzerland, region eu-central-2 (Zurich) is relevant. Opus 5.5, Sonnet 5.5 and Haiku 4.5 are available there, but only as Global or EU profiles and not In-Region. No profile exists that computes exclusively in Zurich. If the EU profile is called from Zurich, AWS distributes requests according to the model card (documented for Haiku 4.5 and Sonnet 4.6) across these regions:

Zurich is a possible destination only if the request originates from Zurich. Processing therefore remains in the EU-plus-Switzerland area. For Opus 5.5 and Sonnet 5.5, the model card does not state the destination regions; the API returns the actual list:

aws bedrock get-inference-profile \
  --region eu-central-2 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-5-5 \
  --query "models[].modelArn"

Options explained

Option	Effect
bedrock get-inference-profile	Reads the definition of an Inference Profile
--region eu-central-2	Zurich source region; the destination list depends on the source region
--inference-profile-identifier	EU profile ID for Sonnet 5.5
--query "models[].modelArn"	Outputs only model ARNs; the region is included in each ARN

By default, data is stored only in the source region. Content retained for abuse detection is an exception: it is held in the destination region. Transfer between regions is encrypted over the AWS network.

Document the processing region for each request

Bedrock is the only route described that records the actual processing region for each request. CloudTrail writes it in the source region to field additionalEventData.inferenceRegion:

aws cloudtrail lookup-events \
  --region eu-central-2 \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com \
  --max-results 20 \
  --query "Events[].CloudTrailEvent" \
  --output text \
  | jq -r '[.eventTime, .eventName, .additionalEventData.inferenceRegion] | @tsv'

Options explained

Option	Effect
cloudtrail lookup-events	Searches CloudTrail events from the past 90 days
--region eu-central-2	Source region in which calls are logged
--lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com	Filters for Bedrock events
--max-results 20	Limits output to 20 events
--query "Events[].CloudTrailEvent"	Outputs only the complete event as JSON text
--output text	Output without a JSON wrapper, one event per line
jq -r '… | @tsv'	Extracts timestamp, action and processing region as a tab-separated line

In addition, a Service Control Policy (SCP) in AWS Organizations can block all regions outside the EU and Switzerland. If a profile’s destination region is blocked, the request fails instead of falling back to another region. With this combination, the processing location is technically enforced and verifiable for each request.

Claude Code via Bedrock in the EU

Claude Code can also run via Bedrock. In an eu-* region, Claude Code automatically selects prefix eu.:

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-central-2
claude

Prefix ANTHROPIC_BEDROCK_REGION_PREFIX can be used to override the prefix. AWS authentication uses the usual mechanisms (profile, SSO, environment variables). Billing is through the AWS account, not a Claude subscription.

Google Vertex AI: EU only, explicitly excluding Switzerland

On Google Cloud (Vertex AI, now called Gemini Enterprise Agent Platform), the situation is less favourable for Switzerland:

Google explicitly excludes Switzerland from the EU multi-region endpoint: it covers EU member states only; the United Kingdom and Switzerland are not included. Several Swiss guidance pages cite europe-west6 as a route to Claude in Zurich; according to Google’s official location table, no Claude model is available there. Google does not document a log field containing the actual processing region for each request. For the global endpoint, Google states that the processing region can neither be controlled nor determined.

Vertex AI is therefore suitable for processing exclusively in the EU, but not for processing in Switzerland.

Microsoft Foundry: currently no EU option

Microsoft offers Claude in Foundry in two variants. “Hosted on Azure” computes on Azure infrastructure, either as Global Standard or Data Zone Standard; the Data Zone for Claude exists only for the US. “Hosted on Anthropic” computes on Anthropic infrastructure, and Microsoft notes that data may be processed outside Azure and outside the selected region. Anthropic lists Foundry for Europe as “Coming soon”. In Microsoft 365 Copilot and Copilot Studio, Anthropic models are excluded from the EU Data Boundary and are disabled by default in the EU, EFTA (including Switzerland) and the United Kingdom.

Overview: which route guarantees which processing location

No provider currently offers a route that guarantees Claude processing exclusively in Switzerland. AWS Bedrock with Zurich as the source region and the EU profile comes closest. If it must additionally be ruled out that data leaves the EU (for example, due to contractual commitments to EU customers), the EU profile can be called from an EU region such as Frankfurt; Zurich is then no longer a destination.

What regional binding costs

All three cloud providers and Anthropic itself charge a 10% premium for binding to a region or geography compared with the global endpoint. For Bedrock, prices are based on the source region; Zurich, Frankfurt and North Virginia cost the same. Routing between regions incurs no additional charge.

List prices in USD per 1 million tokens (input / output):

For Vertex AI, the EU-column price applies to Haiku 4.5 and Sonnet 4.6 in region europe-west1. An example calculation for an internal application with 50 million input and 10 million output tokens per month:

Regional binding therefore costs 10% more than the global endpoint. Compared with Anthropic’s direct list price with inference_geo: "us", an EU profile on Bedrock costs the same. Other overheads tend to weigh more heavily in the decision: an AWS or Google Cloud account with organisational policies, logging and budget alerts must be set up and operated, and fixed monthly Claude subscription prices are replaced by pure usage-based billing. Whether switching pays off depends on volume; a subscription has a fixed price per person, but provides no control over the processing location.

Retention and training

Alongside location, how long data is stored also matters:

• Anthropic API: Prompts and responses are not used for training unless explicit consent is given. Zero Data Retention (ZDR) is available on request per organisation and can be combined with inference_geo. Content flagged by abuse detection remains stored for up to two years even with ZDR. The Fable and Mythos models require retention for 30 days.
• AWS Bedrock: Content is not sent to Anthropic. Retention can be selected per model between none, default and aws_review; Fable requires aws_review with storage for up to 30 days for review by AWS.
• Google Vertex AI: Google uses the data for training or fine-tuning only with prior consent.