O problema: múltiplas equipes, um cluster caro
Clusters de GPU são investimentos significativos. Dentro de uma mesma organização, é comum que várias equipes — de ciência de dados, visão computacional, pesquisa em arquiteturas de modelos — precisem acessar a mesma infraestrutura ao mesmo tempo. Sem uma arquitetura bem pensada para esse cenário multi-tenant (multi-equipe), o resultado costuma ser caótico: consumo descontrolado de recursos, sem isolamento entre times, sem como atribuir os custos de GPU a quem realmente os gerou, e sobrecarga administrativa que freia a inovação.
Para endereçar esse desafio, a AWS publicou uma arquitetura de referência detalhada para construir ambientes multi-tenant no Amazon SageMaker HyperPod com Amazon Elastic Kubernetes Service (EKS). O HyperPod é um serviço de IA projetado especificamente para gerenciar clusters de computação em larga escala para cargas de trabalho de IA generativa, com monitoramento de saúde dos nós, recuperação automática de falhas e gerenciamento do ciclo de vida do cluster.
Visão geral da arquitetura
A arquitetura proposta pela AWS organiza o compartilhamento de um único cluster HyperPod EKS entre duas equipes (Equipe A e Equipe B), cada uma operando dentro do seu próprio namespace isolado. O fluxo é estruturado em camadas, conectando a identidade do usuário, passando pelos controles de autorização, até os namespaces de carga de trabalho no cluster.
Os principais blocos que compõem essa solução são:
- AWS IAM Identity Center para autenticação centralizada, com federação para provedores de identidade externos
- Domínios SageMaker AI por equipe para uma experiência de workspace personalizada
- Namespaces Kubernetes para isolamento de cargas de trabalho
- HyperPod Task Governance para alocação justa de recursos de computação
- Alocação de custos por namespace para visibilidade de gastos por equipe
Autenticação e controle de acesso
A fundação de qualquer sistema multi-tenant é uma autenticação robusta. Nessa arquitetura, o AWS IAM Identity Center (sucessor do AWS Single Sign-On) atua como camada centralizada de autenticação, federando com um provedor de identidade externo — no exemplo da AWS, o Microsoft Entra ID (antigo Azure AD), embora o mesmo padrão funcione com qualquer provedor compatível com SAML (Security Assertion Markup Language) 2.0.
A configuração envolve três etapas principais:
- Estrutura de grupos no provedor de identidade: criar grupos que correspondam às equipes organizacionais (TeamA, TeamB, Admin) no Entra ID
- Provisionamento via SCIM (System for Cross-domain Identity Management): sincronização automática de usuários e grupos entre o Entra ID e o IAM Identity Center — quando um novo usuário é adicionado ao grupo TeamA no Entra ID, ele automaticamente ganha acesso sem intervenção manual
- Federação SAML 2.0: quando os usuários se autenticam, fazem isso contra o Entra ID; o Identity Center atua como provedor de serviços, confiando nas asserções do tenant Entra ID
Saiba mais: O que é o IAM Identity Center · Conectar um provedor de identidade externo · Perfil SCIM e implementação SAML 2.0
Autorização: IAM e RBAC do Kubernetes
Com a autenticação estabelecida, o próximo passo é a autorização — controlar o que cada equipe pode fazer nos serviços AWS e no cluster Kubernetes. Essa arquitetura opera em dois níveis: IAM para acesso a serviços AWS e RBAC (Role-Based Access Control — Controle de Acesso Baseado em Funções) do Kubernetes para acesso ao cluster.
Roles IAM por equipe
Cada equipe recebe uma role IAM dedicada, que serve como execution role do domínio SageMaker AI e define quais serviços AWS a equipe pode acessar. Tipicamente, essas políticas incluem acesso ao Amazon SageMaker AI, ao Amazon S3 (com escopo para prefixos de bucket específicos da equipe), ao Amazon CloudWatch para logs e métricas, e ao Amazon EKS para que a interface do SageMaker Studio possa fazer chamadas à API Kubernetes em nome do usuário.
Saiba mais: Como usar execution roles do SageMaker AI
Permission sets no Identity Center para acesso via CLI
Além do SageMaker Studio, as equipes frequentemente precisam de acesso direto à conta AWS para operações de linha de comando, como executar comandos kubectl. O Identity Center oferece permission sets para isso. Os membros de cada equipe configuram o AWS CLI para autenticar via Identity Center usando aws configure sso, o que cria perfis em ~/.aws/config. Um exemplo de configuração resultante:
[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-2Saiba mais: Gerenciar contas AWS com permission sets · Configurando autenticação do IAM Identity Center com o AWS CLI
Domínios SageMaker AI por equipe
Os domínios SageMaker AI fornecem o limite de workspace para cada equipe. A AWS recomenda criar um domínio por equipe — um padrão bem estabelecido para organizar ambientes multi-team. Cada domínio é configurado com a execution role específica da equipe e com autenticação via Identity Center, permitindo que os usuários façam login uma única vez pelo provedor de identidade corporativo e cheguem diretamente ao ambiente Studio da sua equipe.
Administradores também podem personalizar a navegação de cada domínio, ocultando itens irrelevantes para os fluxos de trabalho do HyperPod e reduzindo a sobrecarga cognitiva para os membros da equipe.
Saiba mais: Entidades e status de domínios SageMaker AI · Visão geral de múltiplos domínios
Isolamento no cluster HyperPod EKS
Namespaces Kubernetes
No nível do cluster, o isolamento é obtido por meio de namespaces Kubernetes dedicados por equipe — por exemplo, hyperpod-ns-team-a e hyperpod-ns-team-b. Os namespaces criam uma fronteira lógica que isola as cargas de trabalho de cada equipe (Spaces, jobs de treinamento, endpoints de inferência) umas das outras.
É importante notar, conforme a própria AWS ressalta, que namespaces são uma fronteira de isolamento, não uma fronteira de segurança rígida. Essa arquitetura é voltada para equipes dentro de uma mesma organização, que compartilham um cluster sob um domínio administrativo comum e um nível básico de confiança mútua. Para isolamento entre tenants completamente desconfiados ou com requisitos regulatórios rígidos, a recomendação é usar fronteiras mais fortes, como clusters ou contas separadas.
Saiba mais: Namespaces Kubernetes
Isolamento de rede
Por padrão, a rede Kubernetes é plana: qualquer pod pode se comunicar com qualquer outro pod em todos os namespaces. Para restringir o tráfego entre equipes, a AWS recomenda usar recursos NetworkPolicy do Kubernetes com o padrão de negar tudo por default em cada namespace e depois permitir explicitamente o tráfego necessário. O exemplo abaixo nega todo ingresso no namespace da equipe e depois permite tráfego apenas de pods dentro do mesmo 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 namespaceSaiba mais: Network policies Kubernetes · Network policy do Amazon VPC CNI
Access entries do EKS
Os access entries do EKS conectam principals IAM às permissões RBAC do Kubernetes. Para cada equipe, são criadas duas entradas: uma para o acesso via SageMaker Studio (usando a execution role do domínio) e outra para o acesso via CLI (usando a role provisionada pelo Identity Center para o permission set). Ambas as entradas são escopadas ao namespace da equipe, garantindo que — independentemente de o acesso vir do Studio ou do terminal — os usuários só interajam com recursos do seu próprio namespace.
Saiba mais: Conceder acesso a usuários IAM ao Kubernetes com EKS access entries
HyperPod Task Governance: cotas e prioridades
Quando habilitado no cluster, o HyperPod Task Governance adiciona uma camada de gerenciamento de recursos com três capacidades principais:
- Cotas de computação: define quanto de capacidade de GPU e CPU cada equipe pode consumir, evitando que uma única equipe monopolize o hardware compartilhado
- Prioridades: permite atribuir prioridades de escalonamento por equipe ou tipo de carga de trabalho, de forma que endpoints de inferência em produção possam preemptar jobs de treinamento experimentais quando os recursos estiverem escassos
- Escalonamento justo: quando múltiplas equipes competem por recursos, a alocação segue as políticas configuradas em vez do modelo primeiro-a-chegar-primeiro-a-ser-atendido
O Task Governance é construído sobre o Kueue, e os jobs são roteados para a fila local da equipe via kueue.x-k8s.io/queue-name.
Saiba mais: Task governance do SageMaker HyperPod
Armazenamento: sistemas de arquivos e S3
Sistemas de arquivos compatíveis com POSIX
Para cargas de trabalho de treinamento distribuído que exigem um sistema de arquivos de alto desempenho compartilhado, a AWS sugere três opções:
- Amazon FSx for Lustre: sistema de arquivos paralelo de alta taxa de transferência e baixa latência, ideal para treinamentos em larga escala
- Amazon FSx for OpenZFS: sistema de arquivos de uso geral com semântica POSIX robusta, snapshots e compressão
- Amazon Elastic File System (EFS): armazenamento NFS (Network File System) totalmente gerenciado e elástico, com suporte a access points para isolamento de diretórios por equipe
O layout típico de armazenamento inclui diretórios compartilhados por equipe (ex: /fsx/TeamA, /fsx/TeamB) e diretórios home por usuário (ex: /home/User1, /home/User2). As permissões POSIX nesses sistemas de arquivos dependem de UIDs, GIDs e grupos suplementares para reforçar as fronteiras de acesso. A AWS recomenda usar um webhook de admissão mutante do Kubernetes para recuperar informações de identidade POSIX do repositório de identidades e injetar automaticamente no contexto de segurança do Pod quando uma carga de trabalho é submetida:
# 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"],
},
}]Saiba mais: FSx for Lustre · FSx for OpenZFS · Amazon EFS
Amazon S3
Para armazenamento de objetos, o acesso aos buckets S3 é governado pela execution role IAM da equipe. É possível criar buckets por equipe ou usar um bucket compartilhado com prefixos por equipe, dependendo das políticas IAM para reforçar o isolamento. Os pods dentro do cluster precisam de service accounts configurados com IRSA (IAM Roles for Service Accounts) ou EKS Pod Identity para autenticar no S3.
HyperPod Spaces, treinamento e inferência
Spaces para desenvolvimento interativo
Os HyperPod Spaces fornecem ambientes de desenvolvimento interativo (IDEs) rodando diretamente nos nós do cluster. Em um cluster compartilhado, os Spaces devem ser escopados ao namespace de cada equipe por meio de templates de Space com escopo de namespace. Um exemplo de template para JupyterLab da Equipe A:
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 ...Saiba mais: Ambientes de desenvolvimento interativo no Amazon SageMaker HyperPod EKS
Jobs de treinamento distribuído
O HyperPod Training Operator permite que equipes submetam jobs de treinamento distribuído como recursos customizados do Kubernetes (HyperPodPyTorchJob). Os jobs são escopados ao namespace da equipe e sujeitos às cotas e prioridades do Task Governance. Os dois elementos que ancoram um job a uma equipe são o metadata.namespace e os labels do Task Governance:
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. ...Saiba mais: Usando o HyperPod training operator
Endpoints de inferência
O HyperPod Inference Operator permite que equipes façam deploy de modelos como endpoints de inferência diretamente no cluster. Assim como os jobs de treinamento, os endpoints são escopados por namespace. Para cargas de inferência em produção que exigem alta disponibilidade, a AWS recomenda atribuir prioridade de escalonamento mais alta aos endpoints de inferência do que aos jobs de treinamento em lote:
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. ...Saiba mais: Deploy de modelos no Amazon SageMaker HyperPod
Observabilidade com Amazon Managed Grafana
O HyperPod Observability oferece capacidades de monitoramento e dashboards integrados via Amazon Managed Grafana. Para o cenário multi-tenant, o acesso das equipes ao Grafana deve ser configurado como somente leitura: os grupos TeamA e TeamB recebem a role Viewer, enquanto o grupo Admin recebe a role Admin ou Editor. O Amazon Managed Grafana usa o IAM Identity Center como mecanismo de autenticação, permitindo que os usuários acessem o Grafana com as mesmas credenciais corporativas que usam para o SageMaker Studio.
A AWS também recomenda criar dashboards dedicados que filtrem dados por namespace, de forma que cada equipe veja apenas as métricas das suas próprias cargas de trabalho.
Saiba mais: Observabilidade para clusters Amazon SageMaker HyperPod orquestrados pelo Amazon EKS
Alocação de custos e chargeback
Em um ambiente onde equipes compartilham infraestrutura cara de GPU, saber quem consome o quê é essencial para accountability, orçamento e chargeback. A AWS indica o Kubecost para essa necessidade, pois ele quebra os gastos dentro do cluster em conceitos nativos do Kubernetes (namespace, label, deployment, serviço) e os mapeia para conceitos organizacionais como equipe, projeto ou ambiente.
Como a arquitetura já isola cada equipe em um namespace dedicado, a alocação de custos por namespace se alinha diretamente com as fronteiras das equipes, dando aos administradores uma visão clara de consumo de GPU, CPU, memória, armazenamento e rede por equipe — sem necessidade de tags adicionais nas cargas de trabalho. Para instruções passo a passo sobre como implantar e configurar o Kubecost em um cluster HyperPod, a AWS disponibilizou documentação específica sobre Kubecost no SageMaker HyperPod.
Com o Kubecost em operação, é possível configurar orçamentos e alertas por namespace, suportar processos de chargeback (cobrar as equipes pelo uso) ou showback (reportar o uso sem cobrar), e dar a cada equipe visibilidade dos seus próprios dados de custo sem expor os dados das outras.
Conclusão
A arquitetura de referência publicada pela AWS para ambientes multi-tenant no SageMaker HyperPod com EKS combina múltiplos blocos de construção em uma solução coesa: federação de identidade, isolamento por namespace, RBAC, governança baseada em cotas e alocação de custos. O resultado é um blueprint que permite a múltiplas equipes compartilhar eficientemente um único cluster HyperPod EKS, mantendo as fronteiras de isolamento, controle e visibilidade necessárias.
A abordagem é flexível e pode ser estendida para conectar equipes a clusters HyperPod Slurm junto com EKS, proporcionando uma experiência multi-tenant unificada em diferentes backends de orquestração. Os padrões fundamentais — federação de identidade, isolamento por namespace, RBAC, governança por cotas e alocação de custos — permanecem aplicáveis independentemente de como a organização evolua sua infraestrutura de IA.
Fonte
Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/share-gpu-clusters-across-teams-with-isolation-and-fairness-using-amazon-sagemaker-hyperpod/)