Claude Platform on AWS 访问统一三类环境，但 IAM 精细度决定安全结果

AWS 已记录了在单一订阅下使用 Claude Platform on AWS 的三条访问路径，尽管它们的凭证与安全要求存在显著差异。

这项于 10 月 1 日发布的实施方案，将 AWS 工作负载、开发者笔记本电脑和外部服务连接至专用 AI Services 账户中的工作区。生产应用使用跨账户 Signature Version 4，开发者获得限定范围的 API 密钥，外部工作负载则通过 OpenID Connect 联合身份验证。

该架构承诺实现集中式计费和管理，同时不强制所有环境采用同一种凭证模型。其中的张力也同样明显：集中化简化了所有权管理，但宽泛的 IAM 策略或处理不当的开发者密钥，可能会削弱使该设计具备价值的工作区边界。

这不仅仅是另一份 Claude 集成指南。AWS 实施方案将身份验证转变为按环境划分的控制平面，也揭示了“单一订阅”这一表述背后隐藏的运营工作。

Amazon Bedrock 仍是重要参照。它通过 AWS 管理的基础模型服务提供 Claude 模型。Claude Platform on AWS 则通过 AWS 账户提供 Anthropic 原生平台体验，包括其 API、控制台和平台功能。

新的访问模式并未抹去这种区别。它展示了企业如何在保留基于 IAM 的生产流量控制的同时，将 Anthropic 的原生平台扩展至整个 AWS 组织。

一个订阅现已服务于三条信任边界

重要的变化不只是连接范围扩大。AWS 在保持工作区所有权集中的同时，已将三类环境映射到三种不同的身份验证方式。

建议的拓扑结构始于三类账户角色。管理账户负责组织级别的计费与治理。专用 AI Services 账户拥有 Claude Platform 订阅、工作区、API 密钥和访问角色。

随后，一个或多个工作负载账户可使用 Claude 推理能力，但并不拥有订阅。这些账户中的应用会承担 AI Services 账户中的角色，并调用由这些角色授权的工作区资源。

这种划分赋予 AI Services 账户明确用途。它成为 Claude 访问的管理边界，而非又一个装满无关资源的通用应用账户。

AWS 建议在该账户内创建独立的生产和开发工作区。工作区是用于隔离团队、项目或环境，同时保留集中式管理的资源边界。

每个工作区都拥有可供 IAM 策略引用的 Amazon Resource Name，即 ARN。因此，权限可以授权针对某一工作区的推理，而不会自动授权访问其他工作区。

第一条访问路径覆盖已在 AWS 内部运行的应用。AWS 以 Amazon EKS pod 为例，但该模式同样适用于其他 AWS 工作负载。

该 pod 首先承担 AI Services 账户中的跨账户角色。随后，临时凭证使用 AWS Signature Version 4（通常称为 SigV4）为 Claude 请求签名。

SigV4 使用 AWS 凭证对 AWS API 请求进行加密签名。它使接收服务无需单独的静态 API 密钥，即可验证调用方、请求完整性和授权上下文。

跨账户角色授予针对生产工作区 ARN 的指定 aws-external-anthropic 操作。示例包括推理、令牌计数、模型获取和模型列表查询。

该角色无需获得访问开发工作区的权限。这在工作负载身份、允许的 API 操作与获准使用的 Claude 工作区之间建立了直接关联。

第二条路径面向开发者笔记本电脑。开发者通常需要以更低的摩擦测试提示词、SDK 行为和应用逻辑，而不必依赖已部署的工作负载。

AWS 为这些用户分配与开发工作区关联的长期 API 密钥。标准 Anthropic SDK 可通过该密钥访问区域性 Claude Platform on AWS 终端节点。

这条路径保留了熟悉的开发者体验，但也产生了持久的持有者凭证。任何持有该密钥的人，都可以在密钥到期或管理员撤销前使用其权限。

第三条路径面向外部服务。例如，运行于 Google Cloud、非 AWS Kubernetes 集群，以及 GitHub Actions 或 GitLab CI 等 CI/CD 系统上的工作负载。

这些服务使用 OIDC 联合身份验证，将身份提供商签发的令牌交换为临时 AWS 凭证。临时凭证随后生成短期 Claude 持有者令牌。

AWS 的示例创建了有效期为一小时的令牌。该实施方案允许配置最长 12 小时的有效期，之后外部服务必须获取新的令牌。

这三条路径共同构成 Claude 多环境访问的核心。订阅保留在一个账户中，而身份验证方式则随调用方运行位置而变化。

这正是架构上的进步。它认识到 EKS pod、开发者笔记本电脑和外部流水线不应共用同一种通用凭证模式。

Claude Platform on AWS 访问将控制权移入 IAM

Claude Platform on AWS 访问如今较少取决于代码运行位置，而更多取决于 IAM 是否准确描述其预期身份和工作区。

AWS 将该服务介绍为通过现有 AWS 账户使用 Anthropic 原生平台的方式。该公司表示，AWS 是首家通过自身账户结构提供这种原生体验的云服务提供商。

最初发布将身份验证、计费和审计功能连接至 AWS。客户无需建立单独的商业关系，即可使用 Anthropic 的 API 和工具。

多环境设计将这一主张扩展到了基础 API 连接之外。它使 AWS 组织，而非单个应用，成为组织 Claude 访问的核心层。

这很重要，因为企业的 AI 使用很少局限于单一环境。一个团队可能在本地测试应用，将其部署到 EKS，并从另一家云服务商运行评估。

一把共享的静态密钥可以连接这三个位置，但也会压缩它们各自的身份。日志显示的是密钥，而不一定是使用它的工作负载、账户或流水线。

跨账户角色能保留更多上下文。工作负载承担一个具名角色，获取临时凭证，并发出 AWS 可归因于某一主体的已签名请求。

该角色还设置了两个授权检查点。工作负载账户必须允许其本地身份承担目标角色；AI Services 账户则必须信任该身份及其所在组织。

AWS 的示例在信任策略中添加了 aws:PrincipalOrgID 条件。该条件将角色承担限制为与指定 AWS 组织关联的主体。

权限策略随后将推理限制在生产工作区 ARN。信任机制回答谁可以进入该角色，而权限则定义该角色之后可以执行什么操作。

这种划分使那些此前将模型访问视为密钥分发的团队面临新的要求。它们现在需要将 Claude AWS 身份验证作为身份架构来管理。

安全、平台和应用团队必须就账户所有权达成一致，还需要为角色、工作区、策略和环境映射制定命名标准。

专用账户可以让这些职责更加清晰可见，但并不会自动确保它们被正确配置。

该架构也会影响事件响应。生产角色可以被禁用，而无需立即移除开发者访问权限。遭泄露的开发密钥可以被撤销，而无需修改 EKS 工作负载角色。

工作区隔离同样可支持成本归因。AWS 表示，组织可以为工作区添加标签，并启用这些标签用于成本分配。

在启用后，AWS 表示这一过程可能需要 24 至 48 小时，团队即可按工作区筛选 AWS Cost Explorer 数据。这为从技术隔离到项目级支出分析创造了一条路径。

可审计性还需要另一项明确选择。默认情况下，工作区管理会出现在 CloudTrail 管理事件中，但推理属于数据事件类别。

监控文档表示，团队必须启用数据事件日志记录，才能捕获推理及其他工作区操作。这些事件还可能产生额外的 CloudTrail 费用。

这一差异很容易被忽视。集中订阅提高了审计轨迹的潜在完整性，但并不保证推理活动正在被记录。

因此，该设计要求平台所有者将可观测性视为访问控制的一部分。策略可以限制操作，而日志则提供了关于实际执行该操作的主体的证据。

三条身份验证路径解决不同问题

该架构之所以有效，是因为它避免将便利性、工作负载身份和外部联合身份验证强行纳入同一凭证生命周期。

对于 AWS 工作负载，跨账户 SigV4 与现有云身份体系的契合度最高。应用通过承担角色获得临时 AWS 凭证。

随后，它会为向 Claude 终端节点发出的每项请求签名。工作负载账户、容器镜像或部署配置中无需存储单独的 Claude API 密钥。

这种方式遵循既有 AWS 指导。该公司的 IAM 最佳实践建议工作负载使用临时角色凭证，而非长期访问密钥。

生产角色可以仅包含应用实际需要的操作。一个基础同步应用可能需要推理和令牌计数权限，但不需要文件、批处理或管理操作。

Claude Platform on AWS 使用 aws-external-anthropic IAM 命名空间。其权限模型将 API 路由映射至特定操作，例如用于消息请求的 CreateInference。

该操作可以引用一个工作区 ARN。应用由此获得生产工作区访问权限，而不会继承账户范围的 Claude 权限。

对于持续运行的 AWS 工作负载，这是三条路径中最强的一种。应用无需携带持久 Claude 密钥，AWS 也可将请求归因于已承担的身份。

开发者笔记本电脑面临不同约束。要求每次本地实验都经过跨账户角色链，可能提高配置成本并拖慢迭代。

因此，AWS 为开发环境使用限定至工作区的 API 密钥。该密钥可配合标准 Anthropic 客户端使用，并指向 Claude Platform on AWS 的区域终端节点。

关键限制在于，新生成的密钥并不会自动具备足够窄的权限范围来满足该模式。AWS 表示，其后端 IAM 用户最初会获得 AnthropicLimitedAccess 托管策略。

根据实施指南，该托管策略授予跨工作区访问权限。管理员必须将其解除附加，并替换为仅限开发环境的内联策略。

这一步是开发者路径中最关键的手动控制环节。生成密钥很容易，而落实预期的工作空间边界则需要单独修改 IAM。

AWS 建议随后测试该边界。开发者应当成功调用开发工作空间，然后尝试发起生产请求，并确认 IAM 会拒绝该请求。

这项负向测试比成功请求更重要。开发环境的响应只能证明连通性，而只有被拒绝的生产调用才能验证隔离主张。

API 密钥仍然具备自认证特性。它可在 AWS、其他云平台或笔记本电脑上使用，因为持有密钥本身就提供了凭证。

因此，团队应将其存储在经批准的密钥管理器中，并设置过期时间。同时，还需要针对设备丢失、角色变更和意外暴露到代码仓库等情况制定吊销流程。

外部工作负载路径消除了这种持久化密钥。OIDC 允许兼容的身份提供商签发用于识别工作负载的 JSON Web Token。

AWS Security Token Service 会验证该令牌并检查角色的信任条件，然后通过 AssumeRoleWithWebIdentity 返回临时 AWS 凭证。

OIDC 指南建议将这一模式用于 AWS 之外的应用，因为它避免了嵌入长期凭证。

外部工作负载使用临时 AWS 凭证请求一个短期 Claude bearer token。生成后，该 bearer token 可以调用 Claude，而无需保留 AWS 凭证。

这适用于外部容器和 CI/CD 作业，但令牌续期会成为应用的一部分。持续运行的服务必须在令牌过期前刷新它。

OIDC 信任策略同样值得密切关注。AWS 的示例会根据预期值检查令牌的 audience 和 subject 声明。

audience 用于识别令牌的预期接收方。subject 则用于区分获准的工作负载、服务账户、代码仓库或流水线身份。

宽松的声明过滤条件可能会允许超出预期的外部身份访问。即使联合机制本身正确，不精确的信任条件仍会导致过度授权。

因此，这些路径是互补关系，而非可以相互替代。

• 跨账户 SigV4 适用于已通过 AWS 身份治理的生产工作负载。

• 工作空间范围的 API 密钥可降低本地开发的使用门槛。

• OIDC 联合适用于能够提供可验证工作负载身份的外部自动化。

共同要素是工作空间。每条凭证路径最终都应解析为与该环境相匹配的工作空间权限。

集中化并不能消除凭证风险

只有当每个角色、密钥、信任条件、端点和日志设置都与预期工作空间一致时，这一设计才能改善隔离。

最明显的风险位于开发者路径。AWS 自身的说明指出，新生成的 API 密钥起初会附带一项托管策略，可访问每个工作空间。

管理员必须识别新创建的底层 IAM 用户，移除该策略，并附加范围更窄的内联策略。

这一流程容易受到人为错误影响。管理员可能为错误的用户设定范围、保留托管策略，或引用错误的工作空间 ARN。

由此产生的密钥仍可正常工作。其成功的开发请求不会暴露它仍保有生产访问权限这一问题。

强制性的拒绝测试可以捕捉这种错误。组织应将生产访问测试纳入密钥签发流程，而不是作为之后可选的验证步骤。

长期密钥的归因能力也弱于基于角色的访问。多名开发者共用一个密钥时，可能会在审计记录中显示为同一主体。

单独的密钥可以改善归因，但也会增加需要安全存储、设置过期、吊销和跟踪所有权的凭证数量。

跨账户路径存在不同的失效模式。信任策略可能过于宽泛，或者工作负载侧的承担权限可能指向错误的目标角色。

aws:PrincipalOrgID 条件有助于限制组织范围。但它不能替代精确的主体 ARN 或严谨的角色命名。

权限也应在操作级别接受审查。对整个 aws-external-anthropic 命名空间授予通配符访问，会削弱该指南的最小权限结构。

AWS 发布了关于单工作空间推理及其他控制措施的详细 IAM 策略示例。团队应根据实际使用的 API 功能验证已部署的策略。

OIDC 路径将安全重心转向外部身份声明。其安全性取决于签发者、audience、subject 过滤器、角色策略和令牌续期逻辑能否协同正常工作。

覆盖整个代码仓库组的 subject 模式，可能会授权不相关的流水线。宽泛的服务账户模式可能会接纳预期命名空间之外的工作负载。

临时凭证限制了暴露时长，但并不能纠正在这段时间内存在的过度权限。短期访问比永久访问更安全，但并不天然意味着最小权限。

生成的 Claude token 也会成为独立的 bearer 凭证。在过期之前，只要持有它，就足以在继承的授权边界内使用它。

应用应避免将其输出到日志、构建输出、异常跟踪或监控元数据中。在可行情况下，令牌有效期应与作业持续时间相匹配。

区域行为增加了另一项运维约束。工作空间在某个 AWS Region 中创建，API 请求必须指向相应的区域端点。

AWS 将这种端点绑定与推理地理位置区分开来。工作空间的安全设置会独立决定推理是采用美国路由还是全球路由。

短期密钥只能与其生成时所使用的同一区域端点配合使用。根据 AWS 的指南，长期 API 密钥不受区域锁定。

这种差异可能会在部署过程中造成令人困惑的故障。令牌续期流程可能在一个 Region 中成功，而应用却指向另一个端点。

该架构还存在一个买方必须理解的更广泛边界。AWS 表示，Claude Platform on AWS 由 Anthropic 运营，请求和数据会在 AWS 安全边界之外处理。

这使该服务不同于“所有处理都保留在 AWS 控制的服务边界内”的假设。对数据驻留有严格要求的组织需要进行单独审查。

AWS 将 Claude Platform on AWS 定位为对通过 Amazon Bedrock 提供的 Claude 模型的补充。因此，选择并不只是某一种认证方法与另一种之间的对比。

其中还涉及平台功能、运营归属、处理边界和区域要求。多环境访问并不能为每项工作负载解决这些问题。

集中化也可能扩大管理错误的影响范围。AI Services 账户持有订阅、工作空间、API 密钥和访问角色。

该账户的一项变更可能同时影响多个应用账户。因此，设计应对该账户实施比普通开发环境更严格的变更控制。

团队应尽可能将策略编写与审批分离。基础设施即代码也可以减少不同团队和工作空间之间不一致的角色定义。

AWS 表示，拥有更多环境的组织可以为每个团队或工作负载创建一个工作空间，并重复使用跨账户角色模式。

这种方式可以扩展隔离模型，但也会增加策略、角色关系、日志、标签和端点配置的数量。运维纪律将成为限制因素。

因此，核心承诺应谨慎表述。这一模式提供了工作空间隔离所需的组件，但部署的策略和凭证处理方式决定了这种隔离能否成立。

企业接下来应验证什么

下一项测试是组织能否持续一致地运行这一访问模型，而不是三种认证流程能否在演示中运行。

第一个信号是自动化策略验证。团队应确认每个生产角色都只面向一个预期的工作空间 ARN，并且仅拥有所需的 API 操作权限。

开发者密钥签发应包含策略替换、过期设置、密钥存储以及强制性的生产访问拒绝测试。依赖记忆的流程终将发生偏移。

如果组织通过部署流水线自动执行这些检查，AWS 的集中化模型在大规模场景下会更具可信度。反复的手动例外会削弱这一结论。

第二个信号是审计覆盖范围。仅依赖 CloudTrail 管理事件无法提供每次推理调用的可见性。

组织应为相关 Claude 工作空间资源类型启用数据事件，然后验证记录是否包含有用的主体归因信息。

他们还应测试事件响应人员能否将请求关联到 EKS 角色、开发者密钥或外部 OIDC 身份。

如果审计路径能够保留这些差异，三路径架构就能支持可追责的访问。如果日志将调用者压缩为共享身份，集中化的调查价值就会降低。

第三个信号是 AWS 原生应用之外的采用情况。OIDC 路径专为外部云、Kubernetes 部署和 CI/CD 系统设计。

其真正的考验将是长时间运行作业中的可靠令牌轮换。随着代码仓库和服务账户发生变化，团队还必须维持严格的 subject 和 audience 声明。

频繁的认证故障会促使开发者退回使用长期密钥。具备精确信任条件的稳定续期将强化联合方案。

企业还应监控工作空间的扩张。为每个团队或工作负载创建一个工作空间，可以改善隔离、所有权和成本分配。

若没有一致的标签和生命周期规则，过多的工作空间可能造成另一种形式的蔓延。旧密钥、废弃角色和未使用的工作空间都需要退出流程。

专用 AI Services 账户应成为受治理的服务边界。其管理员需要为每个工作空间、角色和凭证保留所有权记录。

平台团队可以将访问决策与应用架构和事件流程一并记录。可搜索的工程知识库可以帮助团队在人员变化时保留这些映射关系。

最有价值的评估应从一条完整的应用路径开始。通过 SigV4 连接生产工作负载，通过受限密钥连接开发客户端，并通过 OIDC 连接流水线。

然后验证跨工作空间请求被拒绝、令牌续期、CloudTrail 数据事件和紧急吊销。在日常策略变更之后，这些控制措施是否仍然有效？

这个答案比首次请求成功更重要。Claude Platform on AWS 访问如今支持在一个订阅下覆盖三种环境，但其安全价值取决于可重复验证的隔离证明。