AWS发布HyperPod多租户参考架构：单EKS集群按团队隔离并分摊GPU成本
AWS机器学习博客发布一套参考架构，用IAM Identity Center集中认证、每团队独立SageMaker AI域与Kubernetes命名空间隔离，并以HyperPod Task Governance分配算力和按命名空间分摊费用。
AI解读：AWS发布的是参考架构，而非一个新的托管功能。架构用于让同一公司内多个团队共享一个由EKS编排的SageMaker HyperPod集群，同时保留隔离边界和资源公平性。
隔离由三层叠加：IAM Identity Center负责统一认证，每个团队配置独立的SageMaker AI域和IAM执行角色，集群内为每个团队建Kubernetes命名空间（如hyperpod-ns-team-a），EKS访问条目将角色限定到所属命名空间。
公平性与成本归属由HyperPod Task Governance和命名空间级成本分摊负责。AWS称这一层用于计算配额管理与调度优先级，并让每团队支出可见、可回冲。
架构还覆盖存储：POSIX文件系统（FSx for Lustre或OpenZFS）按团队和个人划分目录，S3按团队或共享使用，由团队IAM执行角色管辖。
认证示例以Microsoft Entra ID为外部身份提供方，通过SCIM同步三个组（TeamA、TeamB、Admin），并配置SAML 2.0联邦；AWS称该模式适用于多数标准SAML 2.0提供方。
AWS提到Amazon Managed Grafana以Identity Center作为员工用户认证机制，因此需要可观测性仪表板时可沿用同一认证层。以上均为该架构设计说明，来源未给出部署后的效果数据。
AWS机器学习博客发布一套在Amazon SageMaker HyperPod上构建多租户环境的参考架构，目标场景是公司内多个团队共享同一个由Amazon EKS编排的GPU集群。
该架构组合了五项机制：AWS IAM Identity Center集中认证、每团队独立的SageMaker AI域、Kubernetes命名空间做工作负载隔离、HyperPod Task Governance做资源公平分配，以及命名空间级成本分摊用于团队支出可见性与回冲。
架构如何把用户限定在所属团队的命名空间
用户有两条访问路径，都经AWS IAM Identity Center Portal认证，Identity Center再与外部身份提供方联合。第一条是CLI路径：用户执行aws sso login，获得所属团队权限集的临时凭证，再用kubectl直接向EKS集群提交任务。第二条是从Identity Center Portal直接选择SageMaker Studio应用，登录团队专属的SageMaker AI域。
在EKS边界，访问条目（access entries）把IAM角色映射为Kubernetes权限。文中示例为两个团队的Studio执行角色（TeamA-role、TeamB-role）配置访问条目，同时也必须为Identity Center提供的CLI/控制台角色（TeamA-permissionset-role、TeamB-permissionset-role）配置访问条目，才能授权经kubectl到达的请求。所有访问条目关联托管或自定义的RBAC策略，并限定到该团队的指定命名空间。
结果是，不论访问来自Studio还是CLI，用户只能操作自己命名空间内的资源。集群内每个命名空间可运行HyperPod Spaces（交互式开发环境）、HyperPod PyTorch作业（分布式训练）和HyperPod Inference端点（模型服务）。
认证与授权的分工：Identity Center、IAM角色与权限集
AWS给出的理由集中在一点：让团队归属在一个地方管理，并自动传播到下游授权决策。示例把三个组（TeamA、TeamB、Admin）建在Entra ID中，开启Entra ID与IAM Identity Center之间的SCIM同步，实现用户和组的自动开通与停用；同时配置SAML 2.0联邦，Identity Center作为服务提供方信任Entra ID断言。新用户加入TeamA组后会自动同步到Identity Center并取得相应访问权限。
每个团队需要一个专用IAM角色作为SageMaker AI域的执行角色，典型策略涵盖SageMaker AI（管理HyperPod集群、MLflow跟踪服务器等）、限定到团队桶前缀的S3读写、CloudWatch日志与指标，以及EKS的eks:AccessKubernetesApi和eks:MutateViaKubernetesApi权限，后者供Studio GUI代表用户发起Kubernetes API调用。角色信任策略须包含sagemaker.amazonaws.com；如果同一执行角色还要用作集群内工作负载的EKS Pod Identity关联，信任策略还须包含pods.eks.amazonaws.com。
CLI访问走独立权限集，与Studio执行角色分开定义，便于管理员按命令行实际所需单独限定权限。团队成员通过aws configure sso在~/.aws/config中建立共享的sso-session块和每团队一个命名profile，再用aws sso login --profile取得限期凭证。
存储分层与示例身份提供方的可替换范围
集群下方有两层存储。第一层是POSIX兼容文件系统，可选Amazon FSx for Lustre或Amazon FSx for OpenZFS，按团队共享目录（/fsx/TeamA、/fsx/TeamB）和按用户主目录（/home/User1、/home/User2）组织。第二层是按团队或共享的Amazon S3桶，由团队的IAM执行角色管辖。
认证部分以Microsoft Entra ID为示例身份提供方，但AWS称同一模式适用于多数标准SAML 2.0提供方。AWS还提到，Amazon Managed Grafana使用Identity Center作为员工用户认证机制，因此当团队还需要访问可观测性仪表板时会自然沿用这一认证层。
每团队一个SageMaker AI域在文中被描述为AWS已广泛记录的做法，域可配置Identity Center认证、默认执行角色，并可在用户配置文件级别覆盖；管理员还能隐藏与团队工作流无关的导航项，呈现聚焦HyperPod的界面。