AWS outlines four-layer governance model for SageMaker HyperPod

AWS’s new guidance addresses how to administer Amazon SageMaker HyperPod when multiple machine-learning teams share clusters. HyperPod provides large pools of accelerated compute for training and fine-tuning models. Teams can connect an existing cluster to an Amazon SageMaker Unified Studio project, where members can launch workloads, review cluster and task information, or open a JupyterLab workflow. Cluster administration itself remains in Amazon SageMaker AI interfaces and APIs.

The post divides governance into organization, project, cluster, and workload layers. It cautions that a project is a collaboration boundary, not a strong runtime security boundary: connecting a cluster to a project does not replace IAM, EKS, or Slurm controls. AWS recommends managing access at each boundary rather than relying on project membership alone.

For capacity, AWS advises placing the HyperPod cluster, scheduler, and scarce accelerator resources under one designated capacity account, with approved cross-account access for consumers. For EKS clusters, its recommendations include tenant-specific namespaces, RBAC, service accounts and EKS Pod Identity roles, default-deny network policies, and tenant-specific storage and KMS permissions. For Slurm clusters, it points to hierarchical accounts and associations, QoS, priority and fair-share policies, and partitions.

The post also recommends IAM roles and resource policies for access to data services and related resources. It extends AWS’s earlier HyperPod task-governance guidance: the February 2025 post focused on compute allocation, task prioritization, idle-compute allocation, and observability, while the new guidance broadens the frame to responsibilities and controls across organizational, project, cluster, and workload boundaries.