Amazon Bedrock是AWS推出的全托管生成式AI服务，最大的特点是把Claude、Llama、Titan、Mistral等多家厂商的基础模型统一封装成一套API，开发者不需要下载模型权重、不需要配置GPU服务器，只要一个API调用就能用上主流大模型。这种托管模式带来的好处非常直接：基础设施由AWS负责，按token计费，天然支持VPC私有网络访问，权限体系直接复用IAM。本文将从模型开通、IAM权限配置、API调用实操到生产环境最佳实践，完整讲清楚Bedrock的使用流程。
一、开通Bedrock模型访问权限
Bedrock有一个和其他AWS服务不太一样的地方：即使你的账号有AdministratorAccess权限，如果没在控制台申请某个模型的使用权限，调用时会直接抛出AccessDeniedException。很多初学者在这一步卡很久，以为是自己IAM策略写错了，实际上是模型订阅没开通。
开通步骤很简单。登录AWS控制台后进入Bedrock服务页面，左下角切换到要使用的区域（比如us-east-1，注意Bedrock在不同区域支持的模型列表有差异），然后在左侧菜单找到Model access入口。页面上会列出当前区域所有可用模型，点击Manage model access，勾选需要的模型。Anthropic的Claude系列需要填写一份简短的使用声明，说明用途并确认不会用于受限场景，提交后大部分模型的审批是即时的，个别模型可能需要等待一段时间。
验证权限是否生效，可以在控制台左侧的Playground里直接测试，能正常返回结果就说明模型访问已开通。也可以用CLI验证：
aws bedrock list-foundation-models \
--region us-east-1 \
--query 'modelSummaries[].modelId'
这条命令会返回当前区域所有可用模型的ID列表，比如anthropic.claude-3-sonnet-20240229-v1:0、meta.llama3-8b-instruct-v1:0等。拿到准确的modelId非常关键，后面调用API时必须使用完全一致的字符串，多一个空格或少一个版本号都会报ValidationException。
二、IAM权限配置与凭证管理
Bedrock的权限控制核心是bedrock:InvokeModel这个Action。下面是一份最小化权限的IAM策略示例，只允许调用指定的两个模型，比直接给bedrock:*安全得多：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0",
"arn:aws:bedrock:us-east-1::foundation-model/meta.llama3-8b-instruct-v1:0"
]
}
]
}
注意Resource字段里模型ARN的格式，区域后面是两个连续的冒号，中间没有账号ID，这是基础模型ARN的特殊写法，写成自己的账号ID反而会报错。如果业务需要使用自定义微调模型，ARN格式则变为arn:aws:bedrock:区域:账号ID:custom-model/模型名，两者不要混淆。
凭证管理方面，本地开发建议直接用aws configure配置AK/SK，或者配合SSO登录。生产环境在EC2或ECS上运行时，最佳实践是给计算角色挂载IAM Role，代码里完全不需要出现明文密钥。如果使用boto3，只要环境里有有效的凭证链，SDK会自动完成认证，不需要额外传参。
还有一个容易忽略的坑：跨账号场景下，除了IAM策略允许，还可能需要在Bedrock侧配置模型共享授权。同账号内IAM策略放行即可，跨账号调用则要确认对方账号是否通过putFoundationModelEntitlement开放了使用权限。
三、使用Python SDK调用模型API
Bedrock的调用方式有两种风格：一是直接调用各模型原生的API格式，二是使用统一的Converse API。推荐优先使用Converse API，因为它把不同模型的请求格式抽象成了统一结构，切换模型时不用重写请求体，代码可维护性明显更好。
先安装依赖：
pip install boto3
下面是一个完整的Converse API调用示例，包含对话历史和流式输出：
import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
messages = [
{
"role": "user",
"content": [{"text": "用两句话解释什么是向量数据库"}]
}
]
# 同步调用，等待完整响应
response = bedrock.converse(
modelId="anthropic.claude-3-sonnet-20240229-v1:0",
messages=messages,
inferenceConfig={"maxTokens": 512, "temperature": 0.7}
)
result = response["output"]["message"]["content"][0]["text"]
token_usage = response["usage"]
print("回复内容:", result)
print("输入token:", token_usage["inputTokens"])
print("输出token:", token_usage["outputTokens"])
# 流式调用，逐块返回
streaming = bedrock.converse_stream(
modelId="anthropic.claude-3-sonnet-20240229-v1:0",
messages=messages
)
for event in streaming["stream"]:
if "contentBlockDelta" in event:
print(event["contentBlockDelta"]["delta"]["text"], end="")
两种调用方式的区别在于体验和成本平衡。同步调用实现简单，适合后台批处理任务；流式调用通过converse_stream实现，响应按内容块逐步推送，用户等待首字出现的延迟大幅降低，适合聊天类产品。另外如果是处理大批量离线任务，还可以用Bedrock的批量推理功能，把请求数据放在S3上，通过bedrock.batch.createModelInvocationJob提交异步任务，批量调用的价格通常是按需调用的一半。
响应中的usage字段记录了输入输出token数量，这是计费和成本监控的依据。生产环境建议把这个数据打到CloudWatch做监控，配合AWS Budgets设置告警，避免某个循环里的bug导致账单失控。
四、常见报错与生产环境建议
整理几个高频问题。第一是AccessDeniedException，前面提过，优先检查模型访问是否开通，再检查IAM策略的Action和Resource。第二是ThrottlingException，说明触发了模型级别的限流，Bedrock对每个模型有默认的TPM（每分钟token数）和RPM（每分钟请求数）配额，可以在Service Quotas里申请提升，代码层面则建议加上指数退避重试，boto3自带的from botocore.config import Config可以配置自动重试次数。
第三是ModelStreamErrorException，流式请求中途被中断，常见原因是网络超时或模型内部错误，客户端要处理好断流后的重新发起逻辑。第四是ValidationException，多半是modelId写错、消息格式不符合规范，或者maxTokens超过了该模型的上限，不同模型的参数上限差异较大，建议查官方文档确认。
架构层面给几条建议：对延迟敏感的应用，把Bedrock放在与调用方相同的区域，并考虑在应用层加一层响应缓存，相同prompt直接命中缓存可以省下全部调用成本；需要私网访问时，配置VPC endpoint接口型终端节点，流量不出公网；涉及敏感数据的场景，开启CloudTrail审计记录所有InvokeModel调用，配合Guardrails做内容过滤。Bedrock自带的Guardrails功能可以配置输入输出的内容审核策略，比如拒绝特定话题、脱敏PII信息，这在合规要求高的业务里非常实用，而且只需要在调用时多传一个guardrailConfig参数就能生效。
总的来说，Bedrock把大模型接入的门槛降到了写几行Python代码的程度，难点主要在权限配置和成本治理这两块。把模型订阅、IAM策略、配额管理这三件事理清楚，剩下的就是选择合适的模型和调用模式了。建议先用Claude Sonnet这类均衡型模型跑通流程，再根据实际效果和成本表现切换到其他模型做对比。
AWS BedrockAPI调用IAM权限配置修改时间：2026-09-11 03:44:52