在 Amazon Bedrock 上通过单一 Region Claude Code 强制实施数据驻留

一家总部位于美国的全球组织最近向我们提出了一项看似简单的数据驻留需求：让其工程师使用 Claude Code。其要求是：Amazon Bedrock 模型推理必须在伦敦（AWS Region eu-west-2）处理，而不仅仅是从伦敦发起调用。该组织的合规团队划出了一条不可逾越的红线：提示词、补全内容和中间处理过程必须全部留在单一 AWS Region 内。近似合规不在考虑范围之内。

我们首先尝试了最新路径（Amazon Bedrock 上 Anthropic 的 Mantle 端点），但遇到了一个限制。随后，我们回到了经典的 Amazon Bedrock Invoke API，并使用应用推理配置文件。该组合加上 AWS Identity and Access Management (IAM) 的区域条件，满足了这一要求。

本文将介绍这两条路径、为何选择取决于你的区域、用于强制执行的 AWS Identity and Access Management (IAM) 策略，以及如何在 AWS CloudTrail 中验证合规性。该模式适用于以 Amazon Bedrock 模型 ID 为目标的工具。

**重要背景：**对于大多数 Amazon Bedrock 工作负载，跨区域推理（CRIS）是正确的默认选择。它可以平滑吞吐量、增加应用可用容量，并让你更早使用较新的模型。仅当你的合规要求指定的是某个特定 AWS Region，而非一个地理范围时，才应使用本文的单一区域模式。如果“位于欧盟境内的某处”即可满足数据驻留需求，那么欧盟跨区域配置文件是更直接的答案。

前提条件

开始前，请确认你具备以下条件：

• 一个 AWS 账户，并已为计划使用的 Claude 模型启用 Amazon Bedrock 模型访问权限。
• Claude Code 所使用身份的 IAM 权限；不同路径所需权限不同：
  • 路径 1（Mantle）：bedrock-mantle:CreateInference、bedrock-mantle:Get* 和 bedrock-mantle:List*。
  • 路径 2（经典 Amazon Bedrock）：bedrock:CreateInferenceProfile、bedrock:InvokeModel 和 bedrock:InvokeModelWithResponseStream。
  • 两条路径均需：iam:CreatePolicy、iam:AttachRolePolicy 和 iam:PutRolePolicy，以便将区域范围策略附加至该角色或用户。
• Claude Code v2.1.94 或更高版本（路径 1 要求支持 Mantle，该支持于 v2.1.94 中加入）。
• 已安装并配置 AWS Command Line Interface（AWS CLI），且已为目标区域配置凭证。

两个端点，两条路径

Amazon Bedrock 通过两个不同端点提供 Claude 模型。你使用的端点决定如何强制实施数据驻留，也决定你可在哪些区域中实施。

**经典 Amazon Bedrock（bedrock-runtime）**是最初的 Amazon Bedrock Invoke API。当你设置 CLAUDE_CODE_USE_BEDROCK=1 时，Claude Code 会使用它。单一区域路由需要推理配置文件。默认情况下，系统定义的推理配置文件是跨区域的。若要将请求保留在单一区域中，你需要创建一个指向该区域内基础模型的应用推理配置文件。

**Mantle（bedrock-mantle）**是一个较新的 Amazon Bedrock 端点，通过 Anthropic 原生 API 形式提供 Claude。当你设置 CLAUDE_CODE_USE_MANTLE=1 时，Claude Code 会使用它。单一区域路由是原生支持的：设置 AWS_REGION 后，Mantle 会将端点直接解析到该区域，无需应用推理配置文件。

图 1：Claude Code 的两条单一区域路径

不过，每个端点都有各自的区域可用性和模型阵容：

| 经典 Amazon Bedrock | Mantle
---|---|---
支持区域内 Claude 的区域 | 仅 eu-west-2（伦敦）（适用于 Claude Opus 4.6、Sonnet 4.6） | 爱尔兰、斯德哥尔摩、东京、墨尔本、美国东部（弗吉尼亚北部）、美国东部（俄亥俄州）、美国西部（俄勒冈州）
模型 ID | anthropic.claude-opus-4-6-v1、anthropic.claude-sonnet-4-6 | anthropic.claude-sonnet-5、anthropic.claude-opus-4-8、anthropic.claude-haiku-4-5
单一区域机制 | 应用推理配置文件 + IAM 条件 | AWS_REGION + IAM 条件

Claude Code 可在同一会话中运行两个端点（同时设置两个环境变量）。以 anthropic. 开头且没有 us. 前缀的模型 ID 会路由到 Mantle，其他所有内容则路由到经典 Invoke。

目标区域决定你的选择。目标是伦敦（eu-west-2）？使用路径 2。Mantle 在该区域不提供区域内路由，而经典 Amazon Bedrock 支持对 Claude Opus 4.6 和 Sonnet 4.6 进行区域内推理。目标是爱尔兰、斯德哥尔摩、东京、墨尔本、美国东部（弗吉尼亚北部）、美国东部（俄亥俄州）或美国西部（俄勒冈州）之一？使用路径 1。Mantle 的原生路由可在这些区域中工作，以更少的设置让你使用较新的模型。目标是其他区域？目前两种模式都不可用。请升级至 AWS 客户经理团队处理。

有关各区域的模型可用性，请参阅 Amazon Bedrock 中的 按 AWS Region 列出的支持模型。

路径 1：在支持的单一区域中使用 Mantle

如果你的合规要求指定 Mantle 支持区域内推理的七个区域之一（爱尔兰、斯德哥尔摩、东京、墨尔本、美国东部（弗吉尼亚北部）、美国东部（俄亥俄州）或美国西部（俄勒冈州）），Mantle 是更直接的路径。你无需创建任何推理配置文件，就能获得直接的单一区域路由，并可访问包括 Claude Sonnet 5 在内的较新模型。

配置 Claude Code 使用 Mantle，并将其固定到目标区域：

# 通过 Mantle 端点路由 Claude Code

# 爱尔兰，一个支持区域内推理的 Mantle 区域
export CLAUDE_CODE_USE_MANTLE=1
export AWS_REGION=eu-west-1
# 将模型系列别名固定到 Mantle 模型 ID
export ANTHROPIC_DEFAULT_OPUS_MODEL='anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='anthropic.claude-sonnet-5'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='anthropic.claude-haiku-4-5'

运行 claude 命令并验证 /status 输出。提供商应显示为 Amazon Bedrock (Mantle)，且区域应与设置一致。Mantle 在 Claude Code v2.1.94 及更高版本中可用。

设置概览：三个环境变量，除 IAM 策略外无需额外预置 AWS 资源。

Claude Code 没有自己的凭证。相反，它会使用开发者环境中已有的 AWS 凭证对 Amazon Bedrock 调用进行签名。请将以下策略附加到该 IAM 主体：开发者所承担的角色（例如通过 AWS IAM Identity Center）或其本地配置文件背后的 IAM 用户。该策略仅允许在目标区域中调用 Amazon Bedrock：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowClaudeCodeMantleInIrelandOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock-mantle:CreateInference",
        "bedrock-mantle:Get*",
        "bedrock-mantle:List*"
      ],
      "Resource": "arn:aws:bedrock-mantle:eu-west-1:111122223333:project/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    }
  ]
}

将 111122223333 替换为你的账户 ID。aws:RequestedRegion 条件会拒绝任何不是针对爱尔兰端点发起的 Mantle 调用，因此即便开发者错误配置了 AWS_REGION，IAM 也会拒绝该调用。这正是本文讨论的区域护栏。请注意，Mantle 上的模型固定机制有所不同：资源是项目而不是模型，因此身份策略只能控制区域。模型选择来自 ANTHROPIC_DEFAULT_*_MODEL 变量。若要强制执行经批准的模型列表，请使用服务控制策略。这正是与路径 2 的不对称之处：在路径 2 中，基础模型 Amazon Resource Name（ARN）使一条身份策略能够同时固定区域和模型。

路径 2：针对 Mantle 未覆盖区域的应用推理配置文件

我们客户的合规要求明确指定伦敦，Mantle 的区域可用性表解释了这为何重要。**eu-west-2 在 Mantle 上仅提供 Global 和 EU 端点，没有仅限区域内的选项。**EU 端点会在整个欧盟地理范围内路由，因此从伦敦发出的请求可能会在法兰克福、爱尔兰或巴黎处理。这恰恰是客户需要避免的情况。

经典 Amazon Bedrock 是伦敦的唯一选择。此外还存在一个限制：经典 Amazon Bedrock 中的区域内可用性范围很窄。

根据 Claude Opus 4.6 和 Claude Sonnet 4.6 模型卡，eu-west-2 目前是这些模型唯一提供区域内推理的区域。Opus 4.7 和 4.8 则不提供此能力；它们在经典 Amazon Bedrock 上仅支持地理区域级别的推理。因此，伦敦部署以 Claude Opus 4.6 和 Sonnet 4.6 为基础。

某些基础模型无法通过其模型 ID 直接调用，因为 Amazon Bedrock 要求你通过推理配置文件调用它们。因此，当你将 Claude Code 直接指向其中某个模型 ID 时，调用会失败。Amazon Bedrock 返回的错误会指出不支持按需吞吐量，并要求你使用推理配置文件的 ID 或 ARN 重试。但系统定义的推理配置文件是跨区域配置文件（带有 eu. 和 global. 前缀），而这正是我们试图避免的。

解决方案是使用应用推理配置文件。这是一个由你创建的配置文件，以某个区域中基础模型 ARN 作为模型源。将它指向伦敦的基础模型 ARN，你将获得一个 Claude Code 可接受的配置文件形式 ARN，并且该 ARN 会解析为单一区域模型。

为每个模型系列创建一个配置文件：

aws bedrock create-inference-profile \
  --region eu-west-2 \
  --inference-profile-name "claude-code-opus-london" \
  --model-source copyFrom="arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-opus-4-6-v1"
aws bedrock create-inference-profile \
  --region eu-west-2 \
  --inference-profile-name "claude-code-sonnet-london" \
  --model-source copyFrom="arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-sonnet-4-6"

每次调用都会返回类似 arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<id> 的 inferenceProfileArn。请保存这两个 ARN，Claude Code 将把它们作为模型使用。应用推理配置文件还可在你的 AWS 账单中提供按配置文件划分的成本和使用量追踪。

将 Claude Code 连接至配置文件 ARN：

# 通过伦敦的经典 Bedrock 路由 Claude Code
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-2
# 将模型别名映射到伦敦应用推理配置文件
export ANTHROPIC_DEFAULT_OPUS_MODEL='arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<opus-id>'
export ANTHROPIC_DEFAULT_SONNET_MODEL='arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<sonnet-id>'

对于团队推广，请在托管的设置文件中配置这些值，而不是由每位工程师分别在 Shell 中设置，从而确保配置一致且受集中控制。

设置概览：创建 2 个应用推理配置文件（每个模型系列一个）、4 个环境变量（CLAUDE_CODE_USE_BEDROCK、AWS_REGION 以及两个 ANTHROPIC_DEFAULT_*_MODEL 变量），再加上 IAM 策略。与路径 1 相比，每个模型系列大约需要额外 5 分钟的预置工作。

IAM 策略与路径 1 类似，但现在 Resource 列表包含应用推理配置文件 ARN、其底层基础模型 ARN，以及 Amazon Bedrock 的 IAM 操作：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowClaudeCodeInLondonOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:GetInferenceProfile",
        "bedrock:ListInferenceProfiles"
      ],
      "Resource": [
        "arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<opus-id>",
        "arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<sonnet-id>",
        "arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-opus-4-6-v1",
        "arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-sonnet-4-6"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-2"
        }
      }
    }
  ]
}

进行端到端验证。在 Claude Code 中运行 /status，并确认提供商显示为 Amazon Bedrock，区域为伦敦。

验证单一区域合规性

每一次 Claude Code 的 Amazon Bedrock 调用，都必须出现在目标区域的 AWS CloudTrail 中，且不得出现在其他任何区域。查询方式取决于你部署的是哪条路径，因为这两个端点会以不同事件名称、不同事件源和不同 CloudTrail 事件类型记录日志。

**路径 2（经典 Amazon Bedrock）：**模型调用会在 bedrock.amazonaws.com 事件源下记录为 InvokeModel。可在事件历史记录中查询：

aws cloudtrail lookup-events \
  --region eu-west-2 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel

一次合规的

A US-headquartered global organization recently came to us with a deceptively simple data-residency request: let their engineers use Claude Code. The requirement: Amazon Bedrock model inference had to be processed in London (the eu-west-2 AWS Region), not merely called from London. Their compliance team had drawn a hard line. Prompts, completions, and intermediate processing were required to stay inside a single AWS Region. Approximate compliance wasn’t on the table.

We tried the newest path first (Anthropic’s Mantle endpoint on Amazon Bedrock) and encountered a limitation. Then we went back to the classic Amazon Bedrock Invoke API with an application inference profile. That combination, plus an AWS Identity and Access Management (IAM) Region condition, satisfied the requirement.

In this post, we show you both paths, why the choice depends on your Region, the AWS Identity and Access Management (IAM) policy that enforces them, and how to verify compliance in AWS CloudTrail. The pattern applies to tools that target an Amazon Bedrock model ID.

Important context: for most Amazon Bedrock workloads, cross-Region inference (CRIS) is the right default. It smooths throughput, increases the capacity available to your application, and gives you access to newer models first. Use the single-Region patterns in this post only when your compliance requirement is a specific AWS Region rather than a geography. If “somewhere in the EU” satisfies your data residency need, an EU cross-Region profile is the more straightforward answer.

Prerequisites

Before you begin, confirm that you have:

• An AWS account with Amazon Bedrock model access enabled for the Claude models that you intend to use.
• IAM permissions for the identity Claude Code runs as, which differ by path:
  • Path 1 (Mantle): bedrock-mantle:CreateInference, bedrock-mantle:Get*, and bedrock-mantle:List*.
  • Path 2 (classic Amazon Bedrock): bedrock:CreateInferenceProfile, bedrock:InvokeModel, and bedrock:InvokeModelWithResponseStream.
  • Both paths: iam:CreatePolicy, iam:AttachRolePolicy, and iam:PutRolePolicy to attach the Region-scoped policy to that role or user.
• Claude Code v2.1.94 or later (Path 1 requires Mantle support, which was added in v2.1.94).
• AWS Command Line Interface (AWS CLI) installed and configured with credentials for the target Region.

Two endpoints, two paths

Amazon Bedrock exposes Claude models through two distinct endpoints. The one that you use determines how you enforce data residency. It also determines which Regions you can enforce it in.

Classic Amazon Bedrock (bedrock-runtime) is the original Amazon Bedrock Invoke API. Claude Code uses it when you set CLAUDE_CODE_USE_BEDROCK=1. Single-Region routing requires an inference profile. By default, the system-defined inference profiles are cross-Region. To keep a request in one Region, you create an application inference profile that points at the in-Region foundation model.

Mantle (bedrock-mantle) is a newer Amazon Bedrock endpoint that serves Claude through Anthropic’s native API shape. Claude Code uses it when you set CLAUDE_CODE_USE_MANTLE=1. Single-Region routing is native. You set AWS_REGION, and Mantle resolves the endpoint to that Region directly with no application inference profile needed.

Figure 1: Two paths for single-Region Claude Code

However, each endpoint has its own Regional availability and model lineup:

| Classic Amazon Bedrock | Mantle
---|---|---
Regions with in-Region Claude support | eu-west-2 (London) only (for Claude Opus 4.6, Sonnet 4.6) | Ireland, Stockholm, Tokyo, Melbourne, US East (N. Virginia), US East (Ohio), US West (Oregon)
Model IDs | anthropic.claude-opus-4-6-v1, anthropic.claude-sonnet-4-6 | anthropic.claude-sonnet-5, anthropic.claude-opus-4-8, anthropic.claude-haiku-4-5
Single-Region mechanism | Application inference profile + IAM condition | AWS_REGION + IAM condition

Claude Code can run both endpoints in the same session (set both env vars). Model IDs starting with anthropic. and no us. prefix route to Mantle. Everything else goes to classic Invoke.

Your Region drives the choice. Targeting London (eu-west-2)? Use Path 2. Mantle offers no in-Region routing there, and classic Amazon Bedrock supports in-Region inference for Claude Opus 4.6 and Sonnet 4.6. Targeting one of Ireland, Stockholm, Tokyo, Melbourne, US East (N. Virginia), US East (Ohio), or US West (Oregon)? Use Path 1. Mantle’s native routing works there and gives you access to newer models with less setup. Targeting a different Region? Neither pattern works today. Escalate to your AWS account team.

For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock.

Path 1: Mantle for a supported single Region

If your compliance requirement points at one of Mantle’s seven in-Region Regions (Ireland, Stockholm, Tokyo, Melbourne, US East (N. Virginia), US East (Ohio), or US West (Oregon)), Mantle is the more straightforward path. You get direct single-Region routing without creating any inference profiles, and access to newer models including Claude Sonnet 5.

Configure Claude Code to use Mantle and pin it to your target Region:

# Route Claude Code through the Mantle endpoint

# Ireland, an in-Region Mantle Region
export CLAUDE_CODE_USE_MANTLE=1
export AWS_REGION=eu-west-1
# Pin the model family aliases to Mantle model IDs
export ANTHROPIC_DEFAULT_OPUS_MODEL='anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='anthropic.claude-sonnet-5'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='anthropic.claude-haiku-4-5'

Run the claude command and verify the /status output. The provider should read Amazon Bedrock (Mantle) and the Region should match. Mantle is available in Claude Code v2.1.94 and later.

Setup summary: three environment variables, no additional AWS resources to provision beyond the IAM policy.

Claude Code has no credentials of its own. Instead, it signs Amazon Bedrock calls with whatever AWS credentials are already in the developer’s environment. Attach this policy to that IAM principal: the role your developers assume (for example, through AWS IAM Identity Center) or the IAM user behind their local profile. It permits Amazon Bedrock calls only in your target Region:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowClaudeCodeMantleInIrelandOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock-mantle:CreateInference",
        "bedrock-mantle:Get*",
        "bedrock-mantle:List*"
      ],
      "Resource": "arn:aws:bedrock-mantle:eu-west-1:111122223333:project/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    }
  ]
}

Replace 111122223333 with your account ID. The aws:RequestedRegion condition rejects any Mantle call not made against the Ireland endpoint, so even if a developer misconfigures AWS_REGION, IAM refuses the call. That is the Region guardrail this post is about. Note that model pinning works differently on Mantle: the resource is a project, not a model, so the identity policy controls only Region. Your model choice comes from the ANTHROPIC_DEFAULT_*_MODEL variables. To enforce an approved model list, use a service control policy. That is the asymmetry with Path 2, where the foundation-model Amazon Resource Name (ARN) lets one identity policy pin both Region and models.

Path 2: Application inference profile for Regions Mantle doesn’t cover

Our customer’s compliance requirement was London specifically, and Mantle’s Regional availability table shows why that matters. eu-west-2 offers only Global and EU endpoints on Mantle, with no in-Region-only option. The EU endpoint routes across the whole EU geography, so a request from London can be processed in Frankfurt, Ireland, or Paris. That is exactly what the customer needed to prevent.

Classic Amazon Bedrock is the only option for London. Additionally, there is a constraint: in-Region availability on classic Amazon Bedrock is narrow.

Per the Claude Opus 4.6 and Claude Sonnet 4.6 model cards, eu-west-2 is currently the only Region where these models offer in-Region inference. Opus 4.7 and 4.8 don’t. They are Geo-only on classic Amazon Bedrock. So, the London deployment is anchored on Claude Opus 4.6 and Sonnet 4.6.

Some foundation models can’t be called directly by their model ID because Amazon Bedrock requires you to invoke them through an inference profile instead. So, when you point Claude Code straight at one of these model IDs, the call fails. Amazon Bedrock returns an error saying on-demand throughput isn’t supported and asks you to retry with the ID or ARN of an inference profile. But the system-defined inference profiles are the cross-Region ones (eu. and global. prefixes), which is exactly what we are trying to avoid.

The solution is an application inference profile. This is a profile you create with a foundation-model ARN in one Region as its model source. Point it at the London foundation model ARN and you get a profile-shaped ARN that Claude Code accepts and that resolves to a single-Region model.

Create one profile per model family:

aws bedrock create-inference-profile \
  --region eu-west-2 \
  --inference-profile-name "claude-code-opus-london" \
  --model-source copyFrom="arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-opus-4-6-v1"
aws bedrock create-inference-profile \
  --region eu-west-2 \
  --inference-profile-name "claude-code-sonnet-london" \
  --model-source copyFrom="arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-sonnet-4-6"

Each call returns an inferenceProfileArn like arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<id>. Save both. Claude Code uses them as models. Application inference profiles also give you per-profile cost and usage tracking in your AWS bill.

Wire Claude Code to the profile ARNs:

# Route Claude Code through classic Bedrock in London
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-2
# Map the model aliases to the London application inference profiles
export ANTHROPIC_DEFAULT_OPUS_MODEL='arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<opus-id>'
export ANTHROPIC_DEFAULT_SONNET_MODEL='arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<sonnet-id>'

For a team rollout, set these in a managed settings file rather than each engineer’s shell, so the configuration is consistent and centrally controlled.

Setup summary: 2 application inference profile creations (one per model family), four environment variables (CLAUDE_CODE_USE_BEDROCK, AWS_REGION, and the two ANTHROPIC_DEFAULT_*_MODEL variables), plus the IAM policy. Roughly 5 minutes of additional provisioning per model family versus Path 1.

The IAM policy looks similar to Path 1, but the Resource list now includes the application inference profile ARNs, their backing foundation-model ARNs, and the IAM actions for Amazon Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowClaudeCodeInLondonOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:GetInferenceProfile",
        "bedrock:ListInferenceProfiles"
      ],
      "Resource": [
        "arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<opus-id>",
        "arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<sonnet-id>",
        "arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-opus-4-6-v1",
        "arn:aws:bedrock:eu-west-2::foundation-model/anthropic.claude-sonnet-4-6"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-2"
        }
      }
    }
  ]
}

Verify end to end. Run /status in Claude Code and confirm the provider reads Amazon Bedrock and the Region is London.

Verifying single-Region compliance

Every Claude Code Amazon Bedrock call must appear in the target Region’s AWS CloudTrail, and nowhere else. How you query for it depends on which path you deployed, because the two endpoints log under different event names, different event sources, and different CloudTrail event types.

Path 2 (classic Amazon Bedrock): Model invocations log as InvokeModel under the bedrock.amazonaws.com event source. Look them up in the event history:

aws cloudtrail lookup-events \
  --region eu-west-2 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel

A compliant event contains three fields that matter:

{
  "eventName": "InvokeModel",
  "eventSource": "bedrock.amazonaws.com",
  "awsRegion": "eu-west-2",
  "requestParameters": {
    "modelId": "arn:aws:bedrock:eu-west-2:111122223333:application-inference-profile/opus-london"
  }
}

If no InvokeModel events appear, model-invocation logging might be off. Enable Amazon Bedrock data events on your trail and retry.

Path 1 (Mantle): Mantle logs inference as CreateInference under the bedrock-mantle.amazonaws.com event source, and it is a CloudTrail data event. Before you can verify anything, enable bedrock-mantle data events with an advanced event selector on a trail or event data store. Once logging is on, query the event data store in AWS CloudTrail Lake:

SELECT eventName, awsRegion, element_at(requestParameters, 'model') AS model
FROM <event-data-store-id>
WHERE eventSource = 'bedrock-mantle.amazonaws.com'
AND eventName = 'CreateInference'

A compliant Mantle event carries the target Region in awsRegion and the pinned model in requestParameters.model:

{
  "eventName": "CreateInference",
  "eventSource": "bedrock-mantle.amazonaws.com",
  "awsRegion": "eu-west-1",
  "requestParameters": {
    "model": "anthropic.claude-sonnet-5"
  }
}

Regardless of path, three checks prove compliance. First, every event’s awsRegion must match your target Region. Second, rerunning the same query in every other Region should return zero results. Third, any errorCode: AccessDenied event should trace back to a deliberate test rather than a real client.

Choosing the right path

Compare the two paths:

| Path 1 (Mantle) | Path 2 (Classic Amazon Bedrock)
---|---|---
Regions with in-Region Claude support | 7 | 1 (London only)
Models with in-Region support | Sonnet 5, Opus 4.8, Haiku 4.5 | Opus 4.6, Sonnet 4.6
AWS resources to create | 0 | 2 application inference profiles
Environment variables to set | 3 | 4
Setup steps beyond IAM | Env vars only | 2 CLI calls + env vars

Verify the current in-Region status on the Amazon Bedrock model cards before committing. Availability moves as new models land.

Clean up

If you want to remove the application inference profiles you created, delete them with the AWS CLI:

aws bedrock delete-inference-profile \
  --region eu-west-2 \
  --inference-profile-identifier <opus-profile-arn>
aws bedrock delete-inference-profile \
  --region eu-west-2 \
  --inference-profile-identifier <sonnet-profile-arn>

Application inference profiles carry no ongoing charge on their own. Model invocation is the source of cost. Removing unused profiles keeps your account organized and reduces the surface area for accidental invocation. Path 1 requires no cleanup beyond detaching the IAM policy, since it creates no additional AWS resources.

Considerations and next steps

Treat this as a point-in-time snapshot. Regional availability changes as Anthropic and AWS bring new models to more Regions on both endpoints. Before you roll out, confirm the current in-Region status and exact model IDs for your chosen models on their model cards.

Claude Code can run both endpoints in the same session. Set CLAUDE_CODE_USE_BEDROCK=1 and CLAUDE_CODE_USE_MANTLE=1 together, and model IDs matching the Mantle format route to Mantle while everything else routes to classic Invoke. That is useful during a migration or when different model families live on different endpoints.

Single-Region data residency for an agentic coding tool might appear to require custom infrastructure. It does not. Depending on your Region, choose either Mantle’s native single-Region routing or a classic Amazon Bedrock application inference profile. Pair either with an IAM Region condition for a clean, auditable deployment of Claude Code.

To get started, open the Amazon Bedrock console, check the Regional availability tables for the models you need on both endpoints, and pick the path that fits your Region. Learn more about inference profiles, cross-Region inference, and Claude Code on Amazon Bedrock in their respective documentation.

Related content

---

About the author