Amazon SageMaker HyperPod: GPU-Cluster sicher und fair ueber Teams teilen
Eine Referenzarchitektur zeigt, wie sich ein einzelner Amazon SageMaker HyperPod EKS Cluster sicher auf mehrere Teams aufteilen laesst. Dazu kommen AWS IAM Identity Center fuer die Authentifizierung, eigene SageMaker Domains und Kubernetes Namespaces zur Isolation sowie HyperPod Task Governance fuer faire Ressourcenverteilung und Kostentransparenz.
Immer mehr Teams innerhalb desselben Unternehmens benötigen gemeinsam genutzten Zugriff auf teure GPU-Cluster für ihre Generative-AI-Operationen, während gleichzeitig Isolationsgrenzen, faire Ressourcennutzung und operationale Unabhängigkeit gewahrt bleiben müssen. Man denke etwa an ein Data-Science-Team, das große Sprachmodelle trainiert, eine Computer-Vision-Gruppe, die Inferenz-Workloads ausführt, und ein Forschungsteam, das mit neuen Modellarchitekturen experimentiert. Alle benötigen möglicherweise Zugriff auf denselben Cluster.
Ohne eine gut durchdachte Multi-Tenant-Architektur (Multi-Team-Architektur) stehen Organisationen vor unkontrolliertem Ressourcenverbrauch, schwacher Isolation zwischen den Teams, der Unfähigkeit, gemeinsame GPU-Kosten den verursachenden Teams zuzuordnen, sowie administrativem Mehraufwand, der Innovationen ausbremst.
Amazon SageMaker HyperPod ist ein speziell entwickelter KI-Service, der die Verwaltung großer Compute-Cluster für Generative-AI-Workloads vereinfacht. Er stellt widerstandsfähige, optimierte Cluster bereit, die von Amazon Elastic Kubernetes Service (Amazon EKS) oder Slurm orchestriert werden, sodass Organisationen verteiltes Training, interaktive Entwicklung und Modulinferenz im großen Maßstab betreiben können. Gleichzeitig übernimmt der Service automatisch die Überwachung der Node-Integrität, die Fehlerbehebung und das Lifecycle-Management des Clusters.
In diesem Beitrag stellen wir eine Referenzarchitektur für den Aufbau einer Multi-Tenant-Umgebung auf Amazon SageMaker HyperPod mit EKS vor. Diese Architektur nutzt AWS IAM Identity Center für zentralisierte Authentifizierung, teameigene SageMaker-AI-Domains für ein angepasstes Nutzererlebnis, Kubernetes-Namespaces für die Isolation der Workloads, HyperPod Task Governance für eine faire Ressourcenzuteilung sowie Namespaces-Kostenzuordnung für Sichtbarkeit der Ausgaben und Chargeback auf Teamebene. Am Ende dieses Beitrags haben Sie einen klaren Bauplan dafür, wie mehrere Teams einen einzigen HyperPod-EKS-Cluster effizient gemeinsam nutzen können.
Das folgende Diagramm veranschaulicht die High-Level-Architektur einer Multi-Tenant-HyperPod-EKS-Bereitstellung. In diesem Beispiel teilen sich zwei Teams (Team A und Team B) einen einzigen HyperPod-EKS-Cluster, wobei jedes Team innerhalb seines eigenen isolierten Namespace arbeitet.
Abbildung 1: High-Level-Multi-Tenant-Architektur für zwei Teams, die sich einen HyperPod-EKS-Cluster teilen
Die Architektur ist als geschichteter Ablauf von links nach rechts aufgebaut, der die Nutzeridentität über Autorisierungssteuerungen mit den isolierten Workload-Namespaces auf dem Cluster verbindet.
Ganz links interagieren einzelne Nutzer aus jedem Team (Nutzer 1 aus Team A, Nutzer 2 aus Team B) über zwei Pfade mit dem System. Beide Pfade authentifizieren sich über das AWS-IAM-Identity-Center-Portal, das mit einem externen Identity Provider (etwa Microsoft Entra ID) unten links föderiert.
Der erste Pfad führt über den CLI-Zugriff. Nutzer authentifizieren sich mit aws sso login, was sie zum Identity-Center-Portal weiterleitet, und erhalten anschließend temporäre Anmeldedaten aus dem Permission Set ihres Teams, um Aufgaben direkt mit kubectl an den EKS-Cluster zu übermitteln. Im Diagramm fließt der rosa Pfeil vom CLI-Terminal oben quer direkt in den HyperPod-EKS-Cluster.
Der zweite Pfad führt direkt über das Identity-Center-Portal, wo Nutzer die SageMaker-Studio-Anwendung auswählen, um sich bei ihrer team-spezifischen SageMaker-AI-Domain anzumelden.
Jedes Team verfügt über ein entsprechendes Permission Set (TeamA permission set, TeamB permission set), das die für CLI-Workflows benötigten AWS-Identity-and-Access-Management-(IAM)-Richtlinien enthält. Identity Center stellt automatisch eine IAM-Rolle für jedes Permission Set bereit, im Diagramm dargestellt als TeamA-permissionset-role und TeamB-permissionset-role (beschriftet mit „CLI/Console role“). Diese Rolle dient als IAM-Principal, wenn Nutzer sich über aws sso login authentifizieren.
Vom Identity-Center-Portal aus werden Nutzer zu ihrer team-spezifischen SageMaker-AI-Domain geleitet. Jede Domain (SageMaker AI domain Team A und SageMaker AI domain Team B) bietet eine eigene Amazon-SageMaker-Studio-GUI und ist mit einer team-spezifischen Ausführungsrolle konfiguriert (TeamA-role beziehungsweise TeamB-role). Diese Domains dienen als primäre Arbeitsbereichsoberfläche, sodass Nutzer Aufgaben aus der GUI heraus übermitteln können (dargestellt durch die rosa Pfeile, die in Richtung EKS zeigen).
An der EKS-Grenze mappen Access Entries IAM-Rollen auf Kubernetes-Berechtigungen. Das Diagramm zeigt Access Entries für TeamA-role und TeamB-role (die Studio-Ausführungsrollen), die Anfragen autorisieren, die aus der SageMaker-Studio-GUI stammen. Für die von Identity Center bereitgestellten CLI/Console-Rollen (TeamA-permissionset-role und TeamB-permissionset-role) müssen ebenfalls Access Entries konfiguriert werden, um über kubectl eingehende Anfragen zu autorisieren.
Alle Access Entries sind mit verwalteten oder benutzerdefinierten rollenbasierten Zugriffssteuerungsrichtlinien (RBAC) verknüpft (dargestellt durch das Schlüsselsymbol) und auf den jeweiligen Team-Namespace beschränkt. Dadurch können Nutzer unabhängig davon, ob der Zugriff aus Studio oder der CLI erfolgt, nur mit Ressourcen in ihrem eigenen Namespace interagieren.
Der Cluster selbst ist mit zwei übergreifenden Plattformebenen oben dargestellt: HyperPod Observability (für Monitoring und Dashboards) und HyperPod Task Governance (für Compute-Quotenmanagement und Scheduling-Prioritäten). Unterhalb dieser Ebenen ist der Cluster in Namespace A (Team A) und Namespace B (Team B) unterteilt. Innerhalb jedes Namespaces können die Teams ihre eigenen HyperPod Spaces (interaktive Entwicklungsumgebungen), HyperPod-PyTorch-Jobs (verteilte Trainings-Workloads) und HyperPod-Inference-Endpunkte (Modellbereitstellung) betreiben.
Unterhalb des Clusters umfasst die Architektur zwei Speicherebenen. Die erste ist ein POSIX-kompatibles Dateisystem (Amazon FSx for Lustre oder Amazon FSx for OpenZFS), das in team-spezifische gemeinsame Verzeichnisse (/fsx/TeamA, /fsx/TeamB) und nutzerspezifische Home-Verzeichnisse (/home/User1, /home/User2) gegliedert ist. Die zweite sind team-spezifische oder gemeinsame Amazon-Simple-Storage-Service-(Amazon S3)-Buckets für Objektspeicher, gesteuert über die IAM-Ausführungsrolle des Teams.
Diese Architektur isoliert jedes Team von der Authentifizierung über die Autorisierung bis hin zur Workload-Ausführung, während die teure GPU-Infrastruktur effizient gemeinsam genutzt wird.
Das Fundament jedes Multi-Tenant-Systems ist eine robuste Authentifizierung: die Überprüfung, wer die Nutzer sind, bevor sie mit einer Ressource interagieren. In dieser Architektur dient AWS IAM Identity Center als zentralisierte Authentifizierungsebene und föderiert mit einem externen Identity Provider, um Nutzeridentitäten und Gruppenmitgliedschaften zu verwalten.
AWS IAM Identity Center (Nachfolger von AWS Single Sign-On) bietet eine zentrale Stelle zur Verwaltung von workforce-Identitäten über AWS-Konten und Anwendungen hinweg. Für eine Multi-Tenant-HyperPod-Bereitstellung bietet es mehrere zentrale Funktionen:
In dieser Referenzarchitektur verwenden wir Microsoft Entra ID als externen Identity Provider, wobei dasselbe Muster auf die meisten standardmäßigen SAML-2.0-Provider (Security Assertion Markup Language) anwendbar ist.
Mit dieser Konfiguration verwalten Sie Team-Mitgliedschaften (die alle nachgelagerten Autorisierungsentscheidungen steuern) in Ihrem bestehenden Unternehmensverzeichnis, und diese werden automatisch an AWS weitergegeben.
Das folgende Bild zeigt ein Beispiel dafür, wie Organisationsteams in Microsoft Entra ID abgebildet werden können, mit eigenen Gruppen für TeamA, TeamB und Admin.
Abbildung 2: Organisationsteams als Gruppen in Microsoft Entra ID
Das anschließende Bild zeigt die entsprechenden Gruppen in AWS IAM Identity Center, die automatisch über die SCIM-Synchronisierung aus Entra ID bereitgestellt wurden.
Abbildung 3: Entsprechende Gruppen in AWS IAM Identity Center, bereitgestellt über SCIM
Weitere Informationen: Connect an external identity provider · SCIM profile and SAML 2.0 implementation
Nachdem die Authentifizierung etabliert ist, folgt als nächste Ebene die Autorisierung: die Steuerung, welche Aktionen jedes Team über AWS-Services hinweg und auf dem Kubernetes-Cluster ausführen darf. Die Autorisierung in dieser Architektur erfolgt auf zwei Ebenen: IAM für den Service-Zugriff und Kubernetes RBAC für den Zugriff auf Cluster-Ebene.
Jedes Team benötigt eine dedizierte IAM-Rolle, die die Berechtigungen auf AWS-Ebene für seine KI- und Machine-Learning-(ML)-Workflows kapselt. Diese Rollen dienen als Ausführungsrolle der SageMaker-AI-Domain und legen fest, auf welche AWS-Services das Team zugreifen kann.
Eine typische Team-IAM-Rolle sollte Richtlinien enthalten, die den Zugriff auf Folgendes gewähren:
Die Trust-Policy jeder IAM-Rolle muss sagemaker.amazonaws.com als vertrauenswürdigen Principal enthalten, damit SageMaker AI die Rolle im Namen der Nutzer übernehmen kann, wenn diese über Studio arbeiten. Soll dieselbe Ausführungsrolle darüber hinaus als EKS-Pod-Identity-Assoziation für In-Cluster-Workloads wiederverwendet werden (wie später im Abschnitt zum Amazon-S3-Speicher erläutert), muss die Trust-Policy ebenfalls pods.eks.amazonaws.com als vertrauenswürdigen Principal enthalten. Der CLI-Zugriff über Identity Center verwendet ein separates Permission Set mit eigenen Richtlinien (siehe Abschnitt „AWS account access through Identity Center“), sodass CLI-Berechtigungen unabhängig abgegrenzt werden können.
Weitere Informationen: How to use SageMaker AI execution roles
Über SageMaker Studio hinaus benötigen Teams häufig direkten AWS-Kontozugriff für CLI-Operationen, etwa zum Ausführen von kubectl-Befehlen, zum Skripten von Workflows oder zum programmatischen Zugriff auf Ressourcen. Identity-Center-Permission-Sets bieten diese Möglichkeit.
Für die Admin-Gruppe weisen Sie eine Berechtigungsgruppe mit administrativem Zugriff zu, wie es die Richtlinien Ihres Unternehmens erfordern, und gewähren Sie damit den notwendigen Konto-Zugriff für das Clustermanagement und administrative Vorgänge.
Für Team A und Team B erstellen Sie Berechtigungsgruppen mit Inline- oder verwalteten Richtlinien, die die für CLI-Workflows benötigten Berechtigungen direkt gewähren. Eine typische Team-Berechtigungsgruppe umfasst Berechtigungen für eks:AccessKubernetesApi (um Kubernetes-Ressourcen aus der AWS Console betrachten zu können), einen eingegrenzten S3-Zugriff auf die Daten des Teams sowie CloudWatch-Lesezugriff für das Monitoring. Diese Richtlinien werden unabhängig von der Studio-Ausführungsrolle definiert, sodass Administratoren die CLI-Berechtigungen gezielt auf die Vorgänge zuschneiden können, die Teams über die Befehlszeile ausführen.
Nutzer beziehen temporäre Anmeldeinformationen über die AWS Command Line Interface (AWS CLI) mittels aws sso login, mit denen sie anschließend kubectl konfigurieren können, um direkt mit dem EKS-Cluster zu interagieren.
Das folgende Bild zeigt die teambezogenen Berechtigungsgruppen in AWS IAM Identity Center, die einen eingegrenzten AWS-Konto-Zugriff für CLI-Workflows wie das Ausführen von kubectl und aws sso login gegen den EKS-Cluster bereitstellen.
Abbildung 4: Teambezogene Berechtigungsgruppen in AWS IAM Identity Center für CLI-Workflows
Mehr erfahren: Manage AWS accounts with permission sets
Teammitglieder konfigurieren die AWS CLI für die Authentifizierung über Identity Center, indem sie aws configure sso ausführen. Dadurch werden Profile in ~/.aws/config erstellt, die auf die entsprechende Identity Center-Sitzung und Berechtigungsgruppe verweisen. Jedes Teammitglied verwendet sein teambezogenes Profil bei der Interaktion mit dem Cluster über die Befehlszeile, wodurch die Autorisierungsgrenzen erhalten bleiben, unabhängig davon, ob der Zugriff aus Studio oder von einem lokalen Terminal erfolgt.
Die resultierende Konfiguration definiert einen gemeinsamen sso-session-Block für das Identity Center-Portal und ein benanntes Profil pro Team, wobei jedes Profil auf die Berechtigungsgruppe des jeweiligen Teams verweist. Die Teammitglieder führen dann aws sso login --profile <team> aus, um temporäre Anmeldeinformationen zu erhalten, die auf ihre Berechtigungsgruppe eingegrenzt sind:
[sso-session my-sso] sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start sso_region = us-west-2 sso_registration_scopes = sso:account:access [default] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = OpsAdmin region = us-west-2 [profile team-a] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = TeamA-permission-set region = us-west-2 [profile team-b] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = TeamB-permission-set region = us-west-2 Mehr erfahren: Configuring IAM Identity Center authentication with the AWS CLI
SageMaker AI Domains bilden die Workspace-Grenze für jedes Team und bieten ein zugeschnittenes Nutzererlebnis, vorkonfigurierte Ausführungsrollen sowie eine integrierte Anbindung an die Identity Center-Authentifizierung.
Die Verwendung eines SageMaker AI Domain pro Team ist ein etabliertes Muster zur Organisation von Umgebungen mit mehreren Teams. Dieser Ansatz bietet mehrere Vorteile:
Mehr erfahren: SageMaker AI domain entities and statuses · Multiple domains overview
Erstellen Sie ein SageMaker AI Domain pro Team mit Identity Center-Authentifizierung. In unserem Beispiel erstellen wir TeamA-domain und TeamB-domain. Jede Domain wird wie folgt konfiguriert:
Das folgende Bild zeigt die SageMaker AI Konsole mit einer Domain pro Team (TeamA-domain und TeamB-domain), von denen jede eine isolierte Workspace-Grenze bereitstellt.
Abbildung 5: Ein SageMaker Domain pro Team in der SageMaker-Konsole
Das folgende Bild zeigt anschließend die Details von TeamA-domain, einschließlich der zugewiesenen Identity Center-Gruppen.
Abbildung 6: TeamA-domain-Konfiguration mit den zugewiesenen Identity Center-Gruppen
Der HyperPod EKS Cluster ist der Ort, an dem Workloads ausgeführt werden. Multi-Tenancy auf Cluster-Ebene wird durch Kubernetes-Namespaces für die Isolation und EKS Access Entries für die Autorisierung erreicht.
Erstellen Sie einen dedizierten Kubernetes-Namespace für jedes Team, zum Beispiel hyperpod-ns-team-a und hyperpod-ns-team-b. Namespaces bieten eine logische Grenze innerhalb des Clusters und isolieren die Workloads der einzelnen Teams (Spaces, Trainings-Jobs, Inferenz-Endpunkte) voneinander.
Hinweis: Namespaces sind eine Isolationsgrenze, keine harte Sicherheitsgrenze. Diese Architektur zielt auf Multi-Team-Umgebungen innerhalb einer einzelnen Organisation ab: Teams, die sich einen Cluster unter einer gemeinsamen administrativen Domäne und einem Grundmaß an gegenseitigem Vertrauen teilen. Sie ist nicht für die Isolation mehrerer Kunden untereinander ausgelegt, die sich gegenseitig nicht vertrauen.
Namespaces, RBAC und Quoten verhindern versehentliche Beeinträchtigungen (etwa wenn Teams sich gegenseitig Ressourcen überschreiben oder ihre Rechenkontingente überschreiten), stellen jedoch keine Verteidigung gegen einen entschlossenen bösartigen Tenant dar: Pods in Namespaces teilen sich dieselben Knoten und denselben Kernel, und Cluster-weite Ressourcen (Knoten, PersistentVolumes, CRDs, einige Operator-Komponenten) liegen außerhalb jedes Namespaces.
Für nicht vertrauenswürdige Tenants oder strenge regulatorische Isolation sollten stärkere Grenzen wie separate Cluster oder Konten, dedizierte Node-Pools und Runtime-Sandboxing verwendet werden. Für das hier betrachtete Multi-Team-Szenario bieten die Namespace-Isolation in Kombination mit RBAC, Task-Governance-Quoten und den weiter unten beschriebenen POSIX-Identitätskontrollen einen angemessenen Ausgleich zwischen Trennung und operativer Einfachheit.
Namespaces können manuell mit kubectl create namespace oder automatisch über HyperPod Task Governance bereitgestellt werden, das Namespaces als Teil seiner Quoten- und Scheduling-Konfiguration verwaltet.
Das folgende Bild zeigt die Cluster-Namespaces (verwaltet mit HyperPod Task Governance), mit einem dedizierten Namespace pro Team (hyperpod-ns-team-a und hyperpod-ns-team-b), die eine Workload-Isolation bereitstellen.
Abbildung 7: Dedizierter Kubernetes-Namespace pro Team für die Workload-Isolation
Namespaces beschränken den Netzwerkverkehr nicht. Standardmäßig ist Kubernetes-Netzwerk flat: Jeder Pod kann jeden anderen Pod über alle Namespaces hinweg erreichen. Folglich kann ein Pod in hyperpod-ns-team-a eine Verbindung zu einem Pod in hyperpod-ns-team-b öffnen, sofern Sie keine Kontrollen hinzufügen. Um die Erreichbarkeit von Pod zu Pod entlang der Teamgrenzen einzuschränken, verwenden Sie Kubernetes NetworkPolicy-Ressourcen.
Das empfohlene Muster ist default-deny pro Namespace: Beginnen Sie damit, allen Ingress (und optional Egress) zu verweigern, und erlauben Sie dann explizit den Verkehr, den jedes Team benötigt, typischerweise die Kommunikation innerhalb des Namespace sowie erforderlichen Egress wie DNS, Storage-Endpunkte und AWS APIs. Das folgende Beispiel verweigert allen Ingress im Namespace eines Teams und erlaubt anschließend nur Verkehr von Pods innerhalb desselben Namespaces:
# 1. Default-deny: Allen Ingress im Namespace des Teams verweigern. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: hyperpod-ns-team-a spec: podSelector: {} # gilt für alle Pods im Namespace policyTypes: - Ingress --- # 2. Ingress nur von Pods innerhalb desselben Namespaces erlauben. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-same-namespace namespace: hyperpod-ns-team-a spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: {} # jeder Pod in diesem Namespace Die Durchsetzung von NetworkPolicies hängt von einem Container Network Interface (CNI) ab, das diese unterstützt.
Auf EKS können Sie die Unterstützung von Netzwerkrichtlinien im Amazon Virtual Private Cloud (Amazon VPC) CNI aktivieren.
Wie bei Namespaces gelten auch für NetworkPolicies: Sie verringern die versehentliche teamübergreifende Erreichbarkeit und verkleinern die Angriffsfläche, sind aber für sich genommen keine adversariale Sicherheitsgrenze auf gemeinsam genutzten Knoten. Für eine stärkere Trennung sollten Sie, wie bereits erwähnt, dedizierte Node-Pools pro Team oder separate Cluster in Betracht ziehen.
Mehr erfahren: Kubernetes network policies · Amazon VPC CNI network policy
EKS Access Entries verbinden IAM-Principals mit Kubernetes-RBAC-Berechtigungen. Erstellen Sie für jedes Team zwei Access Entries:
Beide Entries werden mit verwalteten oder benutzerdefinierten Kubernetes-Richtlinien auf den Namespace des Teams eingegrenzt. Beispielsweise gewähren beide Entries von Team A Berechtigungen nur innerhalb von hyperpod-ns-team-a. Die beiden Entries können bei Bedarf unterschiedliche RBAC-Richtlinien tragen. So könnte der CLI-Entry beispielsweise den Schreibzugriff auf bestimmte Ressourcentypen einschränken, während der Studio-Entry vollen Zugriff erlaubt.
Durch diese Eingrenzung können Nutzer, unabhängig davon, ob der Zugriff aus Studio oder aus der CLI erfolgt, nur mit Ressourcen in ihrem eigenen Namespace interagieren. Der Versuch, Ressourcen im Namespace eines anderen Teams aufzulisten oder zu ändern, führt zu einem Kubernetes Forbidden-Fehler.
Für fortgeschrittenere Szenarien können Sie Kubernetes-Gruppen im Access Entry verwenden, um Nutzer benutzerdefinierten ClusterRoles oder Roles zuzuordnen, die feingranulare Berechtigungen über die Standard-Managed-Policies hinaus bereitstellen.
Das folgende Bild zeigt einen EKS Access Entry für die Rolle von Team B, eingegrenzt auf den Namespace hyperpod-ns-team-b, sodass seine Berechtigungen nur innerhalb des Namespace von Team B gelten.
Abbildung 8: Auf den Namespace von Team B eingegrenzter EKS Access Entry
Mehr erfahren: Grant IAM users access to Kubernetes with EKS access entries
Wenn Task Governance auf dem Cluster aktiviert ist, stellt sie eine zusätzliche Ebene des Ressourcenmanagements bereit:
Konfigurieren Sie Task Governance mit angemessenen Quoten und Prioritäten pro Team-Namespace, um einen Ausgleich zwischen garantierten Mindestzuweisungen und Burst-Kapazität für workload lastige Spitzen zu finden.
Das folgende Bild zeigt die Task Governance Compute-Zuweisungen für die beiden Teams, wobei jedem Team-Namespace ein eigenes Kontingent an Cluster-Compute-Kapazität zugewiesen ist.
Abbildung 9: Task Governance Compute-Zuweisungen pro Team-Namespace
Mehr erfahren: SageMaker HyperPod task governance
Storage ist eine zentrale Komponente von KI- und ML-Umgebungen (künstliche Intelligenz und Machine Learning), die sich Teams teilen. Teams benötigen leistungsstarke Dateisysteme für Trainingsdaten, Checkpoints und Modellartefakte und müssen gleichzeitig geeignete Zugriffsgrenzen zwischen den Teams aufrechterhalten.
Für Workloads, die ein gemeinsames, leistungsstarkes POSIX-Dateisystem erfordern (häufig bei verteiltem Training, bei dem mehrere Knoten denselben Datensatz lesen oder Checkpoints schreiben), bieten sich die folgenden Optionen an:
Das Storage-Layout folgt in der Regel dieser Struktur:
Das POSIX-Berechtigungsmodell dieser Dateisysteme basiert auf UIDs, GIDs und ergänzenden Gruppen, um Zugriffsgrenzen durchzusetzen. Diese POSIX-Identitäten sollten dann an den Pod Security Context weitergegeben werden, wenn ein Benutzer einen HyperPod Space startet oder einen Trainingsjob einreicht, damit der Dateisystemzugriff die konfigurierten Eigentums- und Berechtigungsregeln beachtet. Wir empfehlen die Verwendung eines Kubernetes Mutating Admission Webhook, um POSIX-Identitätsinformationen aus Ihrem Identity Store abzurufen. Wenn ein Workload eingereicht wird, sucht der Webhook die Identität zur Laufzeit und passt den Security Context des Pods entsprechend an.
# 1. Die Session-Identität des Aufrufers aus der Admission-Request extrahieren. # Auf EKS erscheinen Anfragen von angenommenen IAM-Rollen (einschließlich IAM Identity Center) # mit dem STS-Session-Namen in userInfo.extra["sessionName"]. Sein Format # hängt davon ab, wie die Session erstellt wurde (z. B. ein SSO-Kurzname, eine E-Mail # oder ein role-session-name); stimmen Sie Ihr Identitätsmapping auf diesen Wert ab. def extract_username(admission_request): extra = admission_request["userInfo"]["extra"]... return extra["sessionName"] # 2.
POSIX-Identität aus einer Mapping-Tabelle (z. B. DynamoDB) nachschlagen. def lookup_posix_identity(username): item = posix_table.get_item(Key={"username": username})["Item"]... return { "uid": int(item["uid"]), "gid": int(item["gid"]), "supplementalGroups": [int(g) for g in item["supplementalGroups"]], } # 3. Den Pod Security Context mit der aufgelösten POSIX-Identität patchen. def build_security_context_patch(pod, posix):... return [{ "op": "add", "path": "/spec/securityContext", "value": { "runAsUser": posix["uid"], "runAsGroup": posix["gid"], "fsGroup": posix["gid"], "supplementalGroups": posix["supplementalGroups"], }, }] Mehr erfahren: FSx for Lustre · FSx for OpenZFS · Amazon EFS
Beim Objektstorage wird der Zugriff auf S3-Buckets über die IAM-Ausführungsrolle des Teams gesteuert. Sie können Buckets pro Team erstellen oder einen gemeinsamen Bucket mit Präfixen pro Team verwenden und sich dabei auf IAM-Policies zur Durchsetzung der Isolation verlassen. Pods innerhalb des Clusters benötigen entsprechend konfigurierte Service Accounts mit IAM Roles for Service Accounts (IRSA) oder Pod Identity, um sich bei S3 zu authentifizieren. Der Einfachheit halber können Sie die auf der SageMaker AI Domain konfigurierte Ausführungsrolle einem Kubernetes Service Account im Namespace des Teams zuordnen, was einen konsistenten S3-Zugriff sowohl aus Studio als auch aus Cluster-Workloads ermöglicht.
Mehr erfahren: IAM roles for service accounts (IRSA) · EKS Pod Identity
HyperPod Spaces bieten interaktive Entwicklungsumgebungen (IDEs), die direkt auf Cluster-Knoten ausgeführt werden. Auf einem gemeinsam genutzten Cluster müssen Spaces korrekt auf den Namespace jedes Teams beschränkt und mit geeigneten Ressourcen-Templates konfiguriert sein.
Erstellen Sie namespace-spezifische Space-Templates für jedes Team. Diese Templates definieren die Ressourcenkonfigurationen (Instance-Typen, Storage-Volumes, Umgebungsvariablen), die Teammitgliedern beim Erstellen von Spaces zur Verfügung stehen. Durch die Beschränkung der Templates auf einen Namespace stellen Sie sicher, dass jedes Team nur Spaces innerhalb seiner zugewiesenen Grenzen starten kann.
Wenn HyperPod Task Governance aktiviert ist, sollten Templates die vom Governance-System erforderlichen Standard-Labels enthalten (z. B. Team-Identifikatoren und Priority-Labels). Der Cluster-Administrator konfiguriert diese Labels vor, sodass Teammitglieder sie beim Starten von Spaces nicht manuell angeben müssen.
Das folgende Beispiel zeigt ein JupyterLab-Space-Template, das auf Team A beschränkt ist. Die Teamspezifischen Teile sind metadata.namespace, das Task Governance Queue-Label unter baseLabels sowie die defaultVolumes, die das gemeinsame Dateisystem des Teams und das Home-Verzeichnis des Benutzers einbinden:
apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: jl-smd-custom namespace: hyperpod-ns-team-a # beschränkt das Template auf den Namespace von Team A spec: displayName: "JupyterLab (team-a)" description: "SageMaker Distribution" appType: jupyterlab baseLabels: - key: kueue.x-k8s.io/queue-name # Task Governance (Kueue) Local Queue für Team A value: hyperpod-ns-team-a-localqueue... # Container-Befehl, Standard-CPU/Speicher-Ressourcen, Security Context, Zugriffstyp usw.... defaultVolumes: - name: home-dir # Home-Verzeichnis pro Benutzer mountPath: /home persistentVolumeClaimName: fsx-openzfs-claim - name: shared-data # Gemeinsames Verzeichnis von Team A mountPath: /fsx persistentVolumeClaimName: fsx-lustre-claim... # Standardwerte und Limits für den primären (EBS) Storage... Persistent Volume Claims Erstellen Sie die entsprechenden Persistent Volume Claims (PVCs) im Namespace jedes Teams, die auf das gemeinsame Dateisystem verweisen. Diese PVCs binden das gemeinsame Verzeichnis des Teams und das Home-Verzeichnis des Benutzers in den Space ein und ermöglichen den Zugriff auf Trainingsdaten, Checkpoints und persönliche Arbeitsbereiche.
Berücksichtigen Sie die Anforderungen Ihrer Organisation in Bezug auf das Teilen von Spaces:
Mehr erfahren: Interactive development environments on Amazon SageMaker HyperPod EKS clusters
Während Teams mit dem Cluster vollständig über die CLI mit kubectl interagieren können, bietet SageMaker Studio einen grafischen Einstiegspunkt zum Cluster für Benutzer, die einen verwalteten, GUI-gesteuerten Workflow bevorzugen. In dieser Architektur greift jedes Team über seine eigene SageMaker AI Domain auf Studio zu (wie zuvor beschrieben), meldet sich mit denselben Identity Center-Zugangsdaten an und arbeitet innerhalb der Grenzen des Team-Namespace.
Das folgende Bild zeigt das IAM Identity Center Access Portal, das Benutzer nach der Anmeldung mit ihren Unternehmens-Zugangsdaten erreichen, und das Single Sign-On-Zugriff auf ihre zugewiesenen SageMaker Studio-Anwendungen und Amazon Managed Grafana-Anwendungen bietet.
Abbildung 10: IAM Identity Center Access Portal mit Single Sign-On zu zugewiesenen Anwendungen
Da Studio über die Domain-Ausführungsrolle des Teams und den entsprechenden EKS Access Entry arbeitet, sind alle Aktionen auf den Namespace des Teams beschränkt. Ein Benutzer, der aus Studio heraus einen Space oder einen Ray-Cluster startet, kann diese nur innerhalb der Grenzen seines eigenen Teams erstellen, konsistent mit dem Isolationsmodell, das auch für den CLI-Zugriff durchgesetzt wird.
Das folgende Bild zeigt, wie ein HyperPod Space über die SageMaker Studio UI erstellt wird, wobei ein Teammitglied ein namespace-spezifisches Space-Template auswählt, ohne Kubernetes-Manifeste zu schreiben oder Task Governance-Labels manuell anzugeben.
Abbildung 11: Erstellen eines HyperPod Space aus einem namespace-spezifischen Template in SageMaker Studio
Mehr erfahren: Interactive development environments on Amazon SageMaker HyperPod EKS clusters · Introducing new Ray capabilities on SageMaker HyperPod
Der HyperPod Training Operator ermöglicht es Teams, verteilte Trainingsjobs als Kubernetes Custom Resources einzureichen (z. B. HyperPodPyTorchJob). In der Multi-Tenant-Architektur sind Trainingsjobs namespace-spezifisch, was bedeutet, dass sie automatisch die Isolationsgrenzen des Teams erben.
Teams können Trainingsjobs über die CLI mit kubectl apply und dem entsprechenden Job-Manifest einreichen. Der Job läuft im Namespace des Teams, nutzt die Compute-Kontingente des Teams (sofern Task Governance aktiviert ist) und hat Zugriff auf die Storage-Volumes des Teams.
Wenn Task Governance aktiviert ist, unterliegen Trainingsjobs den zugewiesenen Kontingenten und Priority-Einstellungen des Teams. Hat ein Team seine garantierte Zuweisung verbraucht, können Jobs in die Warteschlange gestellt werden, bis Ressourcen verfügbar werden oder Workloads mit niedrigerer Priorität verdrängt werden.
Die beiden Elemente, die einen Job an ein Team binden, sind metadata.namespace (das den Job auf die Isolationsgrenze des Teams beschränkt) und die Task Governance-Labels. Task Governance basiert auf Kueue, daher wird der Job über kueue.x-k8s.io/queue-name an die Local Queue des Teams geleitet. Ihm wird über kueue.x-k8s.io/priority-class eine Scheduling-Priorität zugewiesen, deren Wert der Name einer im Cluster definierten WorkloadPriorityClass ist:
apiVersion: sagemaker.amazonaws.com/v1 kind: HyperPodPyTorchJob metadata: name: team-a-training-job namespace: hyperpod-ns-team-a # beschränkt den Job auf den Namespace von Team A labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue # Task Governance (Kueue) Local Queue kueue.x-k8s.io/priority-class: training-priority # Name einer WorkloadPriorityClass spec:... # replicaSpecs, Container-Image, Befehl, Ressourcen, Volumes usw.... Mehr erfahren: Using the HyperPod training operator
Der HyperPod Inference Operator ermöglicht es Teams, Modelle als Inference Endpoints direkt auf dem Cluster zu betreiben. Ähnlich wie Training Jobs sind Inference Endpoints namespace-scoped und unterliegen den RBAC-Richtlinien des Teams sowie den Task-Governance-Quotas.
Teams können Modelle über die CLI bereitstellen, indem sie in ihrem Namespace Custom Resources für Inference Endpoints anlegen. Die Endpoints sind pro Namespace isoliert, das heißt, Team A kann auf die Inference Endpoints von Team B nicht zugreifen oder diese beeinträchtigen.
Bei Produktions-Inference-Workloads, die hohe Verfügbarkeit erfordern, empfiehlt es sich, den Inference Endpoints eine höhere Scheduling-Priorität zuzuweisen als den Training Jobs, damit die Modelbereitstellung nicht durch Batch-Trainings-Workloads unterbrochen wird.
Wie bei Training Jobs wird der Inference Endpoint im metadata.namespace des Teams platziert und trägt die Task-Governance-Labels. Hier verweist kueue.x-k8s.io/priority-class auf eine WorkloadPriorityClass mit höherer Priorität, damit die Modelbereitstellung Batch-Trainings vorgehen kann, wenn die Ressourcen des Teams knapp sind:
apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: team-a-inference-endpoint namespace: hyperpod-ns-team-a # weist den Endpoint dem Namespace von Team A zu labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue # lokale Task-Governance-Queue (Kueue) kueue.x-k8s.io/priority-class: inference-priority # WorkloadPriorityClass mit höherer Priorität spec:... # Modellquelle, Instance-Typ, Replica-Anzahl, Autoscaling usw.... Weitere Informationen: Deploying models on Amazon SageMaker HyperPod
Einblick in die Cluster-Gesundheit, die Workload-Performance und die Ressourcennutzung ist für alle Teams unerlässlich. HyperPod Observability bietet integrierte Monitoring- und Dashboard-Funktionen über Amazon Managed Grafana.
Teams benötigen Zugriff auf Observability-Dashboards, um ihre Workloads zu überwachen, Performance-Probleme zu beheben und den Ressourcenverbrauch nachzuvollziehen. In einer Multi-Tenant-Umgebung sollte dieser Zugriff in der Regel jedoch nur lesend sein:
Das folgende Bild zeigt die Grafana-Rollenzuweisungen in Amazon Managed Grafana. Die Team-Gruppen ( TeamA, TeamB ) erhalten die Viewer-Rolle für den Lesezugriff auf Dashboards und Metriken, während die Admin-Gruppe die Admin-Rolle zugewiesen bekommt, die es ihr erlaubt, Dashboards zu erstellen und zu ändern, Alerting zu konfigurieren und Datenquellen zu verwalten.
Abbildung 12: Grafana-Rollenzuweisungen, die den Teams Lesezugriff als Viewer gewähren
Weitere Informationen: Observability for Amazon SageMaker HyperPod cluster orchestrated by Amazon EKS
In einer Multi-Tenant-Umgebung, in der sich Teams eine teure GPU-Infrastruktur teilen, ist es für Verantwortlichkeit, Budgetierung und Verrechnung unerlässlich zu verstehen, wer was verbraucht. Kubecost deckt diesen Bedarf ab, indem es die In-Cluster-Ausgaben entlang nativer Kubernetes-Konzepte (Namespace, Label, Deployment und Service) aufschlüsselt und sie organisatorischen Konzepten wie Team, Projekt oder Umgebung zuordnet.
Da diese Architektur jedes Team bereits in einem eigenen Namespace isoliert ( hyperpod-ns-team-a, hyperpod-ns-team-b ), richtet sich die Kostenzuweisung auf Namespace-Ebene direkt an den Teamgrenzen aus. Dies gibt Plattformadministratoren eine klare Ansicht pro Team über den Verbrauch von GPU, CPU, Arbeitsspeicher, Storage und Netzwerk, ganz ohne zusätzliche Workload-Tags. Schritt-für-Schritt-Anleitungen zur Bereitstellung und Konfiguration von Kubecost auf einem HyperPod-Cluster finden Sie unter Kubecost on SageMaker HyperPod.
Sobald Kubecost Daten erfasst, gruppieren Sie im Allocations-Dashboard die Kosten nach Namespace, um die Ausgaben pro Team zu sehen. Da jedes Team einen Namespace besitzt, ergibt sich daraus unmittelbar eine Kostenaufschlüsselung pro Team, die Compute, Arbeitsspeicher, Storage und Netzwerk abdeckt. Genau wie bei den Observability-Dashboards profitieren die Teams von der Einsicht in ihre eigenen Kostendaten:
Das folgende Bild zeigt das Kubecost Allocations-Dashboard, gruppiert nach Namespace, mit den kumulierten Kosten der letzten 7 Tage für den Namespace jedes Teams.
Abbildung 13: Kubecost Allocations-Dashboard, gruppiert nach Namespace, für Kosten pro Team
Weitere Informationen: Kubecost on SageMaker HyperPod · Kubecost
Dieser Beitrag hat eine Referenzarchitektur für den Aufbau von Multi-Tenant-Umgebungen auf Amazon SageMaker HyperPod mit EKS vorgestellt. Durch die Kombination von AWS IAM Identity Center für die Authentifizierung, teambezogenen IAM-Rollen für die Autorisierung auf AWS-Ebene, SageMaker AI Domains für ein zugeschnittenes Workspace-Erlebnis, Kubernetes-Namespaces für die Workload-Isolation, HyperPod Task Governance für eine faire Ressourcenzuteilung und Kostenzuweisung auf Namespace-Ebene für Sichtbarkeit der Ausgaben pro Team können mehrere Teams einen einzigen HyperPod EKS Cluster effizient gemeinsam nutzen.
Dies ist ein flexibler, kombinierbarer Ansatz, der mehrere Bausteine zu einer kohärenten Lösung zusammenführt. Die Architektur eignet sich für eine Vielzahl von Anwendungsfällen und Organisationsstrukturen. Organisationen können dieses Muster beispielsweise erweitern, um Teams auch an HyperPod Slurm Cluster anzubinden, und so eine einheitliche Multi-Tenant-Erfahrung über verschiedene Orchestrierungs-Backends hinweg zu schaffen.
Zwar erfordert dieser Ansatz den Aufbau und die Konfiguration mehrerer Komponenten, das Ergebnis ist jedoch ein hoher Grad an Kontrolle und Anpassungsfähigkeit, der sich an die spezifischen Isolations-, Compliance- und Betriebsanforderungen jeder Organisation anpassen lässt. Die grundlegenden Muster (Identity Federation, Namespace-Isolation, RBAC, quotenbasierte Governance und Kostenzuweisung) bleiben in jedem Fall anwendbar.
Um loszulegen, versuchen Sie, dieses Multi-Tenant-Setup auf Ihrem eigenen Amazon SageMaker HyperPod EKS Cluster nachzubauen, und passen Sie die Bausteine an die Isolations-, Governance- und Kostenzuweisungsanforderungen Ihrer Organisation an.
Giuseppe ist Principal Machine Learning Specialist Solutions Architect bei Amazon Web Services. Mit mehrjähriger Erfahrung in der Softwareentwicklung und einem ML-Hintergrund arbeitet er mit Kunden jeder Größe zusammen, um deren geschäftliche und technische Anforderungen tiefgehend zu verstehen und KI- und Machine-Learning-Lösungen zu entwerfen, die die AWS Cloud und das Amazon Machine Learning Stack optimal ausnutzen. Er hat an Projekten in verschiedenen Bereichen gearbeitet, darunter MLOps, Computer Vision und NLP, und dabei ein breites Spektrum an AWS-Services eingesetzt. In seiner Freizeit spielt Giuseppe gerne Fußball.
Mayank ist Senior AI/ML Specialist mit tiefgreifender Expertise in Machine-Learning-Frameworks und Enterprise-AI-Architekturen. Er bringt umfangreiche praktische Erfahrung mit AWS AI Services mit, darunter SageMaker AI und SageMaker HyperPod, und leitet die Konzeption und Umsetzung durchgängiger KI-Lösungen, die von der Modellentwicklung über verteiltes Training bis hin zur Bereitstellung im Produktionsmaßstab reichen. Mit großer Erfahrung in Performance-Optimierung und skalierbaren ML-Architekturen unterstützt Mayank Kunden dabei, komplexe geschäftliche Herausforderungen in sichere, wirkungsvolle und produktionsreife KI-Systeme zu übersetzen, die messbare Ergebnisse liefern.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Multiple teams within the same company increasingly need shared access to expensive GPU clusters for their generative AI operations, while maintaining isolation boundaries, resource fairness, and operational independence. Consider 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 of them might need access to the same cluster. Without a well-designed multi-tenant (multi-team) 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.
Amazon SageMaker HyperPod is a purpose-built AI service that simplifies the management of large-scale compute clusters for gen AI workloads. It provides resilient, optimized clusters orchestrated by Amazon Elastic Kubernetes Service (Amazon EKS) or Slurm, so organizations can run distributed training, interactive development, and model inference at scale. At the same time, it automatically handles node health monitoring, fault recovery, and cluster lifecycle management.
In this post, we present a reference architecture for building a multi-tenant environment on Amazon SageMaker HyperPod with EKS. This architecture uses 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. By the end of this post, you will have a clear blueprint for multiple teams to efficiently share a single HyperPod EKS cluster.
The following diagram illustrates the high-level architecture of a multi-tenant HyperPod EKS deployment. In this example, two teams (Team A and Team B) share a single HyperPod EKS cluster, each operating within their own isolated namespace.
Figure 1: High-level multi-tenant architecture for two teams sharing one HyperPod EKS cluster
The architecture is structured as a layered flow from left to right, connecting user identity through authorization controls and into isolated workload namespaces on the cluster.
On the far left, individual users from each team (User 1 from Team A, User 2 from Team B) interact with the system through two paths. Both paths authenticate through the AWS IAM Identity Center Portal, which federates with an external identity provider (such as Microsoft Entra ID) shown at the bottom-left.
The first path is through CLI access. Users authenticate with aws sso login, which redirects them to the Identity Center portal, and then obtain temporary credentials from their team’s permission set to submit tasks directly to the EKS cluster with kubectl. In the diagram, the pink arrow flows from the CLI terminal across the top directly into the HyperPod EKS cluster.
The second path is through the Identity Center portal directly, where users select the SageMaker Studio application to sign in to their team-specific SageMaker AI domain.
Each team has a corresponding permission set (TeamA permission set, TeamB permission set) that carries the AWS Identity and Access Management (IAM) policies needed for CLI workflows. Identity Center automatically provisions an IAM role for each permission set, shown in the diagram as TeamA-permissionset-role and TeamB-permissionset-role (labeled “CLI/Console role”). This role serves as the IAM principal when users authenticate through aws sso login.
From the Identity Center portal, users are routed to their team-specific SageMaker AI domain. Each domain (SageMaker AI domain Team A and SageMaker AI domain Team B) provides a dedicated Amazon SageMaker Studio GUI and is configured with a team-specific execution role ( TeamA-role and TeamB-role respectively). These domains serve as the primary workspace interface, so users can submit tasks from the GUI (shown by the pink arrows flowing toward EKS).
At the EKS boundary, access entries map IAM roles to Kubernetes permissions. The diagram shows access entries for TeamA-role and TeamB-role (the Studio execution roles), which authorize requests originating from the SageMaker Studio GUI. Access entries must also be configured for the Identity Center-provisioned CLI/Console roles ( TeamA-permissionset-role and TeamB-permissionset-role ) to authorize requests arriving through kubectl. All access entries are associated with managed or custom role-based access control (RBAC) policies (represented by the key icon) and scoped to the team’s designated namespace. As a result, whether access originates from Studio or the CLI, users can only interact with resources in their own namespace.
The cluster itself is depicted with two cross-cutting platform layers at the top: HyperPod Observability (for monitoring and dashboards) and HyperPod Task Governance (for compute quota management and scheduling priorities). Below these layers, the cluster is partitioned into Namespace A (Team A) and Namespace B (Team B). Within each namespace, teams can run their own HyperPod Spaces (interactive development environments), HyperPod PyTorch jobs (distributed training workloads), and HyperPod Inference endpoints (model serving).
Beneath the cluster, the architecture includes two storage tiers. The first is a POSIX-compliant file system (Amazon FSx for Lustre or Amazon FSx for OpenZFS) organized into per-team shared directories ( /fsx/TeamA, /fsx/TeamB ) and per-user home directories ( /home/User1, /home/User2 ). The second is per-team or shared Amazon Simple Storage Service (Amazon S3) buckets for object storage, governed by the team’s IAM execution role.
This architecture isolates each team from authentication through authorization to workload execution, while sharing expensive GPU infrastructure efficiently.
The foundation of any multi-tenant system is robust authentication: verifying who users are before they interact with any resource. In this architecture, AWS IAM Identity Center serves as the centralized authentication layer, federating with an external identity provider to manage user identities and group memberships.
AWS IAM Identity Center (successor to AWS Single Sign-On) provides a single place to manage workforce identities across AWS accounts and applications. For a multi-tenant HyperPod deployment, it offers several key capabilities:
In this reference architecture, we use Microsoft Entra ID as the external identity provider, though the same pattern applies to most standard Security Assertion Markup Language (SAML) 2.0 providers.
With this configuration, you manage team membership (which drives all downstream authorization decisions) in your existing corporate directory, and it propagates to AWS automatically.
The following image shows an example of how organizational teams can be represented in Microsoft Entra ID, with dedicated groups for TeamA, TeamB, and Admin.
Figure 2: Organizational teams represented as groups in Microsoft Entra ID
Then, the following image shows the corresponding groups in AWS IAM Identity Center, automatically provisioned from Entra ID through SCIM synchronization.
Figure 3: Corresponding groups in AWS IAM Identity Center, provisioned through SCIM
Learn more: Connect an external identity provider · SCIM profile and SAML 2.0 implementation
With authentication established, the next layer is authorization: controlling what actions each team can perform across AWS services and the Kubernetes cluster. Authorization in this architecture operates at two levels: IAM for service-level access, and Kubernetes RBAC for cluster-level access.
Each team requires a dedicated IAM role that encapsulates the AWS level permissions needed for their AI and machine learning (ML) workflows. These roles serve as the SageMaker AI domain execution role and define what AWS services the team can access.
A typical team IAM role should include policies granting access to:
The trust policy on each IAM role must include sagemaker.amazonaws.com as a trusted principal, so SageMaker AI can assume the role on behalf of users when they operate through Studio. If you plan to reuse the same execution role as an EKS Pod Identity association for in-cluster workloads (as discussed later in the Amazon S3 storage section), the trust policy must also include pods.eks.amazonaws.com as a trusted principal. CLI access through Identity Center uses a separate permission set with its own policies (see the “AWS account access through Identity Center” section), so CLI permissions can be independently scoped.
Learn more: How to use SageMaker AI execution roles
Beyond SageMaker Studio, teams often need direct AWS account access for CLI operations such as running kubectl commands, scripting workflows, or accessing resources programmatically. Identity Center permission sets provide this capability.
For the Admin group, assign a permission set with administrative access as required by your company’s policies, granting the necessary account access for cluster management and administrative operations.
For Team A and Team B, create permission sets with inline or managed policies that grant the permissions needed for CLI workflows directly. A typical team permission set includes permissions for eks:AccessKubernetesApi (to view Kubernetes resources from AWS Console), scoped S3 access for the team’s data, and CloudWatch read access for monitoring. These policies are defined independently from the Studio execution role, so administrators can tailor CLI permissions to the specific operations that teams perform from the command line.
Users retrieve temporary credentials through the AWS Command Line Interface (AWS CLI) using aws sso login, which they can then use to configure kubectl for direct interaction with the EKS cluster.
The following image shows the per-team permission sets in AWS IAM Identity Center, providing scoped AWS account access for CLI workflows such as running kubectl and aws sso login against the EKS cluster.
Figure 4: Per-team permission sets in AWS IAM Identity Center for CLI workflows
Learn more: Manage AWS accounts with permission sets
Team members configure the AWS CLI to authenticate through Identity Center by running aws configure sso. This creates profiles in ~/.aws/config that reference the appropriate Identity Center session and permission set. Each team member uses their team-specific profile when interacting with the cluster from the command line, maintaining authorization boundaries whether access originates from Studio or from a local terminal.
The resulting configuration defines a shared sso-session block for the Identity Center portal and one named profile per team, each pointing at that team’s permission set. Team members then run aws sso login --profile <team> to obtain temporary credentials scoped to their permission set:
[sso-session my-sso] sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start sso_region = us-west-2 sso_registration_scopes = sso:account:access [default] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = OpsAdmin region = us-west-2 [profile team-a] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = TeamA-permission-set region = us-west-2 [profile team-b] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = TeamB-permission-set region = us-west-2 Learn more: Configuring IAM Identity Center authentication with the AWS CLI
SageMaker AI domains provide the workspace boundary for each team, offering a tailored user experience, pre-configured execution roles, and built-in integration with Identity Center authentication.
Using one SageMaker AI domain per team is a well-established pattern for organizing multi-team environments. This approach offers several advantages:
Learn more: SageMaker AI domain entities and statuses · Multiple domains overview
Create one SageMaker AI domain per team with Identity Center authentication. In our example, we create TeamA-domain and TeamB-domain. Each domain is configured as follows:
The following image shows the SageMaker AI console with one domain per team ( TeamA-domain and TeamB-domain ), each providing an isolated workspace boundary.
Figure 5: One SageMaker Domain per team in the SageMaker console
Then the following image shows the details of TeamA-domain, including the assigned Identity Center groups.
Figure 6: TeamA-domain configuration with its assigned Identity Center groups
The HyperPod EKS cluster is where workloads are executed. Multi-tenancy at the cluster level is achieved through Kubernetes namespaces for isolation and EKS access entries for authorization.
Create a dedicated Kubernetes namespace for each team, for example hyperpod-ns-team-a and hyperpod-ns-team-b. Namespaces provide a logical boundary within the cluster, isolating each team’s workloads (Spaces, training jobs, inference endpoints) from one another.
Note: Namespaces are an isolation boundary, not a hard security boundary. This architecture targets multi-team within a single organization: teams that share a cluster under a common administrative domain and a baseline of mutual trust. It isn’t designed for multi-customer isolation between mutually untrusted tenants.
Namespaces, RBAC, and quotas prevent accidental interference (teams overwriting each other’s resources or exceeding their compute allocation) but aren’t a defense against a determined malicious tenant: namespaced pods share the same nodes and kernel, and cluster-scoped resources (nodes, PersistentVolumes, CRDs, some operator components) sit outside any namespace.
For untrusted tenants or strict regulatory isolation, use stronger boundaries such as separate clusters or accounts, dedicated node pools, and runtime sandboxing. For the multi-team scenario here, namespace isolation combined with RBAC, Task Governance quotas, and the POSIX identity controls described later strike an appropriate balance of separation and operational simplicity.
Namespaces can be created manually with kubectl create namespace or provisioned automatically through HyperPod Task Governance, which manages namespaces as part of its quota and scheduling configuration.
The following image shows the cluster namespaces (managed with HyperPod Task Governance), with one dedicated namespace per team ( hyperpod-ns-team-a and hyperpod-ns-team-b ) providing workload isolation.
Figure 7: Dedicated Kubernetes namespace per team for workload isolation
Namespaces don’t restrict network traffic. By default, Kubernetes networking is flat: every pod can reach every other pod across all namespaces. As a result, a pod in hyperpod-ns-team-a can open a connection to a pod in hyperpod-ns-team-b unless you add controls. To scope pod-to-pod reachability along team boundaries, use Kubernetes NetworkPolicy resources.
The recommended pattern is default-deny per namespace: start by denying all ingress (and optionally egress), then explicitly allow the traffic each team needs, typically intra-namespace communication plus required egress such as DNS, storage endpoints, and AWS APIs. The following example denies all ingress in a team’s namespace and then allows traffic only from pods within the same namespace:
# 1. Default-deny all ingress in the team's namespace. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: hyperpod-ns-team-a spec: podSelector: {} # applies to all pods in the namespace policyTypes: - Ingress --- # 2. Allow ingress only from pods within the same namespace. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-same-namespace namespace: hyperpod-ns-team-a spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: {} # any pod in this namespace NetworkPolicy enforcement depends on a Container Network Interface (CNI) that supports it. On EKS, you can enable network policy support in the Amazon Virtual Private Cloud (Amazon VPC) CNI.
As with namespaces, NetworkPolicies reduce accidental cross-team reachability and shrink the scope, but they are not by themselves an adversarial security boundary on shared nodes. For stronger separation, consider dedicated node pools per team or separate clusters, as noted earlier.
Learn more: Kubernetes network policies · Amazon VPC CNI network policy
EKS access entries connect IAM principals to Kubernetes RBAC permissions. For each team, create two access entries:
Both entries are scoped to the team’s namespace with managed or custom Kubernetes policies. For example, both Team A entries grant permissions only within hyperpod-ns-team-a. The two entries can carry different RBAC policies if you want. For instance, the CLI entry might restrict write access to certain resource types while the Studio entry allows full access.
With this scoping, whether access originates from Studio or from the CLI, users can only interact with resources in their own namespace. Attempting to list or modify resources in another team’s namespace results in a Kubernetes Forbidden error.
For more advanced scenarios, you can use Kubernetes groups in the access entry to map users to custom ClusterRoles or Roles that provide fine-grained permissions beyond the standard managed policies.
The following image shows an EKS access entry for Team B’s role, scoped down to the hyperpod-ns-team-b namespace, so its permissions apply only within Team B’s namespace.
Figure 8: EKS access entry scoped to Team B’s namespace
Learn more: Grant IAM users access to Kubernetes with EKS access entries
When Task Governance is enabled on the cluster, it provides an additional layer of resource management:
Configure Task Governance with appropriate quotas and priorities per team namespace, balancing between guaranteed minimum allocations and burst capacity for bursty workloads.
The following image shows the Task Governance compute allocations for the two teams, with each team’s namespace assigned its own quota of cluster compute capacity.
Figure 9: Task Governance compute allocations per team namespace
Learn more: SageMaker HyperPod task governance
Storage is a key component of artificial intelligence and machine learning (AI/ML) environments shared across teams. Teams need high-performance file systems for training data, checkpoints, and model artifacts, while maintaining appropriate access boundaries between teams.
For workloads that require a shared, high-performance POSIX file system (common for distributed training where multiple nodes read the same dataset or write checkpoints), consider the following options:
The storage layout typically follows this structure:
The POSIX permission model on these file systems relies on UIDs, GIDs, and supplemental groups to enforce access boundaries. These POSIX identities should then be propagated to the pod security context when a user launches a HyperPod Space or submits a training job, so that file system access respects the configured ownership and permissions. We recommend using a Kubernetes mutating admission webhook to retrieve POSIX identity information from your identity store. When a workload is submitted, the webhook looks up the identity at runtime and modifies the security context of the Pod accordingly.
# 1. Extract the caller's session identity from the admission request. # On EKS, requests from IAM-assumed roles (including IAM Identity Center) # surface the STS session name in userInfo.extra["sessionName"]. Its format # depends on how the session is created (e.g., an SSO short name, an email, # or a role-session-name); align your identity mapping with this value. def extract_username(admission_request): extra = admission_request["userInfo"]["extra"]... return extra["sessionName"] # 2.
Look up the POSIX identity from a mapping table (e.g. DynamoDB). def lookup_posix_identity(username): item = posix_table.get_item(Key={"username": username})["Item"]... return { "uid": int(item["uid"]), "gid": int(item["gid"]), "supplementalGroups": [int(g) for g in item["supplementalGroups"]], } # 3. Patch the Pod security context with the resolved POSIX identity. def build_security_context_patch(pod, posix):... return [{ "op": "add", "path": "/spec/securityContext", "value": { "runAsUser": posix["uid"], "runAsGroup": posix["gid"], "fsGroup": posix["gid"], "supplementalGroups": posix["supplementalGroups"], }, }] Learn more: FSx for Lustre · FSx for OpenZFS · Amazon EFS
For object storage, access to S3 buckets is governed by the team’s IAM execution role. You can create per-team buckets or use a shared bucket with per-team prefixes, relying on IAM policies to enforce isolation. Pods within the cluster need appropriate service accounts configured with IAM Roles for Service Accounts (IRSA) or Pod Identity to authenticate to S3. For simplicity, you can associate the same execution role configured on the SageMaker AI domain to a Kubernetes service account within the team’s namespace, providing consistent S3 access from both Studio and cluster workloads.
Learn more: IAM roles for service accounts (IRSA) · EKS Pod Identity
HyperPod Spaces provide interactive development environments (IDEs) running directly on cluster nodes. On a shared cluster, Spaces must be properly scoped to each team’s namespace and configured with appropriate resource templates.
Create namespace-scoped Space templates for each team. These templates define the resource configurations (instance types, storage volumes, environment variables) available to team members when creating Spaces. By scoping templates to a namespace, you make sure that each team can only launch Spaces within their designated boundary.
When HyperPod Task Governance is enabled, templates should include the default labels required by the governance system (such as team identifiers and priority labels). The cluster administrator pre-configures these labels so that team members don’t need to specify them manually when launching Spaces.
The following example shows a JupyterLab Space template scoped to Team A. The team-specific parts are the metadata.namespace, the Task Governance queue label under baseLabels, and the defaultVolumes that mount the team’s shared file system and the user’s home directory:
apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: jl-smd-custom namespace: hyperpod-ns-team-a # scopes the template to Team A's namespace spec: displayName: "JupyterLab (team-a)" description: "SageMaker Distribution" appType: jupyterlab baseLabels: - key: kueue.x-k8s.io/queue-name # Task Governance (Kueue) local queue for Team A value: hyperpod-ns-team-a-localqueue... # container command, default CPU/memory resources, security context, access type, etc.... defaultVolumes: - name: home-dir # per-user home directory mountPath: /home persistentVolumeClaimName: fsx-openzfs-claim - name: shared-data # Team A's shared directory mountPath: /fsx persistentVolumeClaimName: fsx-lustre-claim... # primary (EBS) storage defaults and limits... Persistent volume claims Create the appropriate Persistent Volume Claims (PVCs) in each team’s namespace, referencing the shared file system. These PVCs mount the team’s shared directory and the user’s home directory into the Space, providing access to training data, checkpoints, and personal workspaces.
Consider your organization’s requirements around Space sharing:
Learn more: Interactive development environments on Amazon SageMaker HyperPod EKS clusters
While teams can interact with the cluster entirely from the CLI using kubectl, SageMaker Studio provides a graphical entry point to the cluster for users who prefer a managed, GUI-driven workflow. In this architecture, each team accesses Studio through its own SageMaker AI domain (as described earlier), signing in with the same Identity Center credentials and operating within the boundaries of the team’s namespace.
The following image shows the IAM Identity Center access portal that users reach after signing in with their corporate credentials, providing single sign-on access to their assigned SageMaker Studio applications and Amazon Managed Grafana applications.
Figure 10: IAM Identity Center access portal with single sign-on to assigned applications
Because Studio operates through the team’s Domain execution role and the corresponding EKS access entry, all actions are scoped to the team’s namespace. A user launching a Space or a Ray cluster from Studio can only create it within their own team’s boundary, consistent with the isolation model enforced for CLI access.
The following image shows how to create a HyperPod Space from the SageMaker Studio UI, where a team member selects a namespace-scoped Space template without writing Kubernetes manifests or specifying Task Governance labels manually.
Figure 11: Creating a HyperPod Space from a namespace-scoped template in SageMaker Studio
Learn more: Interactive development environments on Amazon SageMaker HyperPod EKS clusters · Introducing new Ray capabilities on SageMaker HyperPod
The HyperPod Training Operator enables teams to submit distributed training jobs as Kubernetes custom resources (for example, HyperPodPyTorchJob). In the multi-tenant architecture, training jobs are namespace-scoped, meaning they automatically inherit the team’s isolation boundaries.
Teams can submit training jobs from the CLI using kubectl apply with the appropriate job manifest. The job runs in the team’s namespace, uses the team’s compute quotas (if Task Governance is enabled), and has access to the team’s storage volumes.
When Task Governance is enabled, training jobs are subject to the team’s allocated quotas and priority settings. If a team has consumed its guaranteed allocation, jobs might be queued until resources become available or until lower-priority workloads are preempted.
The two elements that anchor a job to a team are the metadata.namespace (which scopes the job to the team’s isolation boundary) and the Task Governance labels. Task Governance is built on Kueue, so the job is routed to the team’s local queue through kueue.x-k8s.io/queue-name. It’s assigned a scheduling priority through kueue.x-k8s.io/priority-class, whose value is the name of a WorkloadPriorityClass defined on the cluster:
apiVersion: sagemaker.amazonaws.com/v1 kind: HyperPodPyTorchJob metadata: name: team-a-training-job namespace: hyperpod-ns-team-a # scopes the job to Team A's namespace labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue # Task Governance (Kueue) local queue kueue.x-k8s.io/priority-class: training-priority # name of a WorkloadPriorityClass spec:... # replicaSpecs, container image, command, resources, volumes, etc.... Learn more: Using the HyperPod training operator
The HyperPod Inference Operator allows teams to deploy models as inference endpoints directly on the cluster. Similar to training jobs, inference endpoints are namespace-scoped and subject to the team’s RBAC policies and Task Governance quotas.
Teams can deploy models from the CLI by creating inference endpoint custom resources in their namespace. The endpoints are isolated per namespace, meaning Team A can’t access or interfere with Team B’s inference endpoints.
For production inference workloads that require high availability, consider assigning higher scheduling priority to inference endpoints than to training jobs, so that model serving isn’t interrupted by batch training workloads.
As with training jobs, the inference endpoint is placed in the team’s metadata.namespace and carries the Task Governance labels. Here, the kueue.x-k8s.io/priority-class references a higher-priority WorkloadPriorityClass so that model serving can preempt batch training when the team’s resources are constrained:
apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: team-a-inference-endpoint namespace: hyperpod-ns-team-a # scopes the endpoint to Team A's namespace labels: kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue # Task Governance (Kueue) local queue kueue.x-k8s.io/priority-class: inference-priority # higher-priority WorkloadPriorityClass spec:... # model source, instance type, replica count, autoscaling, etc.... Learn more: Deploying models on Amazon SageMaker HyperPod
Visibility into cluster health, workload performance, and resource utilization is essential for all teams. HyperPod Observability provides built-in monitoring and dashboarding capabilities through Amazon Managed Grafana.
Teams need access to observability dashboards to monitor their workloads, troubleshoot performance issues, and understand resource consumption. However, in a multi-tenant environment, this access should typically be read-only:
The following image shows the Grafana role assignments in Amazon Managed Grafana. The team groups ( TeamA, TeamB ) are assigned the Viewer role for read-only access to dashboards and metrics, while the admin group is assigned the Admin role, granting it the ability to create and modify dashboards, configure alerting, and manage data sources.
Figure 12: Grafana role assignments granting teams read-only Viewer access
Learn more: Observability for Amazon SageMaker HyperPod cluster orchestrated by Amazon EKS
In a multi-tenant environment where teams share expensive GPU infrastructure, understanding who consumes what is essential for accountability, budgeting, and chargeback. Kubecost addresses this need by breaking down in-cluster spend across native Kubernetes concepts (namespace, label, deployment, and service) and mapping it to organizational concepts like team, project, or environment.
Because this architecture already isolates each team in a dedicated namespace ( hyperpod-ns-team-a, hyperpod-ns-team-b ), namespace-level cost allocation aligns directly with team boundaries. This gives platform administrators a clear per-team view of GPU, CPU, memory, storage, and network consumption without any additional workload tagging. For step-by-step instructions on deploying and configuring Kubecost on a HyperPod cluster, see Kubecost on SageMaker HyperPod.
After Kubecost is collecting data, group cost by namespace in the Allocations dashboard to see per-team spend. Because each team owns a namespace, this directly produces a per-team cost breakdown covering compute, memory, storage, and network. Just as with observability dashboards, teams benefit from visibility into their own cost data:
The following image shows the Kubecost Allocations dashboard grouped by namespace, showing the cumulative cost over the last 7 days for each team’s namespace.
Figure 13: Kubecost Allocations dashboard grouped by namespace for per-team cost
Learn more: Kubecost on SageMaker HyperPod · Kubecost
This post presented a reference architecture for building multi-tenant environments on Amazon SageMaker HyperPod with EKS. By combining AWS IAM Identity Center for authentication, per-team IAM roles for AWS level authorization, SageMaker AI domains for a tailored workspace experience, Kubernetes namespaces for workload isolation, HyperPod Task Governance for fair resource allocation, and namespace-level cost allocation for per-team spend visibility, multiple teams can efficiently share a single HyperPod EKS cluster.
This is a flexible, composable approach that combines multiple building blocks into a cohesive solution. The architecture accommodates a variety of use cases and organizational structures. For example, organizations can extend this pattern to connect teams to HyperPod Slurm clusters alongside EKS, providing a unified multi-tenant experience across different orchestration backends.
While this approach requires assembling and configuring several components, the result is a high degree of control and customization that can be tailored to each organization’s specific isolation, compliance, and operational requirements. The foundational patterns (identity federation, namespace isolation, RBAC, quota-based governance, and cost allocation) will remain applicable.
To get started, try building this multi-tenant setup on your own Amazon SageMaker HyperPod EKS cluster, and adapt the building blocks to your organization’s isolation, governance, and cost-allocation requirements.
Giuseppe is a Principal Machine Learning Specialist Solutions Architect for Amazon Web Services. With several years of software engineering and an ML background, he works with customers of any size to deeply understand their business and technical needs and design AI and Machine Learning solutions that make the best use of the AWS Cloud and the Amazon Machine Learning stack. He has worked on projects in different domains, including MLOps, Computer Vision, NLP, and involving a broad set of AWS services. In his free time, Giuseppe enjoys playing football.
Mayank is a Senior AI/ML Specialist with deep expertise in machine learning frameworks and enterprise AI architecture. He brings strong hands-on experience with AWS AI services, including SageMaker AI and SageMaker HyperPod, and leads the design and delivery of end-to-end AI solutions spanning model development, distributed training, and production-scale deployment. With deep experience in performance optimization and scalable ML architectures, Mayank partners with customers to translate complex business challenges into secure, high-impact, production-ready AI systems that drive measurable outcomes.