先理解：Bedrock 不是下载安装到本地的软件

Amazon Bedrock 是 AWS 提供的托管式生成式 AI 服务。新手常误认为需要下载模型或安装服务器。实际配置重点不在“安装包”，而在云端环境准备。

需要准备的内容包括：选择支持的区域、开通模型访问权限、配置 IAM 权限、安装本地命令行工具或 SDK，并把开发、测试、生产账号做好隔离。

对于个人开发者，可以先用单账号跑通。对于团队或企业项目，更建议从一开始就采用多账号结构，避免后期权限混乱、成本难追踪、测试影响线上服务。

Bedrock 适合做文本生成、摘要、知识问答、代码辅助、向量检索增强生成等场景。它的优势是无需自行维护大模型基础设施，能通过统一 API 调用不同模型。但它并不等于完全免费，也不意味着默认可用。

不同区域、不同模型、不同调用方式的开通状态和计费规则可能不同，配置前必须先做检查。

准备工作：账号、区域和本地工具

第一步：确认账号与区域

确认 AWS 账号状态正常，并选择 Bedrock 可用区域。常见选择包括 us-east-1、us-west-2 等，具体以控制台显示为准。进入 Bedrock 控制台后，先查看“Model access”或模型访问入口，选择需要的模型并提交开通申请。部分模型可即时启用，部分模型需要补充用途说明或等待审核。

第二步：安装本地工具

开发者通常需要 AWS CLI v2、Python 或 Node.js 运行环境，以及对应 SDK。Python 项目可使用 boto3，Node.js 项目可使用 AWS SDK for JavaScript v3。

安装后在终端执行 aws --version，确认 CLI 可用。再执行 aws sts get-caller-identity，确认当前凭证能正确识别身份。

第三步：准备权限

不要直接长期使用根账号或高权限账号进行开发。 建议新建 IAM 用户或角色，只授予 Bedrock 调用、日志查看、必要的对象存储或函数计算权限。

若只是本地测试，可先配置只读查看和模型调用权限。若要部署应用，再按服务逐项增加权限。

单账号快速跑通流程

单账号适合个人学习、概念验证和小型 Demo。流程可以按五步走：

• 进入目标区域的 Bedrock 控制台，开通需要的模型。
• 创建 IAM 权限策略，允许 bedrock:InvokeModel、bedrock:InvokeModelWithResponseStream，以及必要的 bedrock:ListFoundationModels。
• 创建访问凭证或使用临时角色。
• 在本地执行 aws configure，填写 Access Key、Secret Key、默认区域和输出格式。
• 用 SDK 发起一次最小请求，验证模型能返回内容。

注意：模型 ID 必须与区域匹配。 常见报错包括“模型不存在”“未授权访问”“区域不支持”。如果控制台能看到模型，但 API 调用失败，优先检查三个点：

• 当前 CLI 配置的区域是否一致
• 当前身份是否拥有模型调用权限
• Bedrock 模型访问是否已经批准

不要为了省事直接给 AdministratorAccess，这会让后续排查和安全管理变得困难。

多账号配置：推荐的团队结构

多账号配置的核心是隔离。常见结构是一个管理账号，加上 dev、test、prod 三类业务账号。

• 管理账号：只负责组织和统一审计，不直接跑业务。
• dev：用于开发试验，权限相对灵活但必须限制预算。
• test：用于集成测试，尽量模拟生产环境。
• prod：用于正式服务，权限最小、变更严格、日志完整。

如果团队使用 AWS Organizations 和 IAM Identity Center，可以为不同成员分配不同权限集。例如开发人员可访问 dev 账号并调用 Bedrock，测试人员可访问 test 账号查看日志，运维人员可对 prod 执行受控发布。这样做的好处是人员离职、项目切换、权限调整时，不需要在每个账号里手工维护大量长期凭证。

多账号调用 Bedrock 时，一般有两种方式：

• 第一种：在每个业务账号内分别开通模型访问，并由本账号应用直接调用。这种方式边界清晰，成本好归属。
• 第二种：建立共享 AI 服务账号，由其他业务账号通过角色切换调用统一服务。这种方式便于集中治理，但需要设计跨账号角色、调用审计和配额隔离。

小团队建议先用第一种，成熟后再考虑共享服务模式。

本地多账号配置示例思路

在本地开发机上，不建议反复覆盖默认凭证，而应使用 profile 区分账号。可以配置 dev-bedrock、test-bedrock、prod-bedrock 三个配置项，每个 profile 指向不同角色或不同临时凭证。开发时通过 AWS_PROFILE=dev-bedrock 运行程序，测试时切换到 test-bedrock。这样可以避免把测试脚本误连到生产环境。

更稳妥的做法是使用角色承担机制。开发者先通过统一身份入口登录，再承担目标账号中的 BedrockRole。角色策略中只允许必要操作，并限制可调用区域、可访问日志、可操作资源范围。

生产角色不要配置到个人长期密钥中，发布系统也应使用短期凭证，减少凭证泄露后的影响范围。

免费方案检查清单：先控风险再动手

Bedrock 的“免费”不能简单理解为随便调用不产生费用。不同模型、区域和活动政策会变化，实际以控制台计费页面和官方价格页为准。

配置前建议完成这份检查清单：

• 是否已确认目标模型的输入与输出价格
• 是否设置预算提醒
• 是否限制开发账号每日调用量
• 是否关闭不用的测试任务
• 是否记录每个项目使用的模型 ID
• 是否为日志设置保留周期
• 是否避免在测试中上传大量无关数据
• 是否为向量库、对象存储、函数计算等配套资源设置清理规则

如果只是学习，优先选择低成本模型、小输入、小输出、低并发方式测试。不要一开始就做大批量生成、长上下文、多轮循环调用。应用中要设置 max_tokens、超时时间、重试次数和并发上限，防止程序异常循环请求。团队项目还应为 dev、test、prod 分别设置预算提醒，避免某个实验任务持续运行。

权限与数据安全边界

调用生成式 AI 服务时，安全边界必须提前写清楚。

• 第一：不要把长期密钥写进代码仓库、镜像、前端页面或共享文档。
• 第二：不要把敏感客户资料、内部密钥、未脱敏业务数据直接送入提示词。
• 第三：生产环境必须记录调用时间、调用方、模型、请求规模和错误信息，但日志中应避免保存完整敏感内容。
• 第四：跨账号角色要设置可信主体，不能允许任意账号承担角色。

权限策略应遵循最小化原则。开发环境可以允许列出模型和调用指定模型，生产环境则建议只允许调用已评估的模型 ID。若应用结合知识库、搜索服务或对象存储，还要分别控制读写权限，避免一个应用角色同时拥有过宽的数据访问能力。对于面向用户的应用，还应增加输入过滤、输出审核、速率限制和人工复核流程。

常见问题与排查方法

• 问题一：控制台看不到 Bedrock。 通常是区域不支持或账号权限不足，先切换到支持区域，再检查当前身份是否有访问控制台服务的权限。
• 问题二：模型已申请但 API 报未授权。 检查模型访问是否已批准、profile 是否正确、区域是否一致、策略是否包含 InvokeModel。
• 问题三：本地能跑，部署后失败。 多半是运行环境使用了不同角色，需要查看云端执行角色的权限，而不是本地开发者权限。
• 问题四：响应很慢或超时。 可降低输出长度、减少上下文内容、启用流式返回，或检查应用所在区域与 Bedrock 调用区域是否合理。
• 问题五：费用超预期。 查看调用量、输入输出 token、重试逻辑和批处理任务，尤其要检查失败后自动重试是否过多。
• 问题六：多账号混淆。 统一命名 profile、角色和预算标签，例如 project-env-purpose，减少误操作。

实用建议：从小闭环开始

最稳的落地方式是先用 dev 账号完成最小闭环：开通一个模型，写一个最短调用脚本，接入日志，设置预算提醒，再扩展到测试环境。确认提示词、权限、成本和异常处理都可控后，再进入生产账号。

不要在生产环境首次试验模型能力，也不要把多模型切换、知识检索、批量任务一次性全部上线。

对于长期项目，建议建立一份 Bedrock 配置文档，记录区域、模型 ID、账号结构、角色名称、预算规则、日志位置、数据边界和回滚方式。

Bedrock 不需要传统意义上的安装，但它需要严谨的环境治理。把账号、权限、成本和安全边界配置好，后续开发 AI 应用才会稳定、可控、容易扩展。