Partager des clusters GPU entre équipes avec isolation et équité à l'aide d'Amazon SageMaker HyperPod

Au sein d'une même entreprise, plusieurs équipes ont de plus en plus besoin d'un accès partagé à des clusters GPU coûteux pour leurs opérations d'IA générative, tout en maintenant des frontières d'isolation, une équité des ressources et une indépendance opérationnelle. Imaginez une équipe de science des données entraînant de grands modèles de langage, un groupe de vision par ordinateur exécutant des charges de travail d'inférence, et une équipe de recherche expérimentant de nouvelles architectures de modèles. Toutes pourraient avoir besoin d'accéder au même cluster. Sans une architecture multi-tenant (multi-équipes) bien conçue, les organisations sont confrontées à une consommation de ressources incontrôlée, à une isolation faible entre les équipes, à une incapacité à attribuer les coûts GPU partagés aux équipes qui les engendrent, et à une charge administrative qui ralentit l'innovation.

Amazon SageMaker HyperPod est un service d'IA conçu spécifiquement qui simplifie la gestion de clusters de calcul à grande échelle pour les charges de travail d'IA générative. Il fournit des clusters résilients et optimisés orchestrés par Amazon Elastic Kubernetes Service (Amazon EKS) ou Slurm, permettant ainsi aux organisations d'exécuter l'entraînement distribué, le développement interactif et l'inférence de modèles à grande échelle. Parallèlement, il gère automatiquement la surveillance de la santé des nœuds, la récupération après panne et la gestion du cycle de vie du cluster.

Dans cet article, nous présentons une architecture de référence pour construire un environnement multi-tenant sur Amazon SageMaker HyperPod avec EKS. Cette architecture utilise AWS IAM Identity Center pour une authentification centralisée, des domaines SageMaker AI par équipe pour une expérience utilisateur personnalisée, des espaces de noms Kubernetes pour l'isolation des charges de travail, HyperPod Task Governance pour une allocation équitable des ressources, et une allocation des coûts au niveau de l'espace de noms pour la visibilité des dépenses et la refacturation par équipe. À la fin de cet article, vous disposerez d'un schéma directeur clair permettant à plusieurs équipes de partager efficacement un seul cluster HyperPod EKS.

Vue d'ensemble de l'architecture

Le diagramme suivant illustre l'architecture de haut niveau d'un déploiement HyperPod EKS multi-tenant. Dans cet exemple, deux équipes (Team A et Team B) partagent un seul cluster HyperPod EKS, chacune opérant dans son propre espace de noms isolé.

Figure 1 : Architecture multi-tenant de haut niveau pour deux équipes partageant un seul cluster HyperPod EKS

L'architecture est structurée comme un flux en couches de gauche à droite, reliant l'identité des utilisateurs à travers les contrôles d'autorisation jusqu'aux espaces de noms de charges de travail isolés sur le cluster.

Utilisateurs et authentification

À l'extrême gauche, les utilisateurs individuels de chaque équipe (User 1 de Team A, User 2 de Team B) interagissent avec le système par deux chemins. Les deux chemins s'authentifient via le portail AWS IAM Identity Center, qui se fédère avec un fournisseur d'identité externe (tel que Microsoft Entra ID) illustré en bas à gauche.

Le premier chemin passe par l'accès CLI. Les utilisateurs s'authentifient avec aws sso login, qui les redirige vers le portail Identity Center, puis obtiennent des informations d'identification temporaires à partir du jeu d'autorisations de leur équipe pour soumettre des tâches directement au cluster EKS avec kubectl. Dans le diagramme, la flèche rose part du terminal CLI le long du haut et entre directement dans le cluster HyperPod EKS.

Le second chemin passe directement par le portail Identity Center, où les utilisateurs sélectionnent l'application SageMaker Studio pour se connecter à leur domaine SageMaker AI propre à leur équipe.

Chaque équipe dispose d'un jeu d'autorisations correspondant (TeamA permission set, TeamB permission set) qui contient les stratégies AWS Identity and Access Management (IAM) nécessaires aux flux de travail CLI. Identity Center provisionne automatiquement un rôle IAM pour chaque jeu d'autorisations, illustré dans le diagramme par TeamA-permissionset-role et TeamB-permissionset-role (étiquetés « CLI/Console role »). Ce rôle sert de principal IAM lorsque les utilisateurs s'authentifient via aws sso login.

Domaines SageMaker AI

Depuis le portail Identity Center, les utilisateurs sont acheminés vers leur domaine SageMaker AI propre à leur équipe. Chaque domaine (SageMaker AI domain Team A et SageMaker AI domain Team B) fournit une interface graphique Amazon SageMaker Studio dédiée et est configuré avec un rôle d'exécution propre à l'équipe (TeamA-role et TeamB-role respectivement). Ces domaines servent d'interface de travail principale, permettant aux utilisateurs de soumettre des tâches depuis l'interface graphique (montré par les flèches roses se dirigeant vers EKS).

Contrôle d'accès EKS

À la frontière EKS, les entrées d'accès mappent les rôles IAM aux autorisations Kubernetes. Le diagramme montre des entrées d'accès pour TeamA-role et TeamB-role (les rôles d'exécution Studio), qui autorisent les requêtes provenant de l'interface graphique SageMaker Studio. Des entrées d'accès doivent également être configurées pour les rôles CLI/Console provisionnés par Identity Center (TeamA-permissionset-role et TeamB-permissionset-role) afin d'autoriser les requêtes arrivant via kubectl. Toutes les entrées d'accès sont associées à des stratégies RBAC (contrôle d'accès basé sur les rôles) gérées ou personnalisées (représentées par l'icône de clé) et délimitées à l'espace de noms désigné de l'équipe. Ainsi, que l'accès provienne de Studio ou de la CLI, les utilisateurs ne peuvent interagir qu'avec les ressources de leur propre espace de noms.

Cluster HyperPod EKS

Le cluster lui-même est représenté avec deux couches de plateforme transversales en haut : HyperPod Observability (pour la surveillance et les tableaux de bord) et HyperPod Task Governance (pour la gestion des quotas de calcul et les priorités d'ordonnancement). En dessous de ces couches, le cluster est partitionné en Namespace A (Team A) et Namespace B (Team B). Dans chaque espace de noms, les équipes peuvent exécuter leurs propres HyperPod Spaces (environnements de développement interactifs), leurs tâches HyperPod PyTorch (charges de travail d'entraînement distribué) et leurs points de terminaison HyperPod Inference (service de modèles).

Stockage

Sous le cluster, l'architecture comprend deux niveaux de stockage. Le premier est un système de fichiers compatible POSIX (Amazon FSx for Lustre ou Amazon FSx for OpenZFS) organisé en répertoires partagés par équipe (/fsx/TeamA, /fsx/TeamB) et en répertoires personnels par utilisateur (/home/User1, /home/User2). Le second est constitué de compartiments Amazon Simple Storage Service (Amazon S3) par équipe ou partagés pour le stockage d'objets, gouvernés par le rôle d'exécution IAM de l'équipe.

Cette architecture isole chaque équipe, de l'authentification à l'autorisation en passant par l'exécution des charges de travail, tout en partageant efficacement une infrastructure GPU coûteuse.

Authentification et contrôle des accès

Le fondement de tout système multi-tenant est une authentification robuste : vérifier l'identité des utilisateurs avant qu'ils n'interagissent avec une ressource. Dans cette architecture, AWS IAM Identity Center sert de couche d'authentification centralisée, en se fédérant avec un fournisseur d'identité externe pour gérer les identités des utilisateurs et les appartenances aux groupes.

Pourquoi AWS IAM Identity Center

AWS IAM Identity Center (successeur d'AWS Single Sign-On) fournit un emplacement unique pour gérer les identités de la main-d'œuvre dans les comptes et applications AWS. Pour un déploiement multi-tenant de HyperPod, il offre plusieurs capacités clés :

• Gestion centralisée des identités – Plutôt que de maintenir des bases de données d'utilisateurs séparées par service AWS, Identity Center fournit une source unique de vérité pour toutes les identités des utilisateurs et leurs appartenances aux groupes.
• Fédération avec les fournisseurs d'identité existants – La plupart des entreprises gèrent déjà les identités de leur main-d'œuvre dans des systèmes comme Microsoft Entra ID (anciennement Azure AD), Okta ou Ping Identity. Identity Center s'intègre à ces fournisseurs, ce qui permet aux organisations de réutiliser leur infrastructure d'identité existante sans dupliquer les comptes d'utilisateurs.
• Intégration native avec SageMaker AI – Les domaines SageMaker AI prennent en charge l'authentification Identity Center, de sorte que les utilisateurs peuvent se connecter à SageMaker Studio via leur fournisseur d'identité d'entreprise avec l'authentification unique (SSO).
• Accès au compte AWS – Identity Center peut également accorder aux utilisateurs l'accès au compte AWS sous-jacent avec des ensembles d'autorisations spécifiques, qui prennent en charge les flux de travail en ligne de commande en plus de l'expérience GUI de Studio.
• Requis pour Amazon Managed Grafana – Amazon Managed Grafana utilise Identity Center comme mécanisme d'authentification pour les utilisateurs de la main-d'œuvre, ce qui en fait le choix naturel lorsque les équipes ont également besoin d'accéder à des tableaux de bord d'observabilité pour surveiller leurs charges de travail.

En savoir plus : Qu'est-ce que IAM Identity Center

Configuration d'Identity Center avec un fournisseur d'identité externe

Dans cette architecture de référence, nous utilisons Microsoft Entra ID comme fournisseur d'identité externe, bien que le même modèle s'applique à la plupart des fournisseurs Security Assertion Markup Language (SAML) 2.0 standard.

La configuration comprend :

1. Structure de groupes dans le fournisseur d'identité – Dans Entra ID, créez des groupes correspondant à vos équipes organisationnelles. Dans notre exemple, nous définissons trois groupes : TeamA, TeamB, et Admin. Chaque groupe contient les utilisateurs appartenant à cette équipe (par exemple, user1-teamA@example.com dans le groupe TeamA ).
2. Provisionnement SCIM – Activez la synchronisation SCIM (System for Cross-domain Identity Management) entre Entra ID et AWS IAM Identity Center. SCIM fournit le provisionnement et le déprovisionnement automatiques des utilisateurs et des groupes. Lorsqu’un nouvel utilisateur est ajouté au TeamA groupe dans Entra ID, il est automatiquement synchronisé vers Identity Center et obtient les accès appropriés sans intervention manuelle.
3. Authentification basée sur SAML – Configurez la fédération SAML 2.0 afin que, lorsque les utilisateurs s’authentifient, ils le fassent auprès d’Entra ID. Identity Center agit comme fournisseur de services, faisant confiance aux assertions de votre locataire Entra ID.

Avec cette configuration, vous gérez l’appartenance aux équipes (qui pilote toutes les décisions d’autorisation en aval) dans votre annuaire d’entreprise existant, et elle se propage automatiquement vers AWS.

L’image suivante montre un exemple de la manière dont les équipes organisationnelles peuvent être représentées dans Microsoft Entra ID, avec des groupes dédiés pour TeamA, TeamB, et Admin.

Figure 2 : Équipes organisationnelles représentées comme groupes dans Microsoft Entra ID

Ensuite, l’image suivante montre les groupes correspondants dans AWS IAM Identity Center, provisionnés automatiquement depuis Entra ID via la synchronisation SCIM.

Figure 3 : Groupes correspondants dans AWS IAM Identity Center, provisionnés via SCIM

En savoir plus : Connecter un fournisseur d’identité externe · Profil SCIM et implémentation SAML 2.0

Autorisation

Une fois l’authentification établie, la couche suivante est l’autorisation : contrôler quelles actions chaque équipe peut effectuer sur les services AWS et le cluster Kubernetes. L’autorisation dans cette architecture fonctionne à deux niveaux : IAM pour l’accès au niveau des services, et Kubernetes RBAC pour l’accès au niveau du cluster.

Rôles IAM par équipe

Chaque équipe nécessite un rôle IAM dédié qui encapsule les autorisations de niveau AWS nécessaires à ses flux de travail d'IA et de machine learning (ML). Ces rôles servent de rôle d'exécution du domaine SageMaker AI et définissent les services AWS auxquels l'équipe peut accéder.

Un rôle IAM d'équipe typique doit inclure des politiques accordant l'accès à :

• Amazon SageMaker AI – Pour la gestion des clusters HyperPod, des serveurs de suivi MLflow et d'autres ressources SageMaker AI via l'API SageMaker AI.
• Amazon S3 – Pour la lecture des jeux de données d'entraînement et l'écriture des artefacts de modèles, des points de contrôle et des journaux. Limitez la portée de ces autorisations aux préfixes de compartiments propres à l'équipe.
• Amazon CloudWatch – Pour la consultation des journaux et des métriques liés aux charges de travail de l'équipe.
• Amazon EKS – Plus précisément, les eks:AccessKubernetesApi et eks:MutateViaKubernetesApi autorisations, dont l'interface graphique SageMaker Studio a besoin pour effectuer des appels à l'API Kubernetes au nom de l'utilisateur (par exemple, lister les Spaces ou soumettre des jobs).

La politique de confiance de chaque rôle IAM doit inclure sagemaker.amazonaws.com en tant que principal approuvé, afin que SageMaker AI puisse endosser le rôle au nom des utilisateurs lorsqu'ils opèrent via Studio. Si vous prévoyez de réutiliser le même rôle d'exécution comme association EKS Pod Identity pour les charges de travail au sein du cluster (comme indiqué plus loin dans la section sur le stockage Amazon S3), la politique de confiance doit également inclure pods.eks.amazonaws.com en tant que principal approuvé. L'accès CLI via Identity Center utilise un jeu d'autorisations distinct avec ses propres politiques (voir la section « Accès au compte AWS via Identity Center »), de sorte que les autorisations CLI peuvent être délimitées indépendamment.

En savoir plus : Comment utiliser les rôles d'exécution SageMaker AI

Accès au compte AWS via Identity Center

Au-delà de SageMaker Studio, les équipes ont souvent besoin d'un accès direct au compte AWS pour des opérations CLI telles que l'exécution de commandes kubectl , la création de scripts de flux de travail ou l'accès programmatique aux ressources. Les jeux d'autorisations Identity Center fournissent cette capacité.

Pour le groupe Admin , attribuez un jeu d'autorisations avec un accès administratif conformément aux exigences des politiques de votre entreprise, accordant l'accès au compte nécessaire pour la gestion du cluster et les opérations administratives.

Pour Team A et Team B, créez des jeux d'autorisations avec des politiques en ligne ou gérées qui accordent directement les autorisations nécessaires aux flux de travail CLI. Un jeu d'autorisations d'équipe typique inclut des autorisations pour eks:AccessKubernetesApi (pour visualiser les ressources Kubernetes depuis la console AWS), un accès S3 délimité aux données de l'équipe et un accès en lecture CloudWatch pour la supervision. Ces politiques sont définies indépendamment du rôle d'exécution Studio, de sorte que les administrateurs peuvent adapter les autorisations CLI aux opérations spécifiques que les équipes effectuent depuis la ligne de commande.

Les utilisateurs récupèrent des informations d'identification temporaires via l'AWS Command Line Interface (AWS CLI) à l'aide de aws sso login, qu'ils peuvent ensuite utiliser pour configurer kubectl afin d'interagir directement avec le cluster EKS.

L'image suivante montre les jeux d'autorisations par équipe dans AWS IAM Identity Center, fournissant un accès délimité aux comptes AWS pour les workflows CLI tels que l'exécution de kubectl et de aws sso login sur le cluster EKS.

Figure 4 : Jeux d'autorisations par équipe dans AWS IAM Identity Center pour les workflows CLI

En savoir plus : Gérer des comptes AWS avec des jeux d'autorisations

Configuration de l'AWS CLI

Les membres de l'équipe configurent l'AWS CLI pour s'authentifier via Identity Center en exécutant aws configure sso. Cela crée des profils dans ~/.aws/config qui référencent la session Identity Center et le jeu d'autorisations appropriés. Chaque membre de l'équipe utilise son profil spécifique à son équipe lorsqu'il interagit avec le cluster depuis la ligne de commande, maintenant ainsi les frontières d'autorisation, que l'accès provienne de Studio ou d'un terminal local.

La configuration résultante définit un bloc partagé sso-session pour le portail Identity Center et un profil nommé par équipe, chacun pointant vers le jeu d'autorisations de cette équipe. Les membres de l'équipe exécutent ensuite aws sso login --profile <team> pour obtenir des informations d'identification temporaires limitées à leur jeu d'autorisations :

[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

En savoir plus : Configuration de l'authentification IAM Identity Center avec l'AWS CLI

Domaines SageMaker AI

Les domaines SageMaker AI fournissent la frontière d'espace de travail pour chaque équipe, offrant une expérience utilisateur adaptée, des rôles d'exécution préconfigurés et une intégration native avec l'authentification Identity Center.

Pourquoi les domaines SageMaker AI

L'utilisation d'un domaine SageMaker AI par équipe est un modèle bien établi pour organiser des environnements multi-équipes. Cette approche offre plusieurs avantages :

• Modèle multi-équipes établi – AWS a largement documenté cette approche pour séparer des lignes métier ou des équipes à l'aide de plusieurs domaines, ce qui en fait une configuration éprouvée et prise en charge.
• Authentification Identity Center native – Chaque domaine peut être configuré avec l'authentification Identity Center, ce qui signifie que les utilisateurs se connectent une seule fois via leur fournisseur d'identité d'entreprise et arrivent directement dans l'environnement Studio de leur équipe.
• Configuration d'équipe intégrée – Les domaines fournissent déjà des mécanismes pour spécifier des configurations pour les utilisateurs et les équipes sans nécessiter d'entités personnalisées supplémentaires. Par exemple, des paramètres tels que le rôle d'exécution de l'équipe peuvent être spécifiés au niveau du domaine et remplacés au niveau du profil utilisateur pour une flexibilité maximale.
• Personnalisation de la navigation – Avec les paramètres de domaine, les administrateurs peuvent masquer les éléments de navigation qui ne sont pas pertinents pour les flux de travail de l'équipe, présentant ainsi une interface épurée adaptée aux cas d'usage de HyperPod.

En savoir plus : Entités de domaine et statuts de SageMaker AI · Vue d'ensemble de plusieurs domaines

Configuration des domaines par équipe

Créez un domaine SageMaker AI par équipe avec l'authentification Identity Center. Dans notre exemple, nous créons TeamA-domain et TeamB-domain. Chaque domaine est configuré comme suit :

1. Rôle d'exécution par défaut – Définissez le rôle d'exécution par défaut du domaine sur le rôle IAM spécifique à l'équipe créé lors de l'étape d'autorisation. Toutes les actions effectuées via Studio héritent ainsi des autorisations appropriées.
2. Affectation de groupe dans Identity Center – Ajoutez le groupe Identity Center correspondant (par exemple, le TeamA au domaine. Cela active l'application SageMaker Studio pour tous les membres de ce groupe, leur donnant accès à l'interface Studio.
3. Vérification de l'affectation des applications – Après avoir configuré l'accès des groupes, vérifiez l'attribution des applications dans Identity Center pour confirmer que les bons groupes sont mappés aux bons domaines.
4. Personnalisation de la navigation « – Configurez les paramètres de navigation par défaut de chaque domaine pour ne présenter que les fonctionnalités pertinentes. Par exemple, vous pouvez masquer les éléments sans rapport avec les workflows HyperPod, offrant ainsi une expérience simplifiée » Axé sur HyperPod expérience utilisateur qui réduit la charge cognitive pour les membres de l'équipe qui n'ont besoin de travailler qu'avec les ressources HyperPod.

L'image suivante montre la console SageMaker AI avec un domaine par équipe («TeamA-domain et TeamB-domain»), chacun fournissant une limite d'espace de travail isolée.

Figure 5 : Un domaine SageMaker par équipe dans la console SageMaker

Ensuite, l'image suivante montre les détails de TeamA-domain, y compris les groupes Identity Center attribués.

Figure 6 : configuration du domaine TeamA avec ses groupes Identity Center assignés

Configuration du cluster EKS HyperPod

Le cluster HyperPod EKS est l'endroit où les charges de travail sont exécutées. Le multi-locataire au niveau du cluster est obtenu grâce aux espaces de noms Kubernetes pour l'isolation et aux entrées d'accès EKS pour l'autorisation.

Isolation par espace de noms

Créez un namespace Kubernetes dédié pour chaque équipe, par exemple hyperpod-ns-team-a et hyperpod-ns-team-b. Les namespaces fournissent une frontière logique au sein du cluster, isolant les workloads de chaque équipe (Spaces, tâches d'entraînement, endpoints d'inférence) les uns des autres.

Remarque : les namespaces constituent une frontière d'isolation, pas une frontière de sécurité stricte. Cette architecture cible le scénario multi-équipe au sein d'une même organisation: des équipes qui partagent un cluster sous un domaine administratif commun et une base de confiance mutuelle. Elle n'est pas conçue pour l'isolation multi-client , c'est-à-dire entre des locataires qui ne se font pas confiance.

Les namespaces, le RBAC et les quotas préviennent les interférences accidentelles (des équipes écrasant les ressources des autres ou dépassant leur allocation de calcul) mais ne constituent pas une défense contre un locataire malveillant résolu : les pods dans les namespaces partagent les mêmes nœuds et le même noyau, et les ressources à portée de cluster (nœuds, PersistentVolumes, CRD, certains composants d'opérateur) se trouvent en dehors de tout namespace.

Pour des locataires non fiables ou une isolation réglementaire stricte, utilisez des frontières plus fortes telles que des clusters ou des comptes séparés, des pools de nœuds dédiés et le sandboxing à l'exécution. Pour le scénario multi-équipe présenté ici, l'isolation par namespace combinée au RBAC, aux quotas de Task Governance et aux contrôles d'identité POSIX décrits plus loin offre un équilibre approprié entre séparation et simplicité opérationnelle.

Les namespaces peuvent être créés manuellement avec kubectl create namespace ou provisionnés automatiquement via HyperPod Task Governance, qui gère les namespaces dans le cadre de sa configuration de quotas et d'ordonnancement.

L'image suivante montre les namespaces du cluster (gérés avec HyperPod Task Governance), avec un namespace dédié par équipe (hyperpod-ns-team-a et hyperpod-ns-team-b) assurant l'isolation des workloads.

Figure 7 : Namespace Kubernetes dédié par équipe pour l'isolation des workloads

En savoir plus : Namespaces Kubernetes

Isolation réseau

Les namespaces ne restreignent pas le trafic réseau. Par défaut, la mise en réseau Kubernetes est plate : chaque pod peut joindre tous les autres pods dans tous les namespaces. Par conséquent, un pod dans hyperpod-ns-team-a peut ouvrir une connexion vers un pod dans hyperpod-ns-team-b à moins que vous n'ajoutiez des contrôles. Pour délimiter l'accessibilité pod à pod selon les frontières des équipes, utilisez les ressources Kubernetes NetworkPolicy .

Le modèle recommandé est default-deny par namespace : commencez par refuser tout ingress (et éventuellement egress), puis autorisez explicitement le trafic dont chaque équipe a besoin, généralement la communication intra-namespace plus l'egress requis comme le DNS, les endpoints de stockage et les API AWS. L'exemple suivant refuse tout ingress dans le namespace d'une équipe, puis n'autorise le trafic que depuis les pods du même 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 L'application dépend d'une interface réseau de conteneurs (CNI) qui la prend en charge. Sur EKS, vous pouvez activer la prise en charge des politiques réseau dans le CNI d'Amazon Virtual Private Cloud (Amazon VPC).

Comme pour les namespaces, NetworkPolicies réduire accidentel la portée inter-équipes et réduire le périmètre, mais elles ne constituent pas en elles-mêmes une frontière de sécurité face aux adversaires sur des nœuds partagés. Pour une séparation plus forte, envisagez des pools de nœuds dédiés par équipe ou des clusters séparés, comme indiqué précédemment.

En savoir plus : Politiques réseau Kubernetes · Politique réseau Amazon VPC CNI

Entrées d'accès EKS

Les entrées d'accès EKS connectent les principaux IAM aux permissions RBAC Kubernetes. Pour chaque équipe, créez deux entrées d'accès :

• Entrée d'accès Studio – Le principal IAM est le rôle d'exécution du domaine SageMaker AI de l'équipe. Cette entrée est utilisée lorsque les actions proviennent de l'interface graphique de SageMaker Studio.
• Entrée d'accès CLI – Le principal IAM est le rôle provisionné par SSO créé par Identity Center pour le jeu d'autorisations de l'équipe (selon le modèle AWSReservedSSO_<permission-set-name>_<unique-id>). Cette entrée est utilisée lorsque les utilisateurs interagissent avec le cluster via kubectl.

Les deux entrées sont limitées à l'espace de noms de l'équipe avec des politiques Kubernetes gérées ou personnalisées. Par exemple, les deux entrées de l'équipe A accordent des permissions uniquement dans hyperpod-ns-team-a. Les deux entrées peuvent comporter des politiques RBAC différentes si vous le souhaitez. Par exemple, l'entrée CLI peut restreindre l'accès en écriture à certains types de ressources tandis que l'entrée Studio autorise un accès complet.

Avec ce périmètre, que l'accès provienne de Studio ou de la CLI, les utilisateurs ne peuvent interagir qu'avec les ressources de leur propre espace de noms. Toute tentative de lister ou de modifier des ressources dans l'espace de noms d'une autre équipe génère une erreur Kubernetes Forbidden .

Pour des scénarios plus avancés, vous pouvez utiliser des groupes Kubernetes dans l'entrée d'accès pour associer les utilisateurs à des ClusterRoles ou Roles personnalisés offrant des permissions à granularité fine au-delà des politiques gérées standard.

L'image suivante montre une entrée d'accès EKS pour le rôle de l'équipe B, limitée à l'espace de noms hyperpod-ns-team-b, de sorte que ses permissions s'appliquent uniquement dans l'espace de noms de l'équipe B.

Figure 8 : Entrée d'accès EKS limitée à l'espace de noms de l'équipe B

En savoir plus : Accorder aux utilisateurs IAM l'accès à Kubernetes avec les entrées d'accès EKS

Gouvernance des tâches HyperPod

Lorsque la gouvernance des tâches (Task Governance) est activée sur le cluster, elle fournit une couche supplémentaire de gestion des ressources :

• Quotas de calcul – Définissez la capacité GPU et CPU que chaque équipe peut consommer. Cela empêche une seule équipe de monopoliser le matériel partagé lors des exécutions d'entraînement.
• Priorités – Attribuez des priorités de planification à chaque équipe ou type de charge de travail, permettant aux charges de travail d'inférence de production critiques de préempter les tâches d'entraînement expérimentales lorsque les ressources sont limitées.
• Ordonnancement équitable – Avec la gouvernance des tâches, lorsque plusieurs équipes se disputent les ressources, l'allocation suit les politiques configurées plutôt qu'un modèle premier arrivé, premier servi.

Configurez la gouvernance des tâches avec des quotas et des priorités appropriés par espace de noms d'équipe, en équilibrant les allocations minimales garanties et la capacité de crue pour les charges de travail intermittentes.

L'image suivante montre les allocations de calcul de la gouvernance des tâches pour les deux équipes, chaque espace de noms d'équipe se voyant attribuer son propre quota de capacité de calcul du cluster.

Figure 9 : Allocations de calcul de la gouvernance des tâches par espace de noms d'équipe

En savoir plus : Gouvernance des tâches SageMaker HyperPod

Stockage

Le stockage est un composant essentiel des environnements d'intelligence artificielle et d'apprentissage automatique (IA/ML) partagés entre plusieurs équipes. Les équipes ont besoin de systèmes de fichiers performants pour les données d'entraînement, les points de contrôle et les artefacts de modèles, tout en maintenant des limites d'accès appropriées entre les équipes.

Systèmes de fichiers conformes POSIX

Pour les charges de travail nécessitant un système de fichiers POSIX partagé et performant (courant pour l'entraînement distribué où plusieurs nœuds lisent le même jeu de données ou écrivent des points de contrôle), envisagez les options suivantes :

• Amazon FSx for Lustre – Fournit un accès à un système de fichiers parallèle à haut débit et à faible latence, idéal pour les charges de travail d'entraînement à grande échelle qui doivent lire de grands ensembles de données à grande vitesse.
• Amazon FSx for OpenZFS – Offre un système de fichiers à usage général avec une sémantique POSIX robuste, des instantanés et la compression. Particulièrement adapté aux charges de travail nécessitant des fonctionnalités traditionnelles de système de fichiers en plus de hautes performances.
• Amazon Elastic File System (Amazon EFS) – Fournit un stockage NFS (Network File System) élastique et entièrement géré. EFS prend également en charge les points d'accès, qui peuvent simplifier l'isolation des répertoires par équipe en associant différents points de montage à différents répertoires avec des UID et des GID appliqués.

La disposition du stockage suit généralement cette structure :

• Répertoires partagés par équipe – Chaque équipe dispose d'un répertoire partagé (par exemple, /fsx/TeamA, /fsx/TeamB) pour les jeux de données, les modèles et les artefacts auxquels tous les membres de l'équipe doivent avoir accès.
• Répertoires personnels par utilisateur – Chaque utilisateur dispose d'un répertoire personnel (par exemple, /home/User1, /home/User2) pour le travail individuel, les expériences et les notebooks.

Le modèle de permissions POSIX sur ces systèmes de fichiers repose sur les UID, les GID et les groupes supplémentaires pour appliquer les limites d'accès. Ces identités POSIX doivent ensuite être propagées au contexte de sécurité du pod lorsqu'un utilisateur lance un HyperPod Space ou soumet une tâche d'entraînement, afin que l'accès au système de fichiers respecte la propriété et les permissions configurées. Nous recommandons d'utiliser un webhook d'admission mutante Kubernetes pour récupérer les informations d'identité POSIX à partir de votre magasin d'identités. Lorsqu'une charge de travail est soumise, le webhook recherche l'identité au moment de l'exécution et modifie en conséquence le contexte de sécurité du Pod.

# 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"][0]

# 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"],
        },
    }]

En savoir plus : FSx for Lustre · FSx for OpenZFS · Amazon EFS

Stockage Amazon S3

Pour le stockage d'objets, l'accès aux buckets S3 est régi par le rôle d'exécution IAM de l'équipe. Vous pouvez créer des buckets par équipe ou utiliser un bucket partagé avec des préfixes par équipe, en vous appuyant sur des stratégies IAM pour appliquer l'isolation. Les pods au sein du cluster ont besoin de comptes de service correctement configurés avec IAM Roles for Service Accounts (IRSA) ou Pod Identity pour s'authentifier auprès de S3. Par simplicité, vous pouvez associer le même rôle d'exécution configuré sur le domaine SageMaker AI à un compte de service Kubernetes dans l'espace de noms de l'équipe, offrant ainsi un accès S3 cohérent depuis Studio et les charges de travail du cluster.

En savoir plus : IAM roles for service accounts (IRSA) · EKS Pod Identity

HyperPod Spaces

HyperPod Spaces fournit des environnements de développement interactifs (IDE) s'exécutant directement sur les nœuds du cluster. Sur un cluster partagé, les Spaces doivent être correctement délimités à l'espace de noms de chaque équipe et configurés avec des modèles de ressources appropriés.

Modèles de Space

Créez des modèles de Space délimités à l'espace de noms pour chaque équipe. Ces modèles définissent les configurations de ressources (types d'instances, volumes de stockage, variables d'environnement) disponibles pour les membres de l'équipe lors de la création de Spaces. En délimitant les modèles à un espace de noms, vous vous assurez que chaque équipe ne peut lancer des que Spaces dans sa limite désignée.

Lorsque HyperPod Task Governance est activé, les modèles doivent inclure les libellés par défaut requis par le système de gouvernance (tels que les identifiants d'équipe et les libellés de priorité). L'administrateur du cluster préconfigure ces libellés afin que les membres de l'équipe n'aient pas besoin de les spécifier manuellement lors du lancement de Spaces.

L'exemple suivant montre un modèle de Space JupyterLab délimité à l'équipe A. Les parties spécifiques à l'équipe sont metadata.namespace, le libellé de file d'attente Task Governance sous baseLabels, et les defaultVolumes qui montent le système de fichiers partagé de l'équipe et le répertoire personnel de l'utilisateur :

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
  ...

Revendications de volumes persistants

Créez les revendications de volumes persistants (PVC) appropriées dans l'espace de noms de chaque équipe, en référençant le système de fichiers partagé. Ces PVC montent le répertoire partagé de l'équipe et le répertoire personnel de l'utilisateur dans le Space, offrant ainsi un accès aux données d'entraînement, aux checkpoints et aux espaces de travail personnels.

Spaces privés (propriétaire uniquement) et Spaces partagés

Tenez compte des exigences de votre organisation concernant le partage de Spaces :

• Spaces réservés au propriétaire – Chaque Space n'est accessible que par l'utilisateur qui l'a créé. Il s'agit de la configuration par défaut, appropriée lorsque les équipes travaillent sur des projets sensibles ou indépendants.
• Spaces partagés – Plusieurs membres de l'équipe peuvent accéder au même Space, ce qui est utile pour la programmation en binôme, le débogage collaboratif ou les environnements de développement partagés. Lors de l'activation des Spaces partagés, assurez-vous que les permissions POSIX et les groupes supplémentaires sont configurés pour permettre l'accès approprié aux fichiers créés dans le Space.

En savoir plus : Interactive development environments on Amazon SageMaker HyperPod EKS clusters

Expérience Studio

Bien que les équipes puissent interagir avec le cluster entièrement depuis la CLI en utilisant kubectl, SageMaker Studio offre un point d'entrée graphique vers le cluster pour les utilisateurs qui préfèrent un flux de travail géré et piloté par GUI. Dans cette architecture, chaque équipe accède à Studio via son propre domaine SageMaker AI (comme décrit précédemment), en se connectant avec les mêmes identifiants Identity Center et en opérant dans les limites de l'espace de noms de l'équipe.

L'image suivante montre le portail d'accès IAM Identity Center que les utilisateurs atteignent après s'être connectés avec leurs identifiants d'entreprise, offrant un accès par authentification unique (SSO) à leurs applications SageMaker Studio et applications Amazon Managed Grafana qui leur sont assignées.

Figure 10 : Portail d'accès IAM Identity Center avec authentification unique (SSO) vers les applications assignées

Depuis l'interface utilisateur de Studio, les membres de l'équipe peuvent :

• Gérer les HyperPod Spaces – Lancer des environnements de développement interactifs à partir des modèles de Space délimités par namespace configurés par l'administrateur, sans écrire de manifestes Kubernetes ni spécifier manuellement les étiquettes Task Governance. Les membres de l'équipe peuvent également démarrer, arrêter et se connecter à leurs Spaces en cours d'exécution, en ouvrant l'IDE associé (tel que JupyterLab) directement dans le navigateur.
• Gérer les charges de travail Ray – Créer et surveiller des clusters Ray, connecter un espace de travail JupyterLab ou Code Editor à un cluster, soumettre des travaux distribués et ouvrir le Ray Dashboard et les tableaux de bord d'observabilité Amazon Managed Grafana, le tout sans écrire de manifestes Kubernetes ni exécuter de kubectl commandes.

Comme Studio opère via le rôle d'exécution Domain de l'équipe et l'entrée d'accès EKS correspondante, toutes les actions sont délimitées au namespace de l'équipe. Un utilisateur lançant un Space ou un cluster Ray depuis Studio ne peut le créer qu'au sein des limites de sa propre équipe, conformément au modèle d'isolation appliqué pour l'accès CLI.

L'image suivante montre comment créer un HyperPod Space depuis l'interface utilisateur de SageMaker Studio, où un membre de l'équipe sélectionne un modèle de Space délimité par namespace sans écrire de manifestes Kubernetes ni spécifier manuellement les étiquettes Task Governance.

Figure 11 : Création d'un HyperPod Space à partir d'un modèle délimité par namespace dans SageMaker Studio

En savoir plus : Environnements de développement interactifs sur les clusters EKS Amazon SageMaker HyperPod · Présentation des nouvelles capacités Ray sur SageMaker HyperPod

HyperPod Training Operator

Le HyperPod Training Operator permet aux équipes de soumettre des tâches d'entraînement distribuées en tant que ressources personnalisées Kubernetes (par exemple, HyperPodPyTorchJob). Dans l'architecture mutualisée, les tâches d'entraînement sont limitées à un espace de noms, ce qui signifie qu'elles héritent automatiquement des frontières d'isolation de l'équipe.

Les équipes peuvent soumettre des tâches d'entraînement depuis la CLI à l'aide de kubectl apply avec le manifeste de tâche approprié. La tâche s'exécute dans l'espace de noms de l'équipe, utilise les quotas de calcul de l'équipe (si Task Governance est activé) et a accès aux volumes de stockage de l'équipe.

Lorsque Task Governance est activé, les tâches d'entraînement sont soumises aux quotas alloués et aux paramètres de priorité de l'équipe. Si une équipe a consommé son allocation garantie, les tâches peuvent être mises en file d'attente jusqu'à ce que des ressources soient disponibles ou que des charges de travail de priorité inférieure soient préemptées.

Les deux éléments qui rattachent une tâche à une équipe sont metadata.namespace (qui limite la tâche à la frontière d'isolation de l'équipe) et les étiquettes Task Governance. Task Governance est construit sur Kueue, de sorte que la tâche est acheminée vers la file d'attente locale de l'équipe via kueue.x-k8s.io/queue-name. Une priorité de planification lui est attribuée via kueue.x-k8s.io/priority-class, dont la valeur est le nom d'un WorkloadPriorityClass défini sur le 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.
  ...

En savoir plus : Utilisation de l'opérateur d'entraînement HyperPod

HyperPod Inference Operator

Le HyperPod Inference Operator permet aux équipes de déployer des modèles en tant que points de terminaison d'inférence directement sur le cluster. Semblables aux tâches d'entraînement, les points de terminaison d'inférence sont limités à un espace de noms et soumis aux politiques RBAC de l'équipe et aux quotas Task Governance.

Les équipes peuvent déployer des modèles depuis la CLI en créant des ressources personnalisées de points de terminaison d'inférence dans leur espace de noms. Les points de terminaison sont isolés par espace de noms, ce qui signifie que l'équipe A ne peut pas accéder aux points de terminaison d'inférence de l'équipe B ni les perturber.

Pour les charges de travail d'inférence en production nécessitant une haute disponibilité, envisagez d'attribuer une priorité de planification plus élevée aux points de terminaison d'inférence qu'aux tâches d'entraînement, afin que le service des modèles ne soit pas interrompu par les charges de travail d'entraînement par lots.

Comme pour les tâches d'entraînement, le point de terminaison d'inférence est placé dans metadata.namespace de l'équipe et porte les étiquettes Task Governance. Ici, kueue.x-k8s.io/priority-class référence un WorkloadPriorityClass de priorité plus élevée afin que le service des modèles puisse préempter l'entraînement par lots lorsque les ressources de l'équipe sont limitées :

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.
  ...

En savoir plus : Déploiement de modèles sur Amazon SageMaker HyperPod

HyperPod Observability

La visibilité sur la santé du cluster, les performances des charges de travail et l'utilisation des ressources est essentielle pour toutes les équipes. HyperPod Observability fournit des capacités de surveillance et de tableaux de bord intégrées via Amazon Managed Grafana.

Configuration de l'accès des équipes à Grafana

Les équipes ont besoin d'un accès aux tableaux de bord d'observabilité pour surveiller leurs charges de travail, résoudre les problèmes de performance et comprendre la consommation des ressources. Cependant, dans un environnement mutualisé, cet accès doit généralement être en lecture seule :

1. Configurer l'authentification Identity Center pour Amazon Managed Grafana – Dans la console Amazon Managed Grafana, accédez à Authentication et activez AWS IAM Identity Center. Les utilisateurs peuvent alors se connecter à Grafana avec les mêmes identifiants d'entreprise qu'ils utilisent pour SageMaker Studio.
2. Attribuer les groupes d'équipes en tant que Viewers – Mappez les groupes Identity Center (TeamA, TeamB) au rôle Viewer de Grafana. Cela accorde aux membres de l'équipe un accès en lecture seule aux tableaux de bord et aux métriques, sans possibilité de modifier les tableaux de bord ou les sources de données.
3. Accès administrateur – Attribuez le groupe Admin au rôle Admin ou Editor de Grafana, afin qu'il puisse créer et modifier des tableaux de bord, configurer les alertes et gérer les sources de données.
4. Tableaux de bord propres à chaque équipe – Envisagez de créer des tableaux de bord dédiés qui filtrent les données par namespace, afin que chaque équipe ne voie que les métriques de sa propre charge de travail. Amazon Managed Grafana prend en charge Grafana Teams (un concept RBAC natif de Grafana, distinct des équipes organisationnelles dans cette architecture), qui peuvent être mappés à partir des groupes Identity Center pour restreindre la visibilité des tableaux de bord et fournir une couche supplémentaire d'isolation des données.

L'image suivante montre les attributions de rôles Grafana dans Amazon Managed Grafana. Les groupes d'équipes (TeamA, TeamB) se voient attribuer le rôle Viewer pour un accès en lecture seule aux tableaux de bord et aux métriques, tandis que le groupe administrateur se voit attribuer le rôle Admin, lui donnant la possibilité de créer et de modifier des tableaux de bord, de configurer les alertes et de gérer les sources de données.

Figure 12 : attributions de rôles Grafana accordant aux équipes un accès Viewer en lecture seule

En savoir plus : Observabilité pour un cluster Amazon SageMaker HyperPod orchestré par Amazon EKS

Répartition des coûts et refacturation

Dans un environnement multi-tenant où les équipes partagent une infrastructure GPU coûteuse, comprendre qui consomme quoi est essentiel pour la responsabilisation, la budgétisation et le refacturation des coûts. Kubecost répond à ce besoin en décomposant les dépenses au sein du cluster selon les concepts natifs de Kubernetes (namespace, label, deployment et service) et en les associant à des concepts organisationnels comme l'équipe, le projet ou l'environnement.

Parce que cette architecture isole déjà chaque équipe dans un espace de noms dédié (hyperpod-ns-team-a, hyperpod-ns-team-b), l'allocation des coûts au niveau du namespace s'aligne directement sur les limites des équipes. Cela offre aux administrateurs de plateforme une vue claire par équipe de la consommation de GPU, CPU, mémoire, stockage et réseau, sans aucun étiquetage supplémentaire des workloads. Pour des instructions étape par étape sur le déploiement et la configuration de Kubecost sur un cluster HyperPod, consultez Kubecost sur SageMaker HyperPod.

Activer la visibilité de l'équipe

Une fois que Kubecost collecte des données, regroupez les coûts par namespace dans le tableau de bord Allocations pour voir les dépenses par équipe. Comme chaque équipe possède un namespace, cela produit directement une répartition des coûts par équipe couvrant le calcul, la mémoire, le stockage et le réseau. Comme pour les tableaux de bord d'observabilité, les équipes bénéficient d'une visibilité sur leurs propres données de coûts :

• Vues de périmètre vers l'espace de noms de chaque équipe – Kubecost prend en charge le filtrage et les rapports enregistrés par namespace, de sorte que chaque équipe peut consulter sa propre consommation et ses tendances sans voir les données des autres équipes.
• Définir des budgets et des alertes « – Configurez des seuils budgétaires et des alertes par namespace, afin que les équipes et les administrateurs de plateforme soient avertis lorsque les dépenses approchent des limites définies, soutenant les mêmes objectifs d'équité de ressources que HyperPod Task Governance. »
• Prise en charge du chargeback et du showback – Les rapports d'allocation au niveau des namespaces peuvent alimenter des processus internes de chargeback (facturation des équipes pour leur utilisation) ou de showback (rapport d'utilisation sans facturation), donnant aux équipes financières et aux équipes de plateforme les données dont elles ont besoin pour attribuer équitablement les coûts partagés des GPU.

L'image suivante montre le tableau de bord Allocations de Kubecost regroupé par namespace, affichant le coût cumulé sur les 7 derniers jours pour le namespace de chaque équipe.

Figure 13 : Tableau de bord des allocations Kubecost regroupé par namespace pour le coût par équipe

En savoir plus : Kubecost sur SageMaker HyperPod · Kubecost

Conclusion

Ce billet présentait une architecture de référence pour construire des environnements multi-locataires sur Amazon SageMaker HyperPod avec EKS. En combinant AWS IAM Identity Center pour l'authentification, des rôles IAM par équipe pour l'autorisation au niveau AWS, des domaines SageMaker AI pour une expérience d'espace de travail sur mesure, des espaces de noms Kubernetes pour l'isolation des charges de travail, HyperPod Task Governance pour une allocation équitable des ressources et une répartition des coûts au niveau des espaces de noms pour la visibilité des dépenses par équipe, plusieurs équipes peuvent partager efficacement un seul cluster HyperPod EKS.

Il s'agit d'une approche flexible et composable qui combine plusieurs blocs de construction en une solution cohérente. L'architecture s'adapte à une variété de cas d'utilisation et de structures organisationnelles. Par exemple, les organisations peuvent étendre ce modèle pour connecter des équipes à des clusters HyperPod Slurm en plus d'EKS, offrant ainsi une expérience mutualisée unifiée à travers différents moteurs d'orchestration.

Bien que cette approche nécessite l'assemblage et la configuration de plusieurs composants, le résultat offre un degré élevé de contrôle et de personnalisation qui peut être adapté aux exigences spécifiques de chaque organisation en matière d'isolation, de conformité et d'exploitation. Les modèles fondamentaux (fédération d'identité, isolation des espaces de noms, RBAC, gouvernance basée sur les quotas et répartition des coûts) resteront applicables.

Pour commencer, essayez de construire cette configuration multi-tenant sur votre propre cluster Amazon SageMaker HyperPod EKS, et adaptez les éléments de base aux exigences de votre organisation en matière d'isolation, de gouvernance et d'allocation des coûts.

À propos des auteurs