SageMaker Unified Studio via Terraform: Migrando para IaC em Ambientes Financeiros

Antes de qualquer migração, é preciso ser honesto sobre o estado inicial. Em organizações financeiras com as quais trabalhei, o padrão mais comum para SageMaker Studio, e, por extensão, para o Unified Studio em seus primeiros meses, era uma combinação de console manual para o domínio principal, scripts Python via boto3 para configurações de usuário, e documentação de runbook que defasava da realidade em semanas. Esse estado não é negligência: é o resultado natural de uma plataforma que evoluiu mais rápido do que o suporte a IaC.

O problema concreto não é estético. Em um ambiente regulado por SOX, PCI-DSS ou BACEN, cada configuração de domínio, quais execution roles foram atribuídas, quais blueprints estão ativos, quais project profiles existem, precisa ser rastreável a um change ticket, revisada por um segundo par de olhos e auditável retroativamente. Um domínio criado via console não tem nenhuma dessas propriedades por padrão. O histórico de mudanças vive no CloudTrail, mas reconstruir por que uma IAM role foi adicionada a um project profile há seis meses requer correlacionar eventos de CloudTrail com tickets de JIRA manualmente, um processo que falha exatamente quando você mais precisa dele: durante um incidente de segurança ou uma auditoria externa.

Além disso, a proliferação de domínios em múltiplas contas (dev, staging, prod, sandbox de cientistas) sem IaC cria drift silencioso. A conta de produção tem um blueprint de Glue habilitado que staging não tem. O project profile de ML em prod usa uma KMS key diferente da que está documentada. Esses desvios só aparecem quando causam problemas, e em ambientes financeiros, os problemas têm custo regulatório, não apenas operacional.

A integração Terraform para o SageMaker Unified Studio é habilitada pelo Terraform AWS Cloud Control Provider (awscc), não pelo provider aws tradicional. Essa distinção tem implicações práticas que merecem atenção antes de você descobrir em produção.

O Cloud Control Provider opera via AWS Cloud Control API, que por sua vez usa o CloudFormation Resource Model. Isso significa que cada operação de criação, atualização ou deleção é assíncrona e polling-based, o provider faz chamadas repetidas à API até que o recurso atinja o estado desejado ou o timeout expire. O timeout padrão para operações de criação é de 120 minutos, o que é relevante para domínios SageMaker com VPC attachment e múltiplos blueprints habilitados. Em pipelines CI/CD com timeout agressivo (comum em organizações que querem feedback rápido), isso pode causar falhas espúrias que não refletem falha real no provisionamento.

Além disso, o awscc provider tem semântica de drift diferente do provider aws. Propriedades que o Cloud Control API não expõe como mutáveis serão marcadas como ForceNew no schema, e o Terraform planejará substituição do recurso se você tentar modificá-las. Isso é especialmente relevante para domain_execution_role_arn e configurações de rede, propriedades que times de segurança frequentemente querem ajustar sem recriar o domínio. A solução é usar lifecycle { ignore_changes = [...] } cirurgicamente para propriedades que são gerenciadas fora do Terraform (por exemplo, por um processo de IAM centralizado), documentando explicitamente no código por que o ignore está lá.

Um ponto positivo: o Cloud Control Provider tem melhor cobertura de recursos novos do que o provider aws tradicional, porque novos tipos de recursos AWS são registrados no CloudFormation Registry antes de receberem suporte nativo no provider Terraform. Para uma plataforma em evolução como o SageMaker Unified Studio, isso significa que novos sub-recursos (novos tipos de blueprint, novas configurações de project profile) estarão disponíveis via awscc antes de aparecerem no provider aws.

O módulo terraform-aws-sagemaker-unified-studio pode provisionar IAM roles automaticamente, mas em ambientes financeiros com SCPs restritivas, essa opção frequentemente falha com AccessDenied porque a role do pipeline CI/CD não tem permissão para criar roles com políticas arbitrárias, e não deveria ter. O modo existing_iam_roles é o caminho correto, mas exige que você entenda exatamente quais roles são necessárias e quais permissões cada uma precisa.

A role de execução do domínio (domain_execution_role_arn) é a identidade sob a qual o SageMaker Unified Studio opera internamente. Ela precisa de trust policy para sagemaker.amazonaws.com com condição aws:SourceAccount para prevenir confused deputy. As permissões mínimas incluem acesso ao bucket de artefatos do domínio (com condição s3:prefix para limitar ao path do domínio), acesso à KMS key do domínio, e permissões de Glue Catalog para o catálogo compartilhado. Não use AmazonSageMakerFullAccess, essa política managed tem escopo muito amplo e vai falhar em revisões de segurança.

Para projetos que usam blueprints específicos (Glue, EMR, Bedrock), as roles de projeto precisam de permissões adicionais. O padrão que recomendo é criar uma role base de projeto com permissões mínimas e usar permission boundaries para limitar o escopo máximo que qualquer role de projeto pode assumir, mesmo que um cientista de dados tente escalar privilégios via Terraform dentro do projeto, o boundary impede. Isso é especialmente importante em projetos de Generative AI com Bedrock, onde as permissões de bedrock:InvokeModel precisam ser limitadas a modelos específicos via condition bedrock:ModelId.

Um detalhe frequentemente ignorado: o SageMaker Unified Studio usa service-linked roles para algumas integrações. Essas roles são criadas automaticamente na primeira vez que o serviço é usado, mas em contas com SCP que bloqueia iam:CreateServiceLinkedRole, elas precisam ser pré-criadas. Inclua a criação dessas roles no seu módulo Terraform de bootstrap de conta, não descubra essa dependência durante o primeiro apply em produção.

Migrar para IaC não elimina a necessidade de observabilidade operacional, ela muda o foco. Antes da migração, você monitorava o estado do domínio diretamente. Após a migração, você monitora o pipeline que gerencia o estado do domínio, mais o estado do domínio em si como validação.

Para o pipeline Terraform, os sinais mais importantes são: duração do apply (um aumento súbito indica throttling da Cloud Control API ou problemas de rede com o VPC endpoint do SageMaker), taxa de falha de plan (indica drift ou mudanças fora do pipeline), e resultado do job de drift detection agendado. Configure CloudWatch Alarms para esses três sinais com thresholds baseados em baseline de 30 dias, não use thresholds fixos arbitrários.

Para o domínio SageMaker Unified Studio em si, os sinais operacionais relevantes são: eventos de CloudTrail para sagemaker:CreateProject, sagemaker:DeleteProject e modificações de blueprint (qualquer mudança fora do pipeline deve gerar alerta), métricas de uso de KMS key (um spike inesperado pode indicar acesso não autorizado a dados do domínio), e logs de acesso ao bucket de artefatos do domínio via S3 Server Access Logging ou CloudTrail Data Events.

Em ambientes financeiros, recomendo também configurar AWS Config Rules para validar propriedades críticas do domínio continuamente: encryption_key_arn deve estar presente e apontar para uma KMS key gerenciada pelo cliente (não AWS managed), vpc_only_mode deve estar habilitado em produção, e as tags obrigatórias de compliance (CostCenter, DataClassification, Environment) devem estar presentes. Com o recente anúncio de que o AWS Config suporta novos resource types (junho 2026), verifique se o tipo AWS::SageMaker::Domain já está coberto na sua região, isso permite usar Config conformance packs para validação automatizada em escala.

Um sinal que frequentemente é ignorado: o número de projetos ativos por domínio. SageMaker Unified Studio tem limites de serviço por domínio que variam por região. Monitore esse contador via CloudWatch custom metrics e configure alarme quando atingir 80% do limite, uma surpresa nesse limite em produção é difícil de resolver rapidamente.