Cursor can send Claude requests to your own Amazon Bedrock account in an EU Region. That part works. But if your goal is “our code never leaves the EU”, Cursor with Amazon Bedrock doesn’t get you all the way there, and it’s better to know that before your security review than during it.
The reason is simple: every request still passes through Cursor’s own servers first, and some features never use Bedrock at all. In this post I’ll explain what Bedrock does and doesn’t change in Cursor, how to set it up for the EU, and what to tell your DPO.
What Bedrock changes in Cursor, and what it doesn’t
Cursor’s Bedrock integration moves the model call into your AWS account. It doesn’t move the rest of Cursor there.
| Part of the request | With Bedrock enabled | Source |
|---|---|---|
| Model inference for Bedrock model IDs | Runs in your Bedrock account, in the Region you configured | Cursor: Amazon Bedrock |
| Prompt building and context assembly | Still on Cursor’s servers: all requests are routed through Cursor’s backend | Cursor: API keys |
| Tab completion | Always uses Cursor’s built-in models | Cursor: API keys |
| “Auto” and standard model names | Routed through Cursor’s own model providers, not Bedrock | Cursor: Amazon Bedrock |
| Cursor’s Zero Data Retention policy | Doesn’t apply; AWS’s data handling applies to the Bedrock call instead | Cursor: API keys |
The second row is the important one. Your code and prompts go to Cursor’s servers, where the final prompt is built, before the call reaches Bedrock. So the EU residency control covers the model call, not the full path.
Cursor does have its own data residency programme for enterprise customers. Today it offers US-only data residency, and EU plus Iceland coverage for inference only, on request. Cursor says broader EU support is in development (Cursor: Privacy and data governance). If you need more than inference to stay in the EU, that conversation is with your Cursor account executive, not with AWS.
Setting it up for the EU
If EU inference is enough for your requirement, or it’s a step on the way, here’s how I’d set it up. Cursor recommends an IAM role over access keys, and so do I (Cursor: AWS Bedrock).
-
Use a dedicated AWS account for Cursor. It keeps billing and Bedrock quotas separate from your other workloads.
-
Create an IAM role that Cursor can assume. The trust policy names Cursor’s cross-account role and the External ID shown in your Cursor dashboard (Cursor: AWS Bedrock):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::289469326074:role/roleAssumer" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "<your-external-id>" } } } ] }
-
Only let that role call EU profiles. Attach a permissions policy that allows your approved
eu.inference profiles and the matching models, and nothing else. The pattern is in How to Enforce EU-Only Claude Routing with IAM and SCPs. -
Configure the team connection in the Cursor dashboard with an EU Region, such as Frankfurt. With a non-US Region, Bedrock models appear in Cursor with the
eu.prefix (Cursor: AWS Bedrock). -
Turn on the Amazon Bedrock toggle for every developer. It’s in Cursor Settings > Models and it’s off by default for each user, even after the team role is validated (Cursor: AWS Bedrock).
-
Tell developers to pick the
eu.model IDs, for exampleeu.anthropic.claude-sonnet-5. If they choose “Auto” or a standard name like “Claude Sonnet 5”, the request goes through Cursor’s own providers instead of your Bedrock account.
Checking it’s working
- In Cursor: Bedrock requests still show up on the dashboard usage page, recorded as bring-your-own-key usage with near-zero model cost, because inference is billed to your AWS account (Cursor: AWS Bedrock). If you see normal model costs, someone isn’t using the Bedrock IDs.
- In AWS: the calls appear in CloudTrail in your source Region, made
by the role Cursor assumes. Check that
requestParameters.modelIdis aneu.profile and thatinferenceRegion, if present, is an EU Region. How to Verify Where Claude Processed Your Request with AWS CloudTrail walks through this. - As a guardrail: an SCP on the Cursor account that denies Global profiles means a misconfigured model choice fails instead of leaving the EU.
What to tell your DPO
Be precise. With this setup, Claude inference for Bedrock model IDs runs in EU Regions under your AWS account. Prompts and code context still pass through Cursor’s servers, Tab completion uses Cursor’s own models, and Cursor’s subprocessors apply to that part of the flow. Cursor publishes its subprocessor list at trust.cursor.com/subprocessors.
If your requirement is that code never leaves the EU at any point, Cursor with Amazon Bedrock doesn’t meet it today. The alternatives are Cursor’s EU data residency programme once it covers what you need, a tool that calls your Bedrock account directly from the developer’s machine such as Claude Code, or Kiro, AWS’s own coding tool, with an enterprise profile in Frankfurt (Using Kiro with Claude in the EU).
Want Cursor set up properly, or a second opinion on the options?
At Wolkn Minds, we set up the Bedrock connection, IAM and SCPs for Cursor, and help you decide whether Cursor, Claude Code or Kiro fits your data requirements. Book a consultation.
