Amazon Bedrock 现在支持在首尔区域使用 Anthropic Claude Opus 5 和 Claude Sonnet 5，在新加坡区域使用 Claude Sonnet 5。关键变化不只是模型可用性，而是推理请求可以完全在调用的 AWS 区域内处理，为韩国和新加坡存在本地数据处理要求的应用提供了新的部署选择。
模型与区域怎么选
当前公布的区域支持关系是：
| AWS 区域 | 区域代码 | 可用模型 |
|---|---|---|
| 首尔 | ap-northeast-2 |
Claude Opus 5、Claude Sonnet 5 |
| 新加坡 | ap-southeast-1 |
Claude Sonnet 5 |
如果工作负载必须在韩国境内完成推理处理，可以把 Bedrock Runtime 客户端固定到首尔区域；如果数据处理边界在新加坡，则应调用新加坡端点。不要让 SDK 使用开发者电脑上的默认区域，否则请求可能被发送到与预期不同的区域。
选型时还应考虑任务特点。可以把 Sonnet 5 用于延迟和吞吐量更敏感的通用生成、摘要、分类或智能助手场景；需要更强复杂推理能力时，再评估首尔区域提供的 Opus 5。具体价格、限额和性能应以目标区域的实际配置与压测结果为准。
先确认目标区域中的模型标识
模型名称与调用时使用的模型 ID 不一定相同，而且账户可见性和访问方式可能存在差异。不要在代码中猜测模型 ID，可以先使用 AWS CLI 查询。
# 首尔：查找 Anthropic 模型
aws bedrock list-foundation-models \
--region ap-northeast-2 \
--by-provider Anthropic \
--query 'modelSummaries[].{Name:modelName,ModelId:modelId,Status:modelLifecycle.status}' \
--output table
# 新加坡：查找 Anthropic 模型
aws bedrock list-foundation-models \
--region ap-southeast-1 \
--by-provider Anthropic \
--query 'modelSummaries[].{Name:modelName,ModelId:modelId,Status:modelLifecycle.status}' \
--output table
运行前需要安装并配置 AWS CLI，例如执行 aws configure 或通过工作负载角色提供凭证。随后从输出中找到 Claude Opus 5 或 Claude Sonnet 5 对应的准确模型 ID。如果控制台要求通过推理配置文件调用，则应使用控制台或 API 返回的配置文件 ID，而不是自行拼接标识符。
用 Python 发起固定区域的推理请求
下面示例采用 Bedrock Runtime 和 Anthropic Messages 请求格式。运行前，把 BEDROCK_MODEL_ID 替换为上一步查询到的模型 ID；首尔使用 ap-northeast-2，新加坡使用 ap-southeast-1。
python -m venv .venv
source .venv/bin/activate
pip install --upgrade boto3
export AWS_REGION=ap-northeast-2
export BEDROCK_MODEL_ID='替换为目标区域返回的模型ID'
保存为 invoke_claude.py：
import json
import os
import boto3
region = os.environ.get("AWS_REGION", "ap-northeast-2")
model_id = os.environ["BEDROCK_MODEL_ID"]
client = boto3.client("bedrock-runtime", region_name=region)
request_body = {
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 500,
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "请将下面的客服记录总结为三条待办事项：客户希望修改配送地址，并确认退款到账时间。"
}
]
}
]
}
response = client.invoke_model(
modelId=model_id,
contentType="application/json",
accept="application/json",
body=json.dumps(request_body).encode("utf-8"),
)
result = json.loads(response["body"].read())
print(json.dumps(result, ensure_ascii=False, indent=2))
执行：
python invoke_claude.py
代码显式创建目标区域的客户端，因此不会依赖 SDK 的隐式区域选择。生产环境还可以在启动时输出当前区域与模型 ID，并设置允许区域清单，避免部署参数错误：
allowed_regions = {"ap-northeast-2", "ap-southeast-1"}
if region not in allowed_regions:
raise RuntimeError(f"不允许在该区域调用模型: {region}")
调用角色至少需要相应的 Bedrock 推理权限。验证阶段可以使用下面的最小示例，再根据组织安全策略把资源范围收紧到实际模型或推理配置文件：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "*"
}
]
}
区域内推理不等于整条链路自动合规
这项能力保证的是模型推理在所调用的区域内处理，但一个完整应用通常还包含 API Gateway、Lambda、容器、对象存储、数据库、日志、链路追踪和备份。如果提示词在进入 Bedrock 前被写入其他区域的日志，或者模型输出被发送到跨区域分析系统，整体数据路径仍可能超出本地边界。
上线前建议逐项检查：
- Bedrock Runtime 客户端是否显式固定到首尔或新加坡。
- 输入数据、模型输出、缓存和会话历史是否存储在同一区域。
- CloudWatch 日志、追踪数据和错误报告是否包含敏感提示词。
- 是否存在跨区域复制、集中日志或外部可观测平台。
- IAM 策略是否只允许批准的模型、角色和区域。
- 目标区域的模型访问、服务配额、并发能力和降级策略是否已验证。
对于必须严格限制区域的系统，还可以在组织级策略中限制 aws:RequestedRegion，但应先确认该限制不会影响全局 AWS 服务或现有运维流程。
采用建议
更稳妥的迁移方式是先选择一条低风险业务链路，在目标区域完成端到端数据流审计和负载测试，再逐步扩大流量。测试不应只比较回答质量，还要记录首字节延迟、整体响应时间、令牌消耗、限流情况和失败重试行为。
首尔同时提供 Opus 5 与 Sonnet 5，适合通过相同测试集比较质量、成本与延迟；新加坡当前重点是 Sonnet 5。无论选择哪种模型，都应把区域和模型 ID作为受控部署参数，而不是散落在业务代码中的字符串。这样既能利用区域内推理，也能降低误调用其他区域和后续模型升级的风险。