版本：1.8.0

AWS Bedrock

Amazon Bedrock 是一项 AWS 服务，可通过托管 API 访问 Amazon 及其他服务提供方的基础模型。AISIX 为应用提供统一的 OpenAI 兼容接口，用于访问由 Bedrock 托管的 Claude、Llama、Mistral、Amazon Nova、Cohere 等模型。

此配置适用于需要使用 AISIX 身份验证、模型允许列表、限流和用量核算的 Bedrock 托管模型。AISIX 使用 AWS SigV4 对出站 Bedrock 调用进行签名，或以 Bearer Token 发送 Bedrock API Key，参见选择凭证模式。

准备工作

开始前，请准备以下内容：

一套 AISIX 环境：
- 对于 AISIX Enterprise 或 AISIX Cloud，需要一个已关联网关的环境和具有写入作用域的 Admin Token。使用 AISIX Enterprise 时，请按照 AISIX Enterprise 快速入门操作。如需申请 AISIX Cloud 访问权限，请联系 API7。
- 对于开源 AISIX 网关，请准备本地 AISIX 安装，或使用开源 AISIX 网关快速入门中的 Docker 环境。配置网关以加载声明式资源文件。
对目标模型具有 bedrock:InvokeModel 权限的 AWS 凭证：Access Key ID 和 Secret Access Key（使用临时凭证时另加 STS Session Token），或其他凭证模式之一。
对于跨区域推理，需要对推理配置文件 ARN、源区域以及每个目标区域中的基础模型 ARN 拥有 bedrock:InvokeModel 权限。具体要求参见 AWS 的地理区域和全球推理配置文件说明。
对所选区域中目标 Bedrock 模型的访问权限，以及该模型的模型 ID 或推理配置文件 ID。
curl 和 jq。

使用 AISIX Enterprise 或 AISIX Cloud 配置

导出控制面连接信息：

# AISIX_CP 是 Admin API 基础 URL；应包含 /api，且不含尾部斜杠
# 本地 AISIX Enterprise 快速入门使用 http://localhost:8080/api
export AISIX_CP="YOUR_AISIX_CONTROL_PLANE_API_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

使用 Bedrock 目录服务提供方和结构化 config 凭证创建服务提供方密钥：

PROVIDER_KEY_ID=$(curl -sS -X POST "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "bedrock-prod",
    "provider": "amazon-bedrock",
    "config": {
      "access_key_id": "YOUR_AWS_ACCESS_KEY_ID",
      "secret_access_key": "YOUR_AWS_SECRET_ACCESS_KEY",
      "region": "us-west-2"
    },
    "allowed_environments": ["'"$ENV_ID"'"]
  }' | jq -r '.provider_key.id')

凭证放在 config 中，因此请求省略 api_key。使用临时 STS 凭证时，在 config 中添加 session_token。如需以其他方式认证，在 config 中添加 auth_type，参见选择凭证模式。

api_base 是可选的。未设置时，控制面会保存凭证中 region 对应的运行时端点（本例为 https://bedrock-runtime.us-west-2.amazonaws.com，中国区域为 .amazonaws.com.cn），并像显式设置的值一样返回。使用私有 Bedrock 端点时请设置 api_base。region 不是合法的 AWS 区域名称，或属于隔离分区时，必须显式设置 api_base。之后将凭证替换为另一个区域的凭证时，由控制面推导出的端点会随之切换到新区域。

在控制台中，服务提供方密钥表单的认证方式字段用于选择凭证模式，并显示该模式需要的字段。

为 Claude Sonnet 5 创建别名。该模型不支持在 us-west-2 区域内推理，因此示例使用其美国地理区域推理配置文件：

MODEL_ID=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/models" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "claude-bedrock",
    "model_name": "us.anthropic.claude-sonnet-5",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }' | jq -r '.model.id')

创建可访问该模型的调用方 API Key：

BEDROCK_CALLER_KEY=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/api_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "bedrock-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

使用开源 AISIX 网关配置

导出 AWS 凭证，并选择应用将发送给 AISIX 的调用方 API Key：

# 请替换为实际值
export BEDROCK_CREDENTIALS='{"access_key_id":"YOUR_AWS_ACCESS_KEY_ID","secret_access_key":"YOUR_AWS_SECRET_ACCESS_KEY","region":"us-west-2"}'
export BEDROCK_CALLER_KEY="YOUR_CALLER_API_KEY"

对于新网关，请使用此完整资源文件。对于现有网关，请将这些条目合并到其当前文件中，并保留其他资源。

resources.yaml
_format_version: "1"

provider_keys:
  - display_name: bedrock-prod
    provider: amazon-bedrock
    adapter: bedrock
    api_key: ${BEDROCK_CREDENTIALS}

models:
  - display_name: claude-bedrock
    provider: amazon-bedrock
    model_name: us.anthropic.claude-sonnet-5
    provider_key: bedrock-prod

api_keys:
  - display_name: bedrock-caller
    key_env: BEDROCK_CALLER_KEY
    allowed_models: ["claude-bedrock"]

❶ provider 用于标记上游。

❷ adapter 选择 Bedrock。

❸ api_key 是包含 access_key_id、secret_access_key 和 region 的 JSON 字符串。其他凭证模式使用同样的 JSON 字符串，只是字段不同。Bedrock 端点按区域确定，例如 bedrock-runtime.us-west-2.amazonaws.com，因此区域为必填项。对于标准 AWS，应不设置 api_base；如果使用私有 Bedrock 端点，则将其设置为该端点。

❹ model_name 是 Bedrock 模型 ID 或完整的推理配置文件 ID。示例中的 us. 配置文件可从 us-west-2 使用，并将推理限制在美国和加拿大境内。

❺ provider_key 通过服务提供方密钥的 display_name 将模型关联到凭证。模型的 provider 使用与服务提供方密钥相同的上游标签。

要在示例文件中使用 Meta Llama，请替换 claude-bedrock 模型条目，并更新 bedrock-caller 以允许新别名。保留 bedrock-prod 和其他资源不变：

resources.yaml（Meta Llama 模型访问）
models:
  - display_name: llama-bedrock
    provider: amazon-bedrock
    model_name: us.meta.llama3-3-70b-instruct-v1:0
    provider_key: bedrock-prod

api_keys:
  - display_name: bedrock-caller
    key_env: BEDROCK_CALLER_KEY
    allowed_models: ["llama-bedrock"]

对于 Amazon Nova，请使用 Bedrock 模型或推理配置文件 ID，例如从 us-west-2 使用的 Nova 2 Lite 配置文件 us.amazon.nova-2-lite-v1:0。与 Claude 和 Llama 示例一样，us. 前缀选择美国地理区域推理配置文件。网关会从 BEDROCK_CALLER_KEY 读取明文调用方 Key，并且只存储其哈希。

下面的验证使用 claude-bedrock。如果应用了 Meta Llama 配置块，请改为发送 llama-bedrock，并预期响应中出现该别名。

使用临时 STS 凭证时，请在凭证 JSON 中包含 session_token；使用长期静态密钥时则省略该字段。服务提供方密钥 Secret 遵循服务提供方密钥中说明的凭证处理方式。

验证并加载配置

如果 AISIX 安装在本地，请在加载前验证完整文件：

aisix validate --resources resources.yaml

验证后，在网关进程环境中提供文件引用的环境变量，再启动网关。仅当这些变量已经可供进程使用时，才重新加载现有网关；否则，请使用更新后的环境重启网关。

如果使用 Docker，请调整开源 AISIX 网关快速入门中的验证和启动命令。挂载此 resources.yaml 文件，并在两条命令中使用 -e 传入它引用的每个环境变量。

选择凭证模式

Bedrock 凭证是一个 JSON 对象：在 AISIX Cloud Admin API 中是 config，在资源文件中是 api_key 里的 JSON 字符串。其中 auth_type 决定 AISIX 如何向 Bedrock 认证，region 在所有模式下都必填：

`auth_type`	字段	认证方式
`access_key`（省略时的默认值）	`access_key_id` 和 `secret_access_key`，使用临时凭证时另加 `session_token`	使用这组密钥进行 SigV4 签名。
`api_key`	`api_key`，即 Bedrock API Key	以 `Authorization: Bearer` 发送，不做 SigV4 签名。
`default_chain`	不带凭证字段	使用网关自身的 AWS 凭证进行 SigV4 签名：环境变量、Web Identity（例如 EKS 上的 IRSA）、ECS 容器凭证端点或 EC2 实例配置文件。

在 access_key 或 default_chain 模式下，设置 role_arn 后，AISIX 会通过 sts:AssumeRole 用这组凭证换取该角色的凭证。external_id 和 role_session_name 可选，且都要求同时设置 role_arn。未设置 role_session_name 时，会话名为 aisix-session-<unix seconds>。如果基础凭证本身已经属于该角色，AISIX 会直接使用，而不会让角色扮演自身。例如，使用网关自身的凭证扮演角色：

带 AssumeRole 的 Bedrock 凭证
{
  "auth_type": "default_chain",
  "role_arn": "arn:aws:iam::123456789012:role/bedrock-invoke",
  "external_id": "YOUR_EXTERNAL_ID",
  "region": "us-west-2"
}

属于其他模式的字段会被拒绝：Admin API 拒绝保存并返回 400；在资源文件中，网关会让经过该密钥的每个请求返回 401 authentication_error，错误信息只写字段名，不回显字段值。默认凭证链找不到凭证来源，或 STS 拒绝 AssumeRole，同样是不可重试的 401。凭证服务本身故障（例如 STS 返回 5xx 或元数据端点不可达）属于传输错误，路由可以重试和故障转移。错误信息会写明 auth_type 以及是否涉及角色，但不会包含 STS 返回的原文，具体原因记录在网关日志中。

来自默认凭证链或 AssumeRole 的临时凭证按配置缓存，并在过期前 60 秒刷新。STS 通过标准 AWS SDK 解析方式访问，因此网关环境中的 AWS_ENDPOINT_URL_STS 和 AWS_ENDPOINT_URL 同样生效。所有 Bedrock 调用都遵循所选模式，包括流式、Token 计数和嵌入。

api_key 和 default_chain 模式，以及任意模式下的角色字段，都需要 1.7.0 或更高版本的网关。只要该密钥允许使用的某个环境中注册了更早版本的网关，AISIX Enterprise 和 AISIX Cloud 就会拒绝保存，并返回 422 DP_INCOMPATIBLE，因为旧网关要么让经过该密钥的所有请求失败，要么以基础身份而非该角色签名。

验证服务提供方连接

导出 AISIX 网关 Origin：

# AISIX_PROXY 不含尾部斜杠或端点路径
# 本地快速入门使用 http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_URL"

通过 AISIX 代理发送 Chat Completions 请求：

curl -sS -X POST "$AISIX_PROXY/v1/chat/completions" \
  -H "Authorization: Bearer ${BEDROCK_CALLER_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-bedrock",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from Bedrock."
      }
    ]
  }'

网关会返回 OpenAI 兼容响应，其中包含面向调用方的别名：

{
  "id": "msg_01example",
  "object": "chat.completion",
  "model": "claude-bedrock",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello from Bedrock!"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 9,
    "completion_tokens": 5,
    "total_tokens": 14
  }
}

在 Bedrock 调用指标、CloudTrail 或服务提供方侧日志中检查测试请求。如果 AISIX 返回上游身份验证或授权错误，请检查 AWS 凭证、区域、IAM 权限和 Bedrock 模型访问权限。

推理力度

发送到 /v1/chat/completions 的 reasoning_effort，或发送到 /v1/responses 的 reasoning.effort，到达 Bedrock 上的 Claude 模型时与直接到达 Anthropic 的处理方式相同。Claude Opus 4.5、Claude 4.6 及更新的模型收到 output_config.effort。Claude Haiku 4.5、Claude Sonnet 4.5 及更早的系列会拒绝该字段，因此改为收到扩展思考预算；未设置输出上限的请求会得到足以容纳预算的上限，在 Converse 上写入 inferenceConfig.maxTokens。AISIX 能从模型 ID 的裸 ID、跨区域和推理配置文件 ARN 写法中读出 Claude 名称。各档位的预算参见旧版 Claude 模型的推理力度。

模型返回的推理内容会传给调用方，覆盖所有 Bedrock 模型（无论是否为 Claude），流式和非流式请求都是如此。/v1/chat/completions 以 message.reasoning_content 返回，流式时为 delta.reasoning_content。/v1/responses 以 reasoning 输出项返回。多个推理块之间以换行符连接，这两条路由不会返回 Bedrock 的推理签名和 redacted reasoning。发往 Claude 模型的 /v1/messages 会原样返回 Bedrock 的 thinking 块及其签名和 redacted_thinking 块，参见 Messages API 上的 Claude。发往其他模型的 /v1/messages 以 signature: "" 的 thinking 块返回推理内容，流式时通过 thinking_delta 事件传输，不带 signature_delta。

Messages API 上的 Claude

发往 Bedrock 上 Claude 模型的 /v1/messages 和 /v1/messages/count_tokens 会携带调用方的请求体，直接发到 Bedrock 自己的 Anthropic Messages 操作，不再经过 Chat 格式转换。Claude 模型指 anthropic. 开头的模型 ID（可带区域或推理配置文件前缀），或指向 Claude 模型的 ARN。不包含模型名的应用推理配置文件 ARN 仍走转换路径。/v1/chat/completions 和 /v1/responses 不受影响。

调用方路由	Bedrock 操作
`/v1/messages`	`InvokeModel`，流式请求为 `InvokeModelWithResponseStream`
`/v1/messages/count_tokens`	使用 `invokeModel` 输入的 `CountTokens`，必要时回退到下文所述的 Bedrock Mantle

因此调用方拿到的是 Claude 原生产出的 Bedrock 响应：带签名的 thinking 块、redacted_thinking 块、tool_result 中的图片、原生停止原因、上游消息 ID，以及流式 message_start 事件中完整的用量（含缓存计数）。内容开始之后在流中抛出的 Bedrock 异常会变成 Anthropic error 事件，例如 throttlingException 变为 rate_limit_error，serviceUnavailableException 变为 overloaded_error。在任何内容之前抛出的异常则让本次尝试失败，以便路由进行故障转移。

转发途中，AISIX 只对请求体做以下调整：

移除 model（URL 已指明模型），将 anthropic_version 设为 bedrock-2023-05-31，并移除 stream。
顶层字段只保留 Bedrock 接受的：anthropic_version、anthropic_beta、max_tokens、messages、system、stop_sequences、temperature、top_p、top_k、tools、tool_choice、thinking、metadata、output_config、safeguards 和 context_management。旧版顶层 output_format 会移入 output_config.format，metadata 只保留 user_id。
anthropic-beta 的值写入请求体的 anthropic_beta，并只保留 Bedrock 支持的 beta，详见 Claude 的 beta 值。advanced-tool-use-2025-11-20 以 Bedrock 的名称 tool-search-tool-2025-10-19 发送；在 4.6 之前的 Claude 系列上设置了 output_config.effort 时，AISIX 会添加 effort-2025-11-24。Bedrock 拒绝的值（例如 prompt-caching-scope-2026-01-05、extended-cache-ttl-2025-04-11 和 files-api-2025-04-14）会被丢弃。这份支持列表是在 Claude Sonnet 4.5 上实测得出的，更新的 Claude 模型可能支持更多。
summarized 和 omitted 以外的 thinking.display 会被丢弃，因为 Bedrock 会拒绝它，此时使用模型的默认显示方式。发往 Claude 的 /v1/chat/completions 和 /v1/responses 请求遵循同样的 thinking.display 规则。
context_management.edits 只保留 compact_20260112 和 clear_tool_uses_20250919。
cache_control 标记只保留 type 和 ttl。
以 URL 给出的媒体（包括 tool_result 中的媒体）会被下载后内联发送，参见媒体输入与 URL 获取。
与所有非 Anthropic 官方 API 的上游一样，移除 Anthropic 归属标识行和签名为空的 thinking 块，参见 Anthropic 归属标识行。

发往 4.5 之前 Claude 系列（不支持原生结构化输出）的结构化输出请求（output_format 或 output_config.format）同样留在这些操作上。AISIX 把 schema 移到 Anthropic 请求体中的合成工具 json_tool_call 上，按 AISIX 如何调整 schema 所述密封和收窄，并在请求没有自带 tool_choice、也没有开启 thinking 时强制使用该工具。模型对该工具的调用会以调用方要求的 JSON 文本返回。请求体中的其他内容按原样到达模型。上游调用不使用流式，因此流式调用方会在答复完整后以 SSE 流收到它。

/v1/messages/count_tokens 使用 Bedrock 的 CountTokens 计数，并应用相同的请求体调整，但不发送调用方和服务提供方密钥的 beta。Bedrock 的 CountTokens 无法对部分 Claude 模型计数，例如只能通过跨区域推理使用的模型。对 Claude 模型返回 400 或 404 时，AISIX 改为在 Bedrock Mantle 上计数，地址为 https://bedrock-mantle.<region>.api.aws/anthropic/v1/messages/count_tokens，使用服务提供方密钥的凭证认证。使用 VPC 端点或 GovCloud 时，请在网关启动配置中设置 upstream.bedrock.mantle_endpoint；一个值适用于所有 Bedrock 服务提供方密钥。

Claude 的 beta 值

Bedrock 上的 Claude 从请求体的 anthropic_beta 字段读取 beta，因此无论该值由哪项设置提供，AISIX 都不会向 Bedrock 上的 Claude 模型发送 anthropic-beta 请求头。AISIX 发送的每个 beta 都会在 Bedrock 名称不同时改名，并只保留 Bedrock 支持的 beta；Bedrock 拒绝的值会被丢弃，而不会导致请求失败。

服务提供方密钥的 anthropic-beta 是其请求头设置解析出的值：request.default_headers 中的条目，或 request.forward_client_headers 放行的调用方请求头。两者都提供时，与其他请求头一样，以 default_headers 中的条目为准。写入 anthropic_beta 的 beta 因路由而异：

调用方路由	`anthropic_beta` 中的 beta
`/v1/messages`，流式与非流式	调用方的 `anthropic-beta` 请求头（即使 `forward_client_headers` 没有列出该请求头），与服务提供方密钥的 `anthropic-beta` 以及请求体所用功能需要的 beta 合并。
`/v1/messages/count_tokens`	只有请求体所用功能需要的 beta。
`/v1/chat/completions` 和 `/v1/responses`	服务提供方密钥的 `anthropic-beta`，并入请求体自带的 `anthropic_beta`。在 Converse 上该字段是 `additionalModelRequestFields.anthropic_beta`，其中的单个字符串按一个值处理。不会根据请求体所用功能添加 beta。

这些规则适用于 Messages API 上的 Claude 所述的 Claude 模型 ID。应用推理配置文件（application inference profile）ARN 不包含模型名称，AISIX 无法判断它对应 Claude：服务提供方密钥的 anthropic-beta 会作为未经过滤的请求头发给它，与其他所有 Bedrock 模型相同。

GPT 和 Grok 模型

通过跨区域推理配置文件（例如 global. 或 us.）访问的 Grok 模型（xai.grok-*）或 OpenAI GPT 5.6 及更新版本（openai.gpt-5.6 及以后，不含 gpt-oss），会由 Bedrock 的 OpenAI 兼容 Chat Completions 端点提供服务，即运行时主机或 api_base 上的 /openai/v1/chat/completions。请求保持 OpenAI 格式，使用服务提供方密钥的凭证认证。区域内模型 ID、ARN 和 gpt-oss 仍走 Converse。

需要只有 Converse 才提供的能力时，请求仍会发往 Converse：

包含 guardrailConfig、performanceConfig、serviceTier、requestMetadata、outputConfig、additionalModelRequestFields、additionalModelResponseFieldPaths 或 promptVariables 之一。
json_schema 响应格式缺少 json_schema 对象。
GPT 模型在推理时携带函数工具，即 reasoning_effort 缺省或不为 "none" 时。Grok 在任意推理力度下都通过 Chat Completions 使用工具。

在 Chat Completions 端点上，每个参数都按调用方发送的原样发出，包括 AWS 对该模型拒绝的参数，例如 n 和 stop，Grok 的两个 penalty 和 reasoning_effort: "none"，以及 GPT 推理时的 temperature、top_p、两个 penalty、logprobs 和 top_logprobs。AWS 的错误会带着其状态码和错误信息返回给调用方。developer 消息保留其角色。唯一的改写是输出上限：max_tokens 以 max_completion_tokens 发送，显式的 max_completion_tokens 优先。远程图片 URL 会被下载后内联发送。1.7.0 及更早版本的网关会丢弃 AWS 在该端点拒绝的参数，并把带 thinking、top_k 或 json_object 响应格式的请求改发到 Converse。参见请求参数处理。

Converse 上的停止序列和输出上限

由 Converse 或 ConverseStream 处理的 chat 请求通过类型化字段携带 stop 和 max_completion_tokens，因此 AISIX 会在发送前检查它们，而不是把无效值转发给 Bedrock 去拒绝。这适用于所有不走 Chat Completions 端点的流式请求、发往 Claude 以外模型的所有非流式请求，以及携带 requestMetadata 或 outputConfig 的非流式 Claude 请求。

stop 必须是非空字符串，或由非空字符串组成的数组。数字、对象，或包含非字符串或空字符串的数组，会被以 400 和 invalid_request_error 拒绝，错误消息会点名 stop。单个空字符串、空数组和 null 视为未设置 stop。
max_completion_tokens 必须是非负整数。其他值，例如 -1、1.5 或 "100"，会以同样方式被拒绝，错误消息会点名 max_completion_tokens。

stop 检查适用于所有 Converse 模型，因此请求是否被拒绝不取决于模型组选中了哪个目标。走 InvokeModel 的非流式 Claude 请求按 Anthropic 路径的方式转换这两个值，该路径同样会以点名字段的 400 拒绝无效的 stop 或 max_completion_tokens。

有效的 stop 会在所有 Converse 模型上以 inferenceConfig.stopSequences 发送，包括 AWS 对其拒绝的模型，例如 OpenAI gpt-oss（openai.gpt-oss-*），此时其 400 会返回给调用方。1.7.0 及更早版本的网关不向 gpt-oss、Grok 和 GPT 5.6 及更高版本发送停止序列，有效的 stop 会被忽略。Claude 请求自带的 stop_sequences 优先于 stop。

max_completion_tokens（缺省时为 max_tokens）按原值以 inferenceConfig.maxTokens 发送。1.7.0 及更早版本的网关会把 GPT、Grok 和 Kimi K3 低于 16 的上限提高到 16。

Converse 请求字段

Converse 为常见采样设置提供类型化字段，并用自由格式的 additionalModelRequestFields 对象承载模型专属参数。AISIX 按模型的 Bedrock 文档对每个 chat 请求字段的定义来放置它，遵循请求参数处理：

temperature 和 top_p 以调用方的精确取值写入 inferenceConfig。
OpenAI 模型（gpt-oss、GPT 和 Grok）会在 additionalModelRequestFields 中收到 Converse 没有专属字段的每个 OpenAI 字段，这与 AWS 对这些模型的说明一致，包括 seed、frequency_penalty、presence_penalty、user、safety_identifier、logit_bias、parallel_tool_calls、metadata，以及 json_schema 以外的 response_format。n、logprobs 和 top_logprobs 会被丢弃，因为 Converse 只返回一条消息，也没有对数概率。
Cohere Command R 在 additionalModelRequestFields 中收到 seed 和两个 penalty，AI21 Jamba 收到两个 penalty。其他发布方没有放置这些 OpenAI 字段的位置，AISIX 会丢弃它们。
reasoning_effort 对 gpt-oss、DeepSeek（R1 除外）、Grok、智谱 AI GLM（zai.*）和 Kimi K3 按原值写入 additionalModelRequestFields.reasoning_effort，对 GPT 写为 reasoning.effort。Amazon Nova 2 把 low、medium 或 high 作为带相应 maxReasoningEffort 的 reasoningConfig 接收，把 none 作为 reasoningConfig: {"type": "disabled"} 接收；Nova 2 没有对应设置的档位会被丢弃。Claude 按推理力度所述转换。其他发布方没有推理设置，AISIX 会丢弃该字段。
top_k 对 Claude 写入 additionalModelRequestFields，对 Amazon Nova 写入 inferenceConfig.topK。其他发布方不会收到它。
service_tier 为 auto 时以 serviceTier default 发送，default、flex 和 priority 按原样发送。其他档位会被丢弃。
函数工具的 strict 以 toolSpec.strict 发送。结构化输出的合成工具也以同样方式携带调用方的 json_schema.strict。不接受 strict 的模型会返回 Bedrock 自己的 400，例如 Nova Lite 返回 This model doesn't support the strict field。
additionalModelResponseFieldPaths 和 promptVariables 作为同名的 Converse 顶层字段发送；携带其中任一字段的 Claude 请求由 Converse 而不是 InvokeModel 处理。
其他不属于 OpenAI Chat Completions 的字段视为模型专属参数，写入 additionalModelRequestFields 到达模型。
只携带回放推理内容的 assistant 轮次（无论推理内容是 reasoning_content，还是 Mistral thinking、Databricks reasoning 等推理内容部件）会被排除在 messages 之外。

Converse 会以点名字段的 400 invalid_request_error 拒绝以下取值，因为它无法把这些值带给 Bedrock 判断：未知字符串或缺少类型或函数名的对象形式的 tool_choice，缺少 function 或 name 的工具，不是对象的 parameters，不是数组的 tools，缺少 id 或函数名的回放工具调用，以及不是字符串的 service_tier 或 reasoning_effort。1.7.0 及更早版本的网关会忽略其中大多数取值，并对 OpenAI 模型丢弃上面列出的 OpenAI 字段、strict，以及 Grok、GLM 和 Kimi K3 上的 reasoning_effort。

模型 ID

model_name 可以是裸模型 ID、跨区域推理配置文件 ID 或 ARN。推理配置文件 ARN 按其最后一段中的模型 ID 分类，因此 Claude 配置文件 ARN 会走上述 Claude 路径。应用推理配置文件或预置吞吐量 ARN 不包含模型名，AISIX 通过 Converse 处理。AISIX 无法识别的模型 ID，或包含非法字符的模型 ID，会作为不重试的配置错误失败，模型组也不会从它故障转移。

结构化输出

携带 JSON schema 的 response_format——直接发送到 /v1/chat/completions，或由 Responses 的 text.format、Anthropic Messages 的 output_config.format 转换而来——在 Bedrock 上会被传达给模型。具体形状取决于模型：

Claude 4.5 及更新的模型能够约束自己的解码，因此 schema 以原生方式上送。AISIX 会先从 Bedrock 模型 ID 中读出 Claude 模型名，因此裸 ID（anthropic.claude-sonnet-4-5-...）、跨区域 ID（us.anthropic.claude-...）以及推理配置文件 ARN 都能识别。非流式的 Claude 请求走 Anthropic Messages 协议，schema 放在 output_config.format；Converse 和 ConverseStream 则放在 outputConfig.textFormat，其中 schema 是一个 JSON 字符串，schema 名称在调用方指定时沿用调用方自己的名称。
GPT 5.6 及更新版本以及 Grok 在 Chat Completions 端点上以 OpenAI 格式接收 json_schema 响应格式。
其余所有模型走合成工具路径：一个入参即为答案的 json_tool_call 工具，回复会被翻译回常规内容，流式请求以模拟流式返回。AISIX 只在 Bedrock 上支持强制工具选择的模型系列上强制调用该工具：Anthropic Claude、Amazon Nova、OpenAI（gpt-oss 和 GPT）、xAI、Qwen 3、DeepSeek V3、Kimi K2.5 和 K3、MiniMax M2.x、Nemotron 3、Mistral Large 2407，以及 zai. 和 mistral.devstral-2 模型。其他模型只提供该工具，由模型自行选择这唯一一个工具。

无论哪种模型，调用方自己发送的工具都会照常转发：发布方不支持的工具是调用方显式要求的，理应由调用方看到上游的拒绝。{"type": "json_object"} 没有指定 schema，在两条路径上都不会写入任何内容。

对于 Claude，以及不含发布方名称的模型 ID（例如应用推理配置文件 ARN），Bedrock 记载的 JSON Schema 子集与 Anthropic 相同，因此 schema 的密封和收窄方式也一致，参见 AISIX 如何调整 schema。走合成工具路径的其他发布方模型按原样接收调用方的 schema。

媒体内容和提示词缓存

通过 InvokeModel 或 Converse 发送时，Chat 请求中各模型支持的图片、文档、音频和视频内容会转换为 Bedrock 媒体块；在 Messages 协议上，Claude 接收 image 和 document 块。Claude 只接受图片和 PDF 文档，模型无法接受的内容会以 400 拒绝。Bedrock 自身不读取这些路径中的媒体 URL，因此 AISIX 会下载 http 或 https URL 并内联发送字节。跨区域 Grok 和 GPT 5.6 及更新模型默认使用 Bedrock Runtime 的兼容 OpenAI Chat Completions 路径；该路径保留 OpenAI 请求形态，只下载远程 image_url，而不通过媒体获取转换 input_audio 或 file。需要 Converse 专属功能的请求仍按 Converse 规则处理。下载限制以及控制它的启动配置参见媒体输入与 URL 获取。

提示词缓存标记在所有路由上都会到达 Claude 和 Amazon Nova 模型。在 Converse 和 ConverseStream 上，cache_control 标记会变成紧跟在被标记内容之后的 cachePoint 块。Claude 在 system、messages 和 tools 中接受检查点，并带上标记的 ttl；Nova 在 system 和 messages 中接受检查点，不带 ttl。其他发布方（包括 openai.*）不会收到检查点。发往 Bedrock 时，标记只保留 type 和 ttl。Bedrock 上的部分 Claude 模型只支持 5 分钟缓存，请求 1h 会被拒绝。如需自动添加标记，参见 Anthropic 提示词缓存。

准备生产环境

如果应用使用流式传输，请在 AWS 权限中添加 bedrock:InvokeModelWithResponseStream，并确认目标模型的流式传输行为。

请至少发送一条用户或助手消息。Bedrock 不接受仅包含 system 或 developer 消息的请求。AISIX 在所有路径上都会把此类请求发给 Bedrock，Bedrock 自己的错误会返回给调用方。1.7.0 及更早版本的网关会在调用 Bedrock 之前以 400 invalid_request_error 拒绝它。

Bedrock 返回的错误会带着 Bedrock 自己的错误信息原文传给调用方，其中可能包含账户 ID、ARN 等 AWS 标识符。没有错误信息的错误以状态码命名。ModelTimeoutException 报告为超时，ModelErrorException 报告为上游服务端错误，路由可以重试和故障转移；上下文窗口溢出会带上 code: context_length_exceeded。

Bedrock 运行时调用、Bedrock 安全护栏以及扮演角色时的 AWS STS 调用，会像其他上游调用一样经过网关的 HTTPS_PROXY、HTTP_PROXY 或 ALL_PROXY，除非 NO_PROXY 覆盖该主机。如需让 Bedrock 流量直连，例如连接 VPC 端点，请把其主机加入 NO_PROXY。发往 AWS 凭证端点的请求，例如实例元数据、ECS 任务凭证、EKS Pod Identity 和本地回环地址上的凭证代理，始终直连。1.6.x 及更早版本的网关直接连接 Bedrock。

响应体中没有自身 ID 时，AISIX 会把 Bedrock 的 x-amzn-requestid 响应头记录为服务提供方请求 ID。在 Converse 上，它也是调用方看到的响应 id。参见追踪服务提供方尝试。

后续步骤

你已将 AISIX 连接到 AWS Bedrock，并验证了模型别名。接下来可阅读以下指南：

Anthropic：改为通过 Anthropic API 配置 Claude。
模型别名：为别名配置路由、重试行为或成本元数据。
服务提供方兼容性：查看支持的代理端点和服务提供方特定边界。

准备工作​

使用 AISIX Enterprise 或 AISIX Cloud 配置​

使用开源 AISIX 网关配置​

验证并加载配置​

选择凭证模式​

验证服务提供方连接​

推理力度​

Messages API 上的 Claude​

Claude 的 beta 值​

GPT 和 Grok 模型​

Converse 上的停止序列和输出上限​

Converse 请求字段​

模型 ID​

结构化输出​

媒体内容和提示词缓存​

准备生产环境​

后续步骤​