Amazon SageMaker HyperPod’s reference architecture combines four elements to share one EKS cluster across teams: AWS IAM Identity Center for authentication, per-team SageMaker Domains and Kubernetes namespaces for isolation, HyperPod Task Governance for fairness, and namespace-level cost allocation for chargeback. The central design choice is to make team boundaries matter across access, compute allocation, and usage reporting. AWS’s architecture overview describes how these elements fit together.
For cloud architects, the useful question is how those controls connect. Authentication establishes who a user is; isolation defines the team environment; governance addresses compute quotas; reporting connects consumption to the team responsible for it. Treating each as an explicit design concern provides a clearer basis for reviewing a shared cluster than treating authentication alone as sufficient.
How the architecture divides responsibility
AWS describes HyperPod as supporting clusters orchestrated by Amazon Elastic Kubernetes Service (Amazon EKS) or Slurm, with node health monitoring, fault recovery, and cluster lifecycle management. The sharing pattern examined here uses EKS. Its team-level controls should be assessed within that scope rather than assumed to describe an equivalent Slurm deployment.
| Concern | Component in the reference architecture | Role |
|---|---|---|
| Workforce authentication | AWS IAM Identity Center | Centralized authentication and identity-provider federation |
| Team isolation | Per-team SageMaker Domains and Kubernetes namespaces | Separate team environments within the shared architecture |
| Compute fairness | HyperPod Task Governance | Compute quota enforcement |
| Chargeback | Namespace-level usage reporting | Consumption visibility and cost attribution |
The architectural implication is that operating a shared cluster requires decisions about both access and resource entitlement. A team’s ability to enter its environment and its entitlement to compute are separate concerns, even when both belong to the same overall sharing policy.
Connect workforce identities to team environments
In the reference design, Identity Center federates with an external identity provider to manage user identities and group memberships. AWS also describes SCIM-based automatic provisioning and de-provisioning of users and groups. Its example adds a user to the TeamA group in Entra ID, synchronizes that user to Identity Center, and grants appropriate access without manual intervention. AWS’s detailed architecture discussion supplies this identity flow.
That example makes group membership a concrete part of access administration. For an implementation review, the corresponding question is whether the intended team membership is reflected consistently in the team’s SageMaker Domain and Kubernetes namespace. This is an architectural review criterion, not a claim that identity synchronization alone configures every isolation control.
AWS identifies per-team Domains and namespaces as the isolation components. The evidence does not specify a complete set of permissions or network policies, so this description should not be read as a complete security configuration. The supported pattern establishes the boundaries to design around; the supplied material does not establish every enforcement detail.
Identity Center also serves as the workforce authentication mechanism for Amazon Managed Grafana in AWS’s discussion. That provides an identity connection for users who need observability dashboards, alongside access to their workload environment.
Make fairness explicit through compute quotas
HyperPod Task Governance provides the fairness component of the reference architecture. AWS’s job-running documentation recommends configuring it to enforce compute quotas and enable granular cost attribution. This gives architects a concrete control to examine when translating team resource expectations into cluster operation.
The supplied guidance also distinguishes allocated resource consumption from borrowed consumption in usage reports. That distinction matters when reviewing a shared pool: a consumption total alone does not convey whether a team used its allocation or borrowed resources. Reporting both categories gives administrators a more useful view of how the sharing policy is being used.
The evidence does not specify a fairness algorithm, borrowing limits, preemption behavior, or workload waiting-time guarantees. Those details remain implementation questions. The documented quota and reporting capabilities support a governance design, but they do not establish a particular scheduling outcome under contention.
Keep workload submission tied to the shared model
Scientists can use the SageMaker HyperPod CLI and native kubectl commands to discover available clusters, submit training jobs as Pods, and manage workloads. The HyperPod CLI supports submission through a training job schema file, along with job listing, description, cancellation, and execution. These are documented workload paths in AWS’s EKS job-running guide.
The same guide says scientists can use Kubeflow Training Operator according to compute quotas managed by HyperPod, and SageMaker AI-managed MLflow for experiments and training runs. These tools occupy different parts of the workflow: workload execution operates within compute quotas, while experiment tracking manages the record of training activity.
For platform teams, the relevant review is whether the selected submission workflow preserves the team context needed for governance and accounting. AWS explicitly documents namespace-based utilization tracking for jobs run through the HyperPod CLI or kubectl; the evidence does not establish identical tracking behavior for every possible submission path.
Install reporting before relying on chargeback
HyperPod can track GPU and CPU hours across namespaces when jobs run through those documented paths. Usage reports expose allocated versus borrowed consumption, team utilization for auditing for up to 180 days, and cost attribution aligned with Task Governance policies. AWS’s release notes separately record usage reporting for EKS-orchestrated clusters as supporting allocation across teams, projects, or departments.
There is an explicit prerequisite: the usage report infrastructure must be installed. Reporting should therefore be treated as a deployment requirement when chargeback is part of the operating model. Simply adopting the reference architecture does not remove that installation step.
The documented metrics establish a basis for attribution. They do not supply a monetary pricing formula or a policy for distributing every shared cost. An organization still needs to decide how it will translate the reported consumption into its own chargeback rules; the supplied evidence does not quantify savings from doing so.
Separate capacity provisioning from team allocation
A related capability in AWS’s HyperPod release notes is flexible instance groups. Through InstanceRequirements, a group can specify up to 20 instance types. HyperPod attempts the highest-priority type first and falls back to lower-priority types when capacity is unavailable.
That provisioning priority concerns which instance type HyperPod attempts to obtain. Task Governance concerns team compute quotas. Keeping these decisions distinct helps architects assess capacity availability and team allocation without assuming one mechanism resolves both.
The documented architecture offers a coherent framework for sharing: connect workforce identities, establish team boundaries, enforce compute quotas, and install reporting that attributes usage to those teams. All supporting sources here are AWS publications, and they provide no independent benchmark of isolation, scheduling fairness, or utilization gains. The practical value is the architecture and its documented prerequisites; deployment-specific enforcement and outcomes still require validation.
