Claude on AWS, the EU way

A CTO forwards the AWS announcement to their compliance lead with one line: "Claude on AWS: sovereign, sorted." It isn't sorted. The name hides a fork in the road, and one path sends your prompts out of the EU.

In May 2026, AWS launched Claude Platform on AWS. It's a genuinely great release: your developers point Claude Code, Claude Cowork, the desktop app, or any SDK at your AWS account and get Anthropic's full native experience (Skills, MCP, web search, code execution) with no separate Anthropic contract, no second invoice, no new logins.

For a regulated Nordic organisation, that announcement raises one question that matters more than all the others: where does our data actually get processed? Answer it wrong and it surfaces as a finding in your next audit, long after a quick fix would have solved it.

At first glance this looks like a compliance problem. It's really a configuration choice. Two paths, one clear difference, and once you know which is which, keeping your data in the EU is a setting you own. Here's how they compare.

"Claude Platform on AWS" is a great dev experience: not a residency control

Read the AWS announcement carefully and the key sentence is hiding in plain sight. Claude Platform on AWS is operated by Anthropic, and your requests are processed outside the AWS security boundary. AWS's own FAQ is blunt about it: the data you send, plus its metadata, is processed by Anthropic outside of AWS in a location of Anthropic's choosing.

AWS even names the audience: Claude Platform on AWS is for organisations without strict regional data residency requirements. That is the opposite of a sovereignty product. It's a developer-experience product with AWS-grade plumbing bolted on: IAM for auth, AWS Marketplace for billing, CloudTrail for the audit trail.

None of this makes it a bad product. The IAM, billing and CloudTrail story is real and useful. It's just not the answer to "does our data stay in the EU." For that, you take the other road.

If data must stay in the EU, Claude on Amazon Bedrock is the foundation

Claude on Amazon Bedrock is the other road, and it's the one you can put in front of an auditor. Your data is processed inside AWS infrastructure, in an EU region. AWS processes it and does not share it with Anthropic or any third party. You also get the AWS-managed controls that compliance teams actually ask for: Guardrails for content filtering, Knowledge Bases for retrieval, and PrivateLink so traffic never touches the public internet.

There's a nuance that matters for a compliance reader, because "in the EU" has two distinct meanings on Bedrock:

In-Region: your data never leaves one region

The strictest setting. The request is processed entirely within the single region you name. For the current Claude models, in-region EU hosting is available here:

Use this when a regulation, a customer contract, or your own policy demands single-region processing, common in health, public sector, and parts of finance.

EU Geo (cross-region): data stays within the EU, routed for capacity

Bedrock routes intelligently within the EU geography to absorb traffic spikes. Prompts and outputs may move between EU regions, but never outside the EU. Claude Opus 4.8 and Sonnet 4.6 both support EU Geo across Frankfurt, Paris, Stockholm, Ireland, Milan, Spain, Zurich and London.

This is the right fit when your residency obligation is tied to the EU as a geography (which is how most GDPR-driven requirements are actually written) rather than to one specific data centre.

The thing to avoid by accident is the third option, Global cross-region, which routes to any commercial region worldwide. Great for throughput, wrong for residency. On Bedrock you choose this deliberately through the model ID prefix (eu. vs global.), so the boundary is a configuration decision you own and can prove.

The comparison that settles it: AWS vs. buying Claude direct

Here's where it gets stark. Many teams assume going straight to Anthropic (the first-party API or Claude.ai) is the simplest route to Claude. It is simple. It just has no EU residency setting. Anthropic's own docs are explicit: the direct API's inference_geo parameter accepts only us or global. There is no eu value, and data-at-rest (workspace geo) is US-only. global might touch Europe, but the docs do not guarantee it. For a regulated EU organisation, "might" is not a control.

So the real choice for an EU compliance owner isn't Claude vs. no-Claude. It's Claude through AWS vs. Claude bought direct, and on residency they are not close.

The direct path isn't wrong for everyone. If Standard Contractual Clauses are an acceptable safeguard for a given dataset, buying direct works fine. It's just a legal mechanism, not a geographic one, and if your obligation is "data stays in the EU," only the AWS path answers it. (Google Vertex AI offers an EU-resident route too; we'll cover the multi-cloud picture another day. Today's point is narrower: direct Anthropic is the one mainstream path with no EU residency setting at all.)

How to point your tools at Claude on Bedrock (EU)

Here's the part that surprises people: you don't switch tools, you switch where they send the request. The same Claude Code, the same IDE extension, the same Cowork desktop app: you just set a couple of environment variables and they route through Bedrock in an EU region instead of the direct API. No new client, no Anthropic key, no subscription.

Claude Code (CLI) and the IDE extension

Two variables turn it on. The EU bit is the eu. model-ID prefix plus an EU AWS_REGION: that's what keeps inference inside the EU geography. Put this in ~/.claude/settings.json:

{
  "awsAuthRefresh": "aws sso login --profile cloud2-eu",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_PROFILE": "cloud2-eu",
    "AWS_REGION": "eu-north-1",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "eu.anthropic.claude-opus-4-8",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "eu.anthropic.claude-sonnet-4-6"
  }
}

The VS Code / JetBrains extension reads the same settings file, so once the CLI is routed, your editor is too. Prefer the guided path? Run claude, pick 3rd-party platform → Amazon Bedrock, and the wizard writes this block for you, just choose an EU region and EU model IDs when it asks.

Cowork / the Claude desktop app

No env vars here: it's a UI. Open the desktop app's setup screen, choose Amazon Bedrock as the backend, then enter your AWS region (e.g. eu-north-1) and the same EU model IDs. It shares the AWS credentials already on your machine, so a developer who has the CLI working is seconds away from having the desktop app working too.

The Agent SDK / your own apps

Same idea, in code. Point the Bedrock client at an EU region and call an eu. model ID:

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="eu-north-1")

msg = client.messages.create(
    model="eu.anthropic.claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hei!"}],
)

Lock it down so nobody can route data out

Setting EU model IDs is the happy path; enforcing them is the governance. Scope an IAM policy so the role can only invoke EU inference profiles, and your boundary stops being a convention and starts being a control:

{
  "Effect": "Allow",
  "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
  "Resource": "arn:aws:bedrock:eu-*:*:inference-profile/eu.anthropic.*"
}

Add Bedrock Guardrails for content filtering, and confirm the whole thing in CloudTrail: every InvokeModel call is logged with the region and the IAM principal, which is exactly the evidence an auditor asks for. Two honest gotchas worth knowing up front: the WebSearch tool isn't available on Bedrock, and Claude Code sends some experimental beta headers that Bedrock rejects, so set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 if you hit that error.

The right answer is usually both: matched to the workload

This isn't a contest where one product wins. The skill is governing the boundary on purpose. Map your Claude use cases by sensitivity, then route each one to the side it belongs on.

Patient records, customer PII, financial data, source code under NDA: those run on Bedrock in an EU region, in-region where the rule is strict, EU Geo where it's geographic. Lower-sensitivity work (a developer prototyping against synthetic data, internal tooling with no personal data) can use Claude Platform on AWS if your risk owners sign off. Same AWS account, same CloudTrail, two deliberate lanes.

And because both paths authenticate through IAM and log to CloudTrail, your security team monitors AI usage the same way they monitor everything else. No new dashboard, no shadow tooling. The control plane you already trust now covers Claude too, as long as someone sets the boundary on purpose rather than by default.

Setting that boundary deliberately, rather than inheriting it by default, is a conversation we have with clients every week.