Enforcing data residency with single-Region Claude Code on Amazon Bedrock

**Claude Code** on **Amazon Bedrock** can be locked to a single AWS Region when “in geography” is not enough. A regulated customer required every Claude Code inference to run in **London** only, not elsewhere in the same broader footprint. The **AWS Machine Learning Blog** walks through how to enforce that pin and prove it.

Technically, the post covers two pinning paths: an **application inference profile**, or the **Mantle endpoint**, each used so Claude Code traffic stays on Bedrock in that one Region. Both approaches are paired with an **IAM Region condition** so identity policy blocks calls that leave the allowed Region. Operators then use **AWS CloudTrail** to check that recorded events match the intended single-Region path.

For engineers and builders under residency, sovereignty, or contractual Region limits, the hard part is not model choice alone—it is where inference actually lands. Claude Code traffic that can fan out across Regions breaks controls that assume one processing location. Region-pinned Bedrock plus IAM conditions turn that requirement into enforceable configuration rather than hope and documentation.

In market terms, this sits at the overlap of generative coding tools and regulated cloud use. Many enterprises already buy Bedrock for managed model access and auditability; Claude Code adds agentic coding workloads that still have to inherit the same residency story. Competitors that only offer multi-Region or loosely “in-region” routing leave a gap for customers who need a named Region such as London on every inference.

Practical takeaway: pick either the application inference profile or Mantle endpoint route, attach the IAM Region condition for London (or your mandated Region), then validate in CloudTrail that Claude Code inference events stay in that Region. Watch for misconfigured profiles, missing Region conditions, and any path that still routes outside the pin before you treat the setup as compliant.