Boas práticas de administração e governança do Amazon SageMaker HyperPod

O desafio de governar clusters compartilhados

O Amazon SageMaker HyperPod oferece a times de aprendizado de máquina (ML) acesso a grandes pools de compute acelerado para treinar e ajustar modelos. Quando várias equipes compartilham um mesmo cluster, a parte técnica costuma ser simples. O que complica é a governança: quem pode usar o cluster, quanto cada time recebe, o que acontece quando workloads competem por recursos e quem responde quando o uso se afasta da política definida.

O Amazon SageMaker Unified Studio adiciona mais uma camada a esse cenário: é possível conectar um cluster HyperPod a um projeto para que membros do time lancem workloads diretamente do workspace. Isso é conveniente, mas quando múltiplas equipes passam a enxergar o mesmo cluster, os controles sobre quem pode fazer o quê se tornam ainda mais críticos.

A AWS publicou um guia de boas práticas que mostra como administrar o SageMaker HyperPod pelo SageMaker Unified Studio preservando os controles de governança subjacentes. O modelo cobre quatro camadas de controle — organização, projeto, cluster e workload — e explica como estruturar políticas de identidade, capacidade e observabilidade em cada uma delas.

Vale lembrar: o SageMaker HyperPod é uma capacidade do Amazon SageMaker AI, enquanto o SageMaker Unified Studio é o ambiente de desenvolvimento de dados e IA onde os times trabalham com suas ferramentas. A separação entre os dois é justamente o que dá à equipe de infraestrutura um modelo operacional claro.

As quatro camadas de controle

Um ambiente bem governado separa administração organizacional, acesso por projeto e operações de cluster. Cada camada responde a uma pergunta diferente e usa um controle diferente:

• Organização: domínios e unidades de domínio do SageMaker Unified Studio, contas associadas, perfis de projeto e políticas de autorização. Define quem pode criar projetos, quais contas e regiões estão disponíveis e quais ferramentas são permitidas.
• Projeto: membros do projeto, papéis e conexões com o HyperPod. Define o contexto de colaboração e os recursos AWS que os membros podem acessar.
• Cluster: papéis de administrador do HyperPod, entradas de acesso ao Amazon EKS, Controle de Acesso Baseado em Papel (RBAC), EKS Pod Identity ou controles do Slurm. Governa configuração do cluster, acesso ao scheduler, namespaces, tarefas e operações de infraestrutura.
• Workload: alocações de compute, classes de prioridade, políticas de empréstimo e permissões de tarefa. Controla quem pode submeter trabalho e como a capacidade compartilhada é distribuída.

Um ponto importante: uma conexão do HyperPod adiciona um cluster aprovado a um projeto, mas não substitui os controles de Gerenciamento de Identidade e Acesso (IAM), Amazon EKS ou Slurm já existentes. Papéis de projeto, papéis de acesso de conexão, entradas EKS, RBAC, identidade de workload, políticas de dados e de chaves do AWS Key Management Service (AWS KMS), políticas de rede e controles do scheduler devem ser revisados em conjunto. O cluster só deve ser disponibilizado depois que todos esses controles estiverem alinhados.

Projetos do SageMaker Unified Studio são fronteiras de colaboração — não são fronteiras fortes de segurança em tempo de execução. O cluster HyperPod, o scheduler e a capacidade de aceleradores devem permanecer sob uma conta de capacidade designada. Para Amazon EKS, a recomendação é usar um namespace por tenant com RBAC, contas de serviço por tenant com papéis EKS Pod Identity, políticas de rede com negação padrão e permissões de armazenamento e KMS específicas por tenant. Para Slurm, usar contabilidade hierárquica com associações, Qualidade de Serviço (QoS), políticas de prioridade e partições.

Quando o SageMaker Unified Studio é a experiência certa

Com o SageMaker Unified Studio, times de ML que já trabalham em um projeto podem seguir um caminho aprovado para acessar o compute compartilhado do HyperPod — encontrar clusters conectados, revisar status e metadados, inspecionar tarefas e métricas, e abrir o JupyterLab sem precisar de um inventário de infraestrutura separado.

Mas essa experiência não substitui a administração do cluster. Cada persona tem seu papel:

• Administrador de domínio ou infraestrutura: usa o Unified Studio para unidades de domínio, políticas de criação de projetos e perfis. Continua usando ferramentas específicas para provisionamento de contas e automação de infraestrutura.
• Administrador do cluster HyperPod: usa o Unified Studio para apresentar conexões aprovadas e revisar metadados. Continua usando as interfaces do SageMaker AI para criação, atualização, resiliência e resposta a incidentes.
• Dono do projeto: gerencia membros e o contexto de compute aprovado. Solicita mudanças de infraestrutura por canais adequados.
• Engenheiro de ML ou cientista de dados: encontra compute aprovado, revisa status de workloads e abre o JupyterLab. Submete e gerencia workloads detalhados pelo HyperPod CLI, kubectl ou ferramentas Slurm.

Para mudanças no cluster e automação repetível, a recomendação é continuar usando APIs do SageMaker AI, infraestrutura como código e ferramentas de orquestração. Implementações de referência estão disponíveis no site AI on SageMaker HyperPod.

Decisões antes de conectar um cluster

Antes de aprovar uma conexão, a AWS recomenda documentar a conta de capacidade, contas de consumidor ou dados, região AWS, caminhos de rede, identidades, donos, fronteiras de workload e requisitos de isolamento. Para orientações sobre criação de cluster, consulte a documentação do Amazon SageMaker HyperPod.

Alguns princípios fundamentais para essa etapa:

• Separe identidades administrativas e de workload. Um papel voltado para o projeto não deve receber permissões de ciclo de vida do cluster só porque seus usuários executam workloads. Consulte AWS Identity and Access Management para SageMaker HyperPod para o modelo de permissões suportado.
• Trate a rede como controle de ponta a ponta. Restrinja o acesso ao endpoint da API Kubernetes do EKS a caminhos administrativos aprovados, controle ingresso e egresso de pods, e configure endpoints de VPC para serviços como Amazon S3, Amazon ECR e Amazon CloudWatch. Para configuração específica do orquestrador, consulte Orquestrando clusters SageMaker HyperPod com Amazon EKS.
• Crie um contrato de conexão. Esse é um registro de governança gerenciado pelo cliente — pode ser uma página de wiki, ticket, registro de service catalog ou arquivo em repositório de infraestrutura como código. Não é uma funcionalidade da plataforma. Deve registrar: dono de negócio, operações e custos; domínio e projeto no Unified Studio; conta, região, nome e orquestrador do cluster; papel do projeto e ARN do papel de acesso; tipos de workload aprovados e classificação de dados; namespaces EKS ou escopo de acesso Slurm; política de scheduling e dono de exceções; e expectativas de monitoramento e descomissionamento.

Governança de identidade e visibilidade de tarefas

Controlar tanto ações quanto visibilidade é essencial. Uma configuração incorreta de nomes de tarefas, namespaces e padrões de uso pode revelar informações sobre o trabalho de outra equipe.

A AWS chama atenção para um detalhe importante: por padrão, usuários do SageMaker AI Studio conseguem ver todas as tarefas de clusters Amazon EKS. Para clusters Slurm, todo usuário do Studio pode visualizar, gerenciar e interagir com tarefas disponíveis. Por isso, é necessário configurar restrições de visibilidade de tarefas antes de integrar múltiplas equipes — veja Restringir visibilidade de tarefas no Studio para clusters EKS e Restringir visibilidade de tarefas no Studio para clusters Slurm.

Para clusters Amazon EKS, cada time deve ser mapeado para um namespace aprovado com permissões RBAC, e cada conta de serviço de workload deve estar associada a um papel IAM específico do tenant. Para acesso a dados entre contas, o EKS Pod Identity realiza a assunção de papel entre contas automaticamente, sem que o código da aplicação precise chamar AssumeRole diretamente.

Manter visibilidade somente leitura separada das permissões para criar, atualizar ou excluir workloads é fundamental. O exemplo abaixo, presente no guia original, mostra um Role Kubernetes RBAC que concede a um time acesso somente leitura a jobs apenas em seu próprio namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-research
  name: research-job-viewer
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
  resources: ["pytorchjobs"]
  verbs: ["get", "list", "watch"]

Um papel separado é necessário para criar ou excluir workloads, mantendo “ver” separado de “agir”.

Traduzindo prioridades de negócio em política de scheduling

Para clusters Amazon EKS, a AWS recomenda aplicar a governança de tarefas somente depois que os controles de identidade e acesso de workload estiverem em vigor. A separação entre autorização e política de scheduling é um ponto central do guia.

RBAC do EKS ou listas de controle de acesso (ACLs) do Slurm determinam se um usuário pode submeter um workload. A governança de tarefas do SageMaker HyperPod para Amazon EKS ou os controles nativos do Slurm determinam quando esse workload autorizado recebe compute. Usar quota do scheduler como controle de acesso, ou usar controles de autorização como política de scheduling, gera comportamento ambíguo e dificulta o diagnóstico de incidentes.

A AWS recomenda documentar capacidade garantida e compartilhada, classes de prioridade e se um time pode usar a alocação ociosa de outro. Por exemplo: o time de treinamento de produção pode receber 60% de alocação garantida com classe de alta prioridade, enquanto o time de pesquisa toma capacidade ociosa em prioridade mais baixa e pode ser preemptado quando o time de produção submeter trabalho. Cada exceção a essa política deve ter um dono designado.

A governança de tarefas também se aplica aos SageMaker HyperPod spaces — ambientes JupyterLab ou Code Editor que rodam diretamente no cluster — portanto esses workloads interativos devem ser incluídos na política de alocação. O post Boas práticas para governança de tarefas do Amazon SageMaker HyperPod detalha pesos de fair-share, quotas, empréstimo e preempção para clusters EKS.

Observabilidade como ciclo de feedback de governança

Com o SageMaker Unified Studio, é possível visualizar detalhes do cluster HyperPod — tarefas, métricas, configurações e metadados. Para clusters EKS, as métricas de governança de tarefas incluem visões de hardware, time e tarefa, que ajudam a comparar a intenção da política com o consumo real.

A recomendação é tratar a observabilidade como um ciclo: monitorar sinais, comparar com a intenção da política, decidir uma resposta e ajustar política e alocações. Cada sinal monitorado deve ter um dono e uma resposta definidos. Alguns exemplos práticos do guia:

• Capacidade do cluster e utilização de aceleradores: verificar se baixa utilização é temporária, orientada por política ou causada por restrições de workload.
• Alocação e utilização por time: revisar se a capacidade reservada e compartilhada ainda reflete a demanda de negócio.
• Tempo de execução e espera de tarefas: investigar política de prioridade, dimensionamento de workload ou contenção de capacidade.
• Tarefas pendentes e preemptadas: confirmar que os resultados do scheduler correspondem ao modelo de prioridade aprovado.
• Saúde de nós e eventos de recuperação: acionar o processo de incidente do cluster e validar objetivos de recuperação.

O add-on Amazon CloudWatch Observability EKS é necessário para as visões de métricas documentadas. Ele requer versão 2.4.0 ou superior e a política IAM CloudWatchAgentServerPolicy anexada ao papel do nó worker Kubernetes. Métricas do Kueue, que alimentam as visões de governança de tarefas, podem gerar cobranças do CloudWatch após o nível gratuito. Consulte a documentação do dashboard do SageMaker HyperPod para considerações atuais de configuração e preços.

Revisando conexões ao longo do ciclo de vida

A AWS recomenda definir um calendário de revisão para cada conexão, além de revisões orientadas por eventos — mudanças de dono de projeto, papéis de acesso, conta ou região, capacidade do cluster, versão do orquestrador, classificação de dados ou cobertura de monitoramento. O contrato de conexão deve registrar cada decisão tomada.

O ciclo de vida de uma conexão passa por quatro fases: aprovação com contrato registrado, operação com monitoramento de uso e custo, revisão periódica e orientada por eventos, e por fim renovação ou revogação. Automação de inventário e coleta de evidências é bem-vinda onde reduz trabalho manual, mas a aprovação deve permanecer com administradores responsáveis. Conexões sem propósito de negócio ou dono responsável devem ser revogadas.

Por onde começar

O guia da AWS sugere começar com um cluster fora de produção e um projeto de teste. Antes de adicionar membros, configure identidade de workload, escopo de namespace ou Slurm, permissões de dados, política de rede, restrições de visibilidade de tarefas e governança de tarefas para EKS (ou controles nativos de scheduling para Slurm). Instale o add-on Amazon CloudWatch Observability EKS para que as visões de métricas sejam populadas, e registre a aprovação completa no contrato de conexão. Use papéis entre contas para contas de consumidor aprovadas e infraestrutura dedicada quando isolamento rígido for exigido. Para os passos de implementação, consulte o procedimento de conexão do SageMaker HyperPod.

Fonte

Best practices for Amazon SageMaker HyperPod administration and governance (https://aws.amazon.com/blogs/machine-learning/best-practices-for-amazon-sagemaker-hyperpod-administration-and-governance/)