Amazon Bedrock 现在通过地理跨区域推理（geographic cross-Region inference），在印度提供 Anthropic Claude Opus 5、Claude Sonnet 5 和 Claude Haiku 4.5。应用可以从印度区域发起请求，并在印度区域范围内处理数据，同时继续使用 Bedrock 控制台、Messages、InvokeModel 或 Converse API。
这项变化的重点不只是“多了几个模型”。对于需要控制数据处理地理边界的团队，它让模型能力、容量调度和区域要求可以放进同一套架构中考虑。
地理跨区域推理解决了什么问题
生成式 AI 工作负载往往存在明显的流量波峰。只绑定单一区域时，即使应用本身运行正常，也可能因为模型容量紧张而影响吞吐量。地理跨区域推理允许 Bedrock 在指定地理范围内调度推理请求，以获得更稳定的模型可用性。
此次扩展意味着上述 Claude 模型可以面向印度工作负载使用，并让推理数据在印度区域范围内处理。典型场景包括：
- 面向印度用户的客服、搜索与内容生成服务；
- 需要限制推理数据处理位置的企业应用；
- 已经把业务部署在 AWS 印度区域，希望减少跨地理边界依赖的团队；
- 需要在容量弹性与数据边界之间取得平衡的大规模推理系统。
需要注意，地理跨区域推理并不等于“固定在一个可用区或一个物理设施中执行”。如果企业政策要求请求只能落到某个特定区域，而不是印度这一地理范围，就应在上线前重新核对架构要求与服务配置。
三类 Claude 模型如何放进同一套应用
Claude Opus 5、Claude Sonnet 5 和 Claude Haiku 4.5 可以承担不同层级的任务。具体选择不应只看模型名称，而应通过真实业务数据评估质量、延迟、吞吐和成本。
可以采用分层路由策略：
| 请求类型 | 候选模型 | 评估重点 |
|---|---|---|
| 复杂分析、长流程决策、高价值输出 | Claude Opus 5 | 准确率、推理质量、单次任务价值 |
| 通用对话、代码辅助、知识问答 | Claude Sonnet 5 | 质量、延迟和成本的平衡 |
| 分类、抽取、摘要、低延迟交互 | Claude Haiku 4.5 | 首字延迟、吞吐量、单位请求成本 |
这不是固定规则。例如，一项字段抽取任务如果涉及模糊合同条款，可能需要更强的模型；相反，格式稳定的摘要任务可能由更轻量的模型完成。更稳妥的做法是准备一组脱敏评测样本，对三个模型运行相同测试，再决定默认模型和升级路径。
用 AWS CLI 找到印度地理推理配置
跨区域推理通常通过 inference profile 调用，而不是在代码里猜测模型 ID。下面的命令可以列出当前账号和区域可见的系统推理配置。
运行前需要安装并配置 AWS CLI，同时为调用身份授予相应的 Bedrock 查询与推理权限。示例使用 ap-south-1；如果工作负载位于另一个已支持的印度区域，请替换该值。
export AWS_REGION=ap-south-1
aws bedrock list-inference-profiles \
--region "$AWS_REGION" \
--type-equals SYSTEM_DEFINED \
--query 'inferenceProfileSummaries[].{Name:inferenceProfileName,Id:inferenceProfileId,Status:status}' \
--output table
在输出中查找名称包含目标 Claude 型号、且对应印度地理范围的 profile。不要把博客或测试环境里的 ID 直接写死到生产代码中，因为模型可用性、账号权限和 profile 标识可能随区域及时间变化。
找到目标配置后，可以把 ID 保存到环境变量：
export BEDROCK_INFERENCE_PROFILE_ID='替换为实际的推理配置ID或ARN'
如果列表中没有目标模型，应检查：
- 当前区域是否支持该模型和地理推理配置；
- 账号是否已经获得相应模型访问权限；
- IAM 身份是否拥有列出 profile 和调用模型的权限；
- 组织级 Service Control Policy 是否阻止了 Bedrock 操作。
使用 Converse API 发起一次可运行的请求
下面的 Python 示例通过 Bedrock Runtime 的 Converse API 调用选定的 inference profile。运行前安装较新的 AWS SDK，并确保默认凭证可用：
python -m pip install --upgrade boto3
export AWS_REGION=ap-south-1
export BEDROCK_INFERENCE_PROFILE_ID='替换为实际的推理配置ID或ARN'
保存为 invoke_claude.py：
import os
import boto3
region = os.getenv("AWS_REGION", "ap-south-1")
profile_id = os.environ["BEDROCK_INFERENCE_PROFILE_ID"]
client = boto3.client("bedrock-runtime", region_name=region)
response = client.converse(
modelId=profile_id,
system=[
{
"text": (
"You are a customer-support assistant. "
"Answer concisely and do not invent policy details."
)
}
],
messages=[
{
"role": "user",
"content": [
{
"text": (
"Summarize this ticket in three bullets: "
"The customer cannot download an invoice, "
"has tried two browsers, and needs it before Friday."
)
}
],
}
],
inferenceConfig={
"maxTokens": 300,
"temperature": 0.2,
},
)
parts = response["output"]["message"]["content"]
print("".join(part.get("text", "") for part in parts))
print("Usage:", response.get("usage", {}))
执行：
python invoke_claude.py
这里把 inference profile ID 放在环境变量中，便于在开发、预发布和生产环境使用不同配置。生产系统还应记录请求 ID、延迟、模型配置和 token 使用量，但不要把用户提示词或模型输出无条件写入日志。
如果现有应用已经使用 InvokeModel 或 Messages 格式，也可以继续沿用相应接口。迁移时重点检查 modelId 是否应替换为地理 inference profile，以及请求体是否符合目标 Claude 模型支持的消息格式。对于新建的多模型应用，Converse API 通常更适合建立统一的消息抽象。
数据留在印度，不代表合规工作自动完成
“推理数据在印度区域内处理”只覆盖整体数据治理中的一部分。应用还可能通过其他路径把信息带出预期边界，例如：
- 应用日志把完整提示词发送到外部日志平台；
- APM 或错误追踪工具采集请求正文；
- 对话记录写入其他区域的数据库或对象存储；
- 人工评审队列由境外团队或系统访问；
- RAG 流程调用了位于其他地理区域的向量数据库、搜索服务或重排模型；
- 备份、审计日志和分析数据集使用了不同的数据驻留策略。
因此，架构审查应覆盖从入口、检索、推理、日志到持久化的完整链路。还应根据所在行业和组织政策确认加密、密钥管理、数据保留期、访问控制与审计要求。地理推理能力是技术控制，不应被直接等同于法律或监管认证。
上线前的采用清单
将这些模型接入生产环境前，可以按以下清单逐项验证：
- 在目标印度区域确认 Claude Opus 5、Sonnet 5 或 Haiku 4.5 的实际可用性；
- 使用控制台或
list-inference-profiles获取正确的地理 inference profile； - 以最小权限配置 Bedrock 控制面和 Runtime API 权限；
- 用脱敏业务样本比较质量、延迟、吞吐与成本；
- 为限流、超时和临时容量问题加入指数退避与抖动重试；
- 审查日志、RAG 数据源、数据库、备份和监控系统的数据位置；
- 明确哪些请求可以自动路由到轻量模型，哪些请求必须升级到更强模型；
- 建立输出评测、内容安全、人工复核和回滚机制。
这次可用性扩展让印度工作负载拥有了更完整的 Claude 模型选择。真正的工程价值来自正确使用地理 inference profile，并把模型路由、权限控制、可观测性和端到端数据治理一起落地。