Governança de modelos entre contas AWS com MLflow e SageMaker AI Model Registry: Parte 2

Governança entre contas: o próximo passo natural

Depois de estabelecer o registro automático de modelos em uma única conta, o passo seguinte para organizações maiores é estender esse controle para múltiplas contas AWS. Foi exatamente isso que a AWS abordou na segunda parte da série sobre governança com MLflow e Amazon SageMaker AI.

Na Parte 1, o foco foi em uma configuração de conta única, onde chaves de condição do Gerenciamento de Identidade e Acesso (IAM) separavam os perfis de cientista de dados e oficial de governança. Agora, o artigo avança para dois cenários de governança entre contas que refletem a realidade de empresas maiores: o padrão hub-and-spoke centralizado e o padrão híbrido para ambientes regulados.

Os perfis envolvidos

Além dos dois perfis da Parte 1 — o cientista de dados (que trabalha em notebooks Jupyter e interage apenas com o MLflow) e o oficial de governança (que atua pela interface de Modelos do Amazon SageMaker Studio) — as topologias entre contas introduzem dois novos perfis:

• Administrador: responsável pela configuração inicial entre contas, incluindo compartilhamentos via AWS Resource Access Manager (AWS RAM), políticas de bucket e grupos de destino.
• Dono do modelo: presente apenas na topologia híbrida, aprova modelos localmente na conta de desenvolvimento antes de promovê-los ao hub central.

Pré-requisitos

Para seguir o passo a passo descrito no artigo original, é necessário ter concluído a Parte 1 e estar familiarizado com o registro automático de modelos, o construto de staging de ciclo de vida e as restrições por chaves de condição IAM. Também são necessárias duas contas AWS — uma de desenvolvimento (spoke) e uma de governança (hub) — com perfis nomeados configurados no CLI da AWS (por exemplo, mlops-spoke e mlops-hub). A stack do AWS CloudFormation disponível no repositório deve ser implantada em ambas as contas, provisionando o domínio do SageMaker AI Studio, perfil de usuário, função de execução e um app MLflow gerenciado com AutoModelRegistrationEnabled.

Topologia 1: Hub-and-spoke com governança centralizada

Nessa topologia, uma conta central (hub) hospeda o app MLflow e o Registro de Modelos central. As contas de desenvolvimento (spokes) compartilham esse app por meio do AWS RAM, mantendo o isolamento de cargas de trabalho entre equipes.

Esse padrão é uma extensão da abordagem descrita no post Centralize model governance with SageMaker Model Registry and AWS RAM sharing.

Fluxo de trabalho

• O hub cria um compartilhamento de recurso AWS RAM para o app MLflow e o spoke aceita o convite. O uso de entidades externas permite que o compartilhamento funcione mesmo entre contas fora da mesma organização.
• O cientista de dados no spoke registra um modelo apontando o URI de rastreamento do MLflow para o app do hub. O registro automático cria o Grupo de Pacotes de Modelos e a versão diretamente na conta hub.
• O hub anexa uma política de recurso ao grupo e o compartilha de volta ao spoke com a permissão gerenciada AllowDeploy, permitindo que o spoke descreva e faça o deploy do modelo.
• O oficial de governança valida as métricas e a linhagem sincronizadas e aprova o modelo centralmente no hub.
• O evento de aprovação dispara um pipeline de Integração e Entrega Contínua (CI/CD), e o modelo aprovado é implantado em um endpoint do Amazon SageMaker na conta spoke.

Configuração pelo administrador (única vez)

O administrador precisa garantir o acesso entre contas ao bucket S3 de artefatos do MLflow, que fica no hub. Isso envolve dois lados: no lado do recurso, uma política de bucket concedendo ao spoke as ações s3:GetObject, s3:PutObject, s3:ListBucket e s3:GetBucketLocation. No lado da identidade, a função de execução do spoke precisa de s3:GetObject no bucket do hub para leitura de artefatos no momento do deploy.

Com isso em ordem, o administrador cria o compartilhamento AWS RAM do app MLflow, que o spoke aceita. Após o primeiro registro, anexa uma política de recurso ao Grupo de Pacotes de Modelos sincronizado e o compartilha de volta ao spoke com a permissão AllowDeploy.

Cientista de dados: registrando do spoke

O fluxo é idêntico ao da Parte 1, com uma diferença: o notebook aponta o URI de rastreamento do MLflow para o Recurso Amazon (ARN) do app no hub. O registro automático cria o Grupo de Pacotes de Modelos e a versão no hub de forma síncrona com a chamada de registro.

Dois pontos importantes a considerar: o registro automático adiciona um sufixo hash curto ao nome do grupo (por exemplo, meu-modelo vira meu-modelo-<hash>). Para localizar o grupo, use list_model_package_groups(NameContains=...) e referencie-o entre contas pelo ARN completo. Além disso, a linhagem é registrada no hub, pois a sincronização ocorre lá — o oficial de governança vê o grafo completo de linhagem no Studio do hub, mas esse dado não é compartilhado de volta ao spoke automaticamente.

Oficial de governança: aprovação centralizada no hub

O oficial de governança trabalha na visão de Modelos do Studio do hub — um único ponto de controle para candidatos de todos os spokes. Ele revisa as métricas e a linhagem sincronizadas, promove o modelo para produção e define o status de aprovação como Aprovado.

Topologia 2: Hub-and-spoke com governança híbrida

Em organizações reguladas, o hub é tratado como uma conta de nível produtivo, e não se quer que cientistas de dados escrevam nela, nem mesmo indiretamente. Para esses casos, a AWS recomenda uma topologia híbrida que mantém cada conta de desenvolvimento completamente isolada.

Fluxo de trabalho

• O cientista de dados registra um modelo no app MLflow da própria conta de desenvolvimento. A sincronização automática registra o modelo no Registro de Modelos local, sem tocar no hub.
• O dono do modelo na conta de desenvolvimento revisa e aprova o modelo localmente, disparando o fluxo de cópia.
• O fluxo de cópia replica os artefatos do modelo em um bucket de propriedade do hub, reescreve a especificação de inferência e registra o pacote no grupo de destino do hub — com metadados apontando para a origem.
• O oficial de governança no hub revalida o pacote copiado e o aprova como registro central de governança.
• Um engenheiro de ML faz o deploy do modelo aprovado localmente para um endpoint no spoke, geralmente via pipeline CI/CD. Nenhum artefato entre contas é necessário no momento do deploy.

Configuração pelo administrador (única vez)

O administrador do hub cria um Grupo de Pacotes de Modelos de destino, anexa uma política de recurso permitindo que a conta de desenvolvimento execute CreateModelPackage nele, e o compartilha via AWS RAM com a permissão AllowRegister. Também cria (ou designa) um bucket de artefatos de propriedade do hub, com política de bucket concedendo ao spoke as ações s3:PutObject e s3:ListBucket para que a cópia possa ocorrer.

Se o contêiner de inferência estiver em um repositório privado na conta de desenvolvimento, será necessário replicar a imagem para o hub ou adicionar uma política de repositório no Amazon Elastic Container Registry (Amazon ECR).

Dono do modelo: aprovação local e cópia para o hub

A aprovação local dispara uma regra do Amazon EventBridge na mudança de estado do Pacote de Modelos, que executa o fluxo de cópia. Esse fluxo realiza três ações: replica os artefatos do modelo do bucket de desenvolvimento para o bucket do hub, reescreve a especificação de inferência para apontar para a cópia no hub, e registra o pacote no grupo de destino do hub com CustomerMetadataProperties registrando o ARN e a conta de origem. O resultado é autossuficiente: o pacote no hub não tem dependência de runtime na conta de desenvolvimento.

O oficial de governança vê o pacote copiado no Studio do hub, com metadados de proveniência apontando para a origem, revalida e aprova de forma independente.

Da aprovação ao deploy

Em ambas as topologias, a aprovação no registro é o portão de controle — não o deploy em si. A mudança de status de aprovação emite um evento para o Amazon EventBridge, e esse evento dispara um pipeline CI/CD: uma regra do EventBridge que corresponde a ModelApprovalStatus: Approved inicia um pipeline que cria ou atualiza o endpoint a partir do Pacote de Modelos aprovado.

A conta onde o pipeline roda e onde o endpoint é implantado são decisões organizacionais. Um arranjo comum executa o pipeline em uma conta de serviços compartilhados e faz o deploy em uma conta dedicada. Configurações mais simples rodam ambos na conta de desenvolvimento (spoke), que é o que os exemplos do repositório demonstram.

Um ponto de atenção: a linhagem do modelo fica na conta onde a sincronização foi registrada. Planeje as revisões de governança em torno do registro do hub (ou de desenvolvimento), sem esperar que a linhagem siga o modelo para a conta de deploy.

Comparando as topologias

As três topologias — conta única (Parte 1), hub-and-spoke centralizado e hub-and-spoke híbrido — trocam isolamento de conta por simplicidade operacional. Na topologia centralizada, os spokes escrevem no hub por meio do app MLflow compartilhado, o que oferece um único ponto de controle com custo operacional moderado. Na topologia híbrida, ninguém escreve diretamente no hub — apenas cópias aprovadas e autossuficientes cruzam para ele, ideal para ambientes regulados, mas com maior custo operacional. Em todas as três, os blocos construtivos são os mesmos: o registro automático produz os metadados sincronizados, o construto de staging expressa o ciclo de vida, e as chaves de condição IAM e tags de recurso reforçam o portão de aprovação.

Limpeza de recursos

Para evitar cobranças contínuas, os recursos criados devem ser removidos na seguinte ordem: endpoint e configuração de endpoint do Amazon SageMaker AI na conta spoke; modelo do SageMaker AI criado para deploy; compartilhamentos de recurso AWS RAM; versões e Grupo de Pacotes de Modelos na conta hub; modelo registrado no app MLflow do hub; política de bucket entre contas no bucket de artefatos do hub; e, por fim, as stacks do CloudFormation em ambas as contas. O repositório inclui scripts de limpeza automatizados para cada topologia.

Conclusão

A governança entre contas apresentada pela AWS na Parte 1 desta série se expande de forma consistente: os mesmos blocos construtivos — registro automático, construto de staging e chaves de condição IAM — são reaproveitados nas topologias entre contas. O que muda é onde o limite de conta está posicionado e como o modelo o cruza.

Para começar, a AWS recomenda revisar a documentação sobre registro automático de modelos e depois trabalhar com os notebooks entre contas no repositório do GitHub.

Recursos adicionais

• Amazon SageMaker AI
• Registrar modelos SageMaker AI automaticamente no SageMaker Model Registry
• Staging Construct para o ciclo de vida do modelo
• Centralizar a governança de modelos com SageMaker Model Registry e AWS RAM sharing
• AWS re:Post para Amazon SageMaker

Fonte

Govern models with MLflow and Amazon SageMaker AI Model Registry sync: Part 2 (https://aws.amazon.com/blogs/machine-learning/govern-models-with-mlflow-and-amazon-sagemaker-ai-model-registry-sync-part-2/)