AWS发布Claude平台多环境访问配置指南
AWS机器学习博客发布分步教程，介绍如何在专用AI Services账户中统一管理Claude Platform on AWS订阅，让AWS工作负载、开发者笔记本和外部环境分别通过SigV4、工作区API密钥和OIDC联邦三种方式访问推理服务。
AI解读：这条新闻解决的是一个大模型平台落地时很实际的问题：公司买了Claude Platform on AWS的订阅，但生产集群、开发者电脑、GitHub Actions这类外部CI/CD各需要不同的认证方式。AWS给出的方案是把订阅放进一个专用AI Services账户，其他账户通过跨账户角色来调用，避免把长期密钥散落到各处。
对平台和安全团队来说，最直接的收益是生产与开发流量可以在工作区层面隔开：生产角色只能访问production工作区，开发用的API密钥被限制在development工作区，即便密钥泄露也碰不到生产流量。开发者这边反而更省事，拿一个工作区限定的长期密钥就能用标准Anthropic SDK在本机调用。
外部环境走的是OIDC联邦：GCP、非AWS的Kubernetes集群或GitHub Actions用身份提供商的令牌换AWS临时凭证，再生成一小时的短时令牌，全程不需要存长期凭证。文章同时给出一条容易踩的坑：CallWithBearerToken必须授予在Resource为 * 上，缩到工作区ARN会导致所有令牌生成失败；而CreateInference仍要缩到工作区以保证隔离。
需要注意的是，这只是配置教程，不是产品新功能或性能数据。它适合正在评估账户结构和认证路径的团队按步骤实施，普通用户不需要立即行动。教程本身也说明，账户结构选型的相关决策在前序文章中讨论，这篇是接续那些决策的落地步骤。来源为博客摘要与正文，未提供实际部署后的效果数据。
AWS机器学习博客发布分步教程，介绍如何为Claude Platform on AWS（CPonAWS）配置多环境访问：生产AWS工作负载、开发者笔记本和外部CI/CD或非AWS环境，共用同一个订阅，并在工作区层面隔离生产与开发流量。文章作者为Andrea Gallo。
教程采用专用AI Services账户模式：CPonAWS订阅、工作区、API密钥和跨账户角色都放在组织内一个专用的AI Services关联账户中。工作负载账户不直接接触订阅，而是假设角色进入AI Services账户来发起推理调用。整体形成三账户结构：用于计费与治理的付款（管理）账户、托管订阅与工作区的AI Services账户，以及一个或多个通过跨账户角色使用推理的工作负载账户。
文章配置三种访问方式：AWS工作负载账户通过跨账户SigV4，由工作负载账户中的EKS Pod假设AI Services账户中的角色后发起SigV4签名推理调用，不存储API密钥、无需轮换密钥；开发者笔记本使用锁定到开发工作区的长期API密钥，配合标准Anthropic SDK本地调用；外部工作负载通过OIDC联邦获取临时AWS凭证，再生成短期令牌发起推理，全程无持久凭证。
前提条件与账户、工作区准备
开始前需具备：AWS Organizations中的组织，包含一个付款（管理）账户、一个用于AI Services订阅的关联账户，以及一个承载工作负载的关联账户（例如Prod）；已安装并配置AWS CLI v2，为两个账户设置命名配置文件；Python 3.12+，并安装anthropic[aws]、boto3、token-generator-for-aws-external-anthropic这三个包。
第 1 步是在AI Services账户中按照《Introducing Claude Platform on AWS》指南订阅CPonAWS，然后创建两个工作区以隔离生产与开发流量：在AWS管理控制台进入Claude Platform on AWS，进入Access并以Admin身份登录，在Claude Console左上角下拉菜单选择Create Workspace，输入名称production创建，记录工作区ARN；重复创建名为development的工作区。
- 工作区创建在特定AWS区域，API调用必须指向匹配的区域端点（例如aws-external-anthropic.us-east-1.api.aws）。
- 工作区区域决定API端点，而非推理运行位置；推理地理位置由Claude Console中工作区的Security设置单独控制，当前选项为US和Global routing。
- 短期密钥的区域限制在生成和使用两端都强制执行：令牌只能对生成它的同一区域端点生效。长期API密钥不受区域锁定。
- 支持的区域和可用模型见《Claude Platform on AWS User Guide》中的Supported Regions and models。
AWS工作负载的跨账户SigV4配置
第 2 步让工作负载账户中的EKS Pod（或其他工作负载）通过SigV4签名发起推理调用。该工作负载假设AI Services账户中的角色，而该角色只授予对production工作区的访问权限。
2.1 在AI Services账户创建跨账户角色：在CloudShell中保存trust-policy.json信任策略文件，允许工作负载账户中特定角色假设该跨账户角色，条件为aws:PrincipalOrgID等于组织ID；随后用aws iam create-role创建名为CrossAccount-ClaudePlatform-Prod的角色。
2.2 附加权限策略：保存permission-policy.json，其中CreateInference等操作的范围限定为WORKSPACE_PROD_ID工作区ARN，GetAccountStatus为无资源限制操作，STSWebIdentity允许sts:GetWebIdentityToken和sts:TagGetWebIdentityToken，然后用aws iam put-role-policy附加。文章明确说明，该角色不能访问开发工作区或账户内的其他工作区。
2.3 在工作负载账户授予AssumeRole：在CloudShell中保存allow-assume-cponaws.json，允许sts:AssumeRole到AI Services账户中的目标角色，创建并附加名为AllowAssumeCPonAWSRole的策略到EKS-Pod-Role。
2.4 测试：在具备EKS-Pod-Role凭证的机器或Pod上运行Python脚本，用boto3的sts.assume_role获取临时凭证，设置环境变量后通过AnthropicAWS(aws_region, workspace_id) 客户端调用claude-sonnet-4-6模型。
开发者工作区API密钥的生成与隔离验证
第 3 步为开发者提供无需配置跨账户角色链的本地调用方式。3.1 在AI Services账户生成API密钥：进入Claude Platform on AWS的API keys页面，选择Generate long-term key，选择过期时间并生成，然后立即复制密钥值并安全保存，因为之后不会再显示。
3.2 将密钥限定到开发工作区：默认情况下，生成密钥对应的IAM用户（AeaApiKey-*）附加了AnthropicLimitedAccess托管策略，该策略授予对所有工作区的访问权限。为强制工作区隔离，需在IAM用户中找到最新创建的用户（创建时间应与生成密钥的时间一致），在Permissions标签中移除AnthropicLimitedAccess托管策略，再创建名为CPonAWS-DevWorkspace-Only的内联策略，将CreateInference和CountTokens限定到开发工作区ARN，并允许CallWithBearerToken、GetAccountStatus以及sts:GetWebIdentityToken、sts:TagGetWebIdentityToken。
3.3 分发密钥：管理员将限定范围的API密钥分发给开发团队，存储在团队偏好的密钥管理方案中；对基于AWS的团队，可在工作负载或开发者AWS账户中用aws secretsmanager create-secret存入AWS Secrets Manager。文章说明该API密钥是自认证的，无论从哪个AWS账户或非AWS环境调用都能工作。
3.4 测试：在开发者笔记本上运行代码，从Secrets Manager获取密钥，用Anthropic(api_key, base_url='https://aws-external-anthropic.YOUR_REGION.api.aws') 创建客户端，并通过extra_headers传入anthropic-workspace-id指向开发工作区，调用claude-sonnet-4-6。
3.5 验证隔离：尝试用开发密钥访问production工作区，预期输出为访问被拒绝并伴随权限错误；如果成功访问，说明第 3.2 步的托管策略未正确移除。
外部工作负载的OIDC联邦配置
第 4 步针对运行在GCP、非AWS的Kubernetes集群或CI/CD流水线（GitHub Actions、GitLab CI）上的工作负载，通过OIDC联邦实现无AWS凭证存储的认证。流程为：外部身份提供商签发令牌，AWS STS将其换成临时凭证，再用这些凭证生成短期CPonAWS bearer令牌。
4.1 在AI Services账户创建IAM OIDC身份提供商，为外部工作负载的签发者配置。文章以GCP工作负载为例，指向《Access AWS using a Google Cloud Platform native workload identity》指南。
4.2 创建外部工作负载角色：保存oidc-trust-policy.json信任策略，允许联合身份主体通过sts:AssumeRoleWithWebIdentity假设角色，条件包括audience为sts.amazonaws.com、sub匹配工作负载身份过滤器；创建名为OIDC-ClaudePlatform-Prod的角色后，附加oidc-permission-policy.json权限策略，其中CreateInference等限定到production工作区ARN，CallWithBearerToken和GetAccountStatus为无资源限制，STSWebIdentity允许相关操作。
4.3 生成并使用短期令牌：外部工作负载通过OIDC获得AWS凭证后，从token_generator_for_aws_external_anthropic导入TokenGenerator，用generator.get_token(expiry=timedelta(hours=1)) 生成一小时令牌，再用该令牌作为api_key构造Anthropic客户端，此后无需AWS凭证。
- 文章特别提示：CallWithBearerToken必须授予在Resource: "*" 上，若限定到工作区ARN会导致所有令牌生成调用失败。
- CreateInference仍限定到工作区ARN以保持隔离：生成的令牌会继承该工作区限制。
- 当组织有更多环境时，可为每个团队或工作负载创建一个工作区，并对每个环境重复跨账户角色模式。
来源与范围说明
以上内容整理自AWS机器学习博客文章《Implementing Multi-Environment Access for Claude Platform on AWS》，作者Andrea Gallo，正文包含完整的CLI命令、控制台操作说明和代码片段。文中涉及账户结构选型和认证路径选择的决策，文章指出可参考相关的Architecture Patterns和Authentication Paths文章，本篇是这些决策之后的完整分步实施指南。来源未提供部署后的实际效果数据或性能指标。