Amazon's New AI Tool Lets Teams Share Supercomputers Without Fighting

Multiple teams within the same company increasingly need shared access to expensive GPU clusters for their generative AI operations, while keeping isolation boundaries, resource fairness, and operational independence intact. Think of a data science team training large language models, a computer vision group running inference workloads, and a research team experimenting with new model architectures — all potentially needing the same cluster. Without a well-designed multi-tenant architecture, organizations face uncontrolled resource consumption, weak isolation between teams, an inability to attribute shared GPU costs to the teams that incur them, and administrative overhead that slows down innovation.

The article presents a reference architecture for building that multi-tenant environment on Amazon SageMaker HyperPod with Amazon EKS. Its building blocks: AWS IAM Identity Center for centralized authentication, per-team SageMaker AI domains for a tailored user experience, Kubernetes namespaces for workload isolation, HyperPod Task Governance for fair resource allocation, and namespace-level cost allocation for per-team spend visibility and chargeback.

In the example, two teams share a single HyperPod EKS cluster, each operating in its own isolated namespace. Users reach the system two ways. One is CLI access: they authenticate with aws sso login, are redirected to the Identity Center portal, and obtain temporary credentials from their team's permission set to submit tasks directly to the cluster with kubectl. The other is through the Identity Center portal, where users select the SageMaker Studio application to sign in to their team-specific SageMaker AI domain.

Identity Center federates with an external identity provider such as Microsoft Entra ID, and automatically provisions an IAM role for each team's permission set — the role that serves as the IAM principal when users authenticate through aws sso login. Each team's SageMaker AI domain comes with its own execution role and a dedicated Studio GUI.

At the EKS boundary, access entries map IAM roles to Kubernetes permissions, associated with managed or custom role-based access control policies and scoped to the team's designated namespace. The result: whether access comes from Studio or the CLI, users can only interact with resources in their own namespace.