AWS Bedrock in Frankfurt: the clearest answer to the residency question

Most “EU data residency” claims describe where data sits at rest. The question that decides whether a transfer happened under GDPR is where the model actually runs, and that is the question AWS Bedrock in eu-central-1 answers cleanly.

This review is about that specific property, because it is the reason to choose Bedrock over a simpler API, and because everything else about it is a trade you should make knowingly.

What it is

Bedrock is AWS’s managed service for calling foundation models. You do not deploy anything; you call an API and get a model response, billed per token, inside your existing AWS account.

The part that matters here is regional. Create a Bedrock application in Frankfurt and the request is processed in Frankfurt. Processing is restricted to EU regions (Frankfurt, Ireland, Paris, Stockholm, Milan and Spain) and for the current Claude models an EU Geo option spans Frankfurt, Paris and Stockholm.

For a European company with a hard requirement on the processing location, that is currently the best-documented commitment available for these models.

Why the distinction is the whole point

Storage residency is a statement about data at rest. Processing residency is a statement about where computation happens. A vendor can hold the first and not the second, and most of them do.

Under Chapter V of the GDPR, sending personal data to a third country for processing is a transfer, whether or not anything is stored there and whether or not it comes back.

A round trip that leaves no trace is still a round trip.

That is why “our data is stored in Frankfurt” is not an answer to “does a transfer occur”, and why so much procurement time gets burned on it. We pulled the two apart in detail in storage residency is not processing residency, and Bedrock is the cleanest practical resolution of it for teams that need one.

This is a continuity argument as much as a legal one. Transfers to the US are currently lawful under the EU-US Data Privacy Framework, whose adequacy decision is under appeal at the Court of Justice. A stack already processing in the EU is indifferent to how that ends. A stack that depends on the framework is not.

What it costs you

Not money: Bedrock’s per-token pricing is competitive and there is no platform fee. What it costs is setup and friction, and there are four honest items.

An AWS account with someone who knows it. If your company already runs on AWS, this is free. If it does not, you are adopting IAM, regions, quotas and a billing model in order to make one API call. That is a real cost and it is paid by whoever gets paged.

Model availability lags. New models reach the direct provider APIs first and the EU regions of a hyperscaler later. If being on the newest model the week it ships matters to you, this is the wrong path. For a production agent, it rarely does, but decide it deliberately.

Quotas. Bedrock applies per-region throughput limits that are lower than most people expect on a new account. This is the item that surprises teams in week two, not week one, and it is worth requesting an increase before load rather than during it.

One more abstraction layer. You are calling a model through AWS rather than directly, which means one more place for a permission, a version or a regional difference to be wrong.

The verification list

Ask for the region per endpoint, not per account. Residency is configured per deployment. An application calling several services can be in-region on some and not on others without anyone noticing.

Check the side paths. Moderation, logging and telemetry are where in-region deployments most commonly leak. The model can run in Frankfurt while something adjacent does not.

Keep retention as a separate question. Residency and retention are independent promises, and so is training exclusion. All three get conflated, and holding one implies nothing about the others.

Write it into the DPA. A configuration can be changed by whoever holds the console. A contract cannot. Under Article 28 GDPR the sub-processors have to be named anyway; put the region next to each name.

Where we would not use it

When residency is not actually required. A lot of teams adopt a hyperscaler path reflexively, pay the complexity, and process data that carries no Chapter V obligation at all. Anonymised aggregates and public information do not need this.

For a prototype. The direct provider APIs are faster to start with and easier to reason about. Move to Bedrock when the residency question becomes real, which is usually at the first serious security review, and design behind your own thin interface so that move is a configuration change rather than a project.

When the constraint is German-jurisdiction hosting specifically. AWS is a US company operating EU regions. For most requirements that is fine and the contractual position is well documented. For requirements written specifically about the operator’s jurisdiction rather than the data’s location, it is not, and that distinction is worth its own conversationDE (auf Deutsch).

What we would actually use it for

Production agents that handle customer data for European clients, in companies already on AWS. In that setting it is the shortest path from “we need a defensible answer about where processing happens” to having one, and the answer survives an audit without a paragraph of explanation.

For everything else (internal tools, non-personal data, early experiments) the simpler path is better, and switching later is cheap if the model sits behind your own interface from the start.

Frequently asked questions