IaC para Plataformas de IA: Terraform e SageMaker Unified Studio

Em ambientes financeiros regulados — onde cada recurso provisionado precisa de trilha de auditoria, aprovação de mudança e capacidade de rollback — a ausência de IaC para plataformas de IA cria uma classe de infraestrutura de segunda categoria. Times de MLOps constroem pipelines sofisticados com Step Functions, MSK e Glue, mas o domínio SageMaker que hospeda tudo isso foi criado manualmente por um administrador há dezoito meses. Ninguém sabe exatamente quais IAM roles foram criadas, quais blueprints estão ativos, ou se o ambiente de staging é realmente idêntico ao de produção.

Esse gap não é cosmético. Quando um auditor do Banco Central ou da SEC pede evidência de que o ambiente de produção de modelos de crédito foi configurado conforme a política de segurança aprovada, a resposta "o domínio foi criado manualmente" é uma não-conformidade. O SageMaker Unified Studio agrega serviços críticos — Amazon DataZone para governança de catálogo, Amazon EMR para processamento distribuído, Amazon Redshift para analytics, Amazon Bedrock para GenAI — e cada um desses serviços tem configurações de segurança que precisam ser auditáveis e reproduzíveis.

O módulo terraform-aws-sagemaker-unified-studio resolve esse problema através de uma abordagem composável: um módulo raiz que provisiona o domínio com IAM roles gerenciadas, e sub-módulos independentes para blueprints, project profiles e projetos. Essa separação de responsabilidades é deliberada e importante — permite que times diferentes controlem diferentes camadas da plataforma sem acoplamento desnecessário no estado do Terraform.

O detalhe técnico mais importante deste lançamento não está no módulo em si, mas na camada que o viabiliza: o Terraform AWS Cloud Control Provider. Diferente do provider hashicorp/aws tradicional, que mapeia recursos AWS para recursos Terraform com lógica customizada por serviço, o Cloud Control Provider usa a API unificada de Cloud Control da AWS para criar, ler, atualizar e deletar recursos. Isso significa que novos tipos de recursos ficam disponíveis no Terraform muito mais rapidamente — sem esperar que a HashiCorp implemente suporte específico.

A consequência prática é dupla. Do lado positivo, recursos como o domínio SageMaker Unified Studio, que têm ciclo de vida gerenciado e configurações complexas, chegam ao Terraform antes que o provider tradicional os suporte. Do lado negativo, o Cloud Control Provider tem semânticas de drift detection diferentes: ele depende do read handler da Cloud Control API, que em alguns recursos retorna apenas um subconjunto dos atributos configuráveis. Isso significa que terraform plan pode reportar "no changes" mesmo quando configurações fora do escopo do handler foram alteradas manualmente no console — exatamente o tipo de drift silencioso que destrói a confiabilidade do IaC em ambientes financeiros.

Para mitigar isso em produção, eu combino o módulo com AWS Config Rules que detectam drift em recursos DataZone e SageMaker, e com CloudTrail + EventBridge para alertar sobre qualquer chamada de API que modifique o domínio fora do pipeline Terraform. O SLO aqui não é "zero drift" — é "drift detectado em menos de 15 minutos". Essa distinção é importante: perseguir zero drift via Terraform isolado é mais frágil do que detectar e corrigir drift rapidamente com observabilidade adequada.

Este padrão resolve um problema específico: provisionar e gerenciar domínios SageMaker Unified Studio como infraestrutura versionada, auditável e reproduzível em múltiplas contas e ambientes. As condições que o tornam a escolha certa são:

1. Múltiplos ambientes com paridade exigida. Se você tem dev, staging e produção para workloads de ML/AI, e compliance exige que a configuração de produção seja derivável da mesma fonte de verdade que staging, o módulo Terraform é a única abordagem que entrega isso de forma auditável. A capacidade de criar projects com IAM roles existentes — em vez de sempre criar novas — é crítica aqui: em ambientes financeiros, IAM roles passam por processo de aprovação separado e não podem ser criadas ad-hoc pelo pipeline de plataforma.

2. Times de plataforma separados dos times de produto. O design modular do terraform-aws-sagemaker-unified-studio — domínio no módulo raiz, blueprints e project profiles em sub-módulos independentes — mapeia diretamente para o modelo de responsabilidade onde um time de Platform Engineering controla o domínio e IAM, enquanto times de dados controlam seus próprios project profiles e projetos. Isso é Data Mesh em nível de infraestrutura: domínios de dados com autonomia controlada.

3. Necessidade de disaster recovery documentado. Um domínio SageMaker Unified Studio criado manualmente não tem RTO definido — ninguém sabe quanto tempo leva para recriar tudo do zero. Com o módulo Terraform, o RTO de recriação do ambiente é o tempo de terraform apply, que para um domínio típico fica entre 8 e 20 minutos dependendo dos blueprints habilitados. Isso é um número real que pode entrar no seu BIA (Business Impact Analysis).

O padrão não é a escolha certa quando você tem um único ambiente de experimentação sem requisitos de auditoria, ou quando a equipe não tem maturidade em Terraform suficiente para gerenciar state remoto, módulos e workspaces com segurança.

Para um banco ou gestora de ativos que precisa operar modelos de crédito, detecção de fraude e análise de portfólio em um ambiente regulado, o design de referência que eu aplicaria combina o módulo Terraform com uma estratégia de contas AWS Organizations e controles de governança em camadas.

Estrutura de contas: Conta de ferramentas de plataforma (onde o estado Terraform remoto vive em S3 com versionamento e KMS CMK, e o DynamoDB lock table usa BillingMode: PAY_PER_REQUEST com ponto-in-time recovery habilitado), conta de produção de AI/ML, conta de staging e conta de desenvolvimento. O pipeline CI/CD assume roles via OIDC em cada conta — nunca usa access keys.

Camadas de estado Terraform: Layer 0 — domínio SageMaker Unified Studio + IAM roles (gerenciado pelo time de Platform Engineering, apply requer aprovação manual no pipeline). Layer 1 — blueprints habilitados (gerenciado pelo time de Platform Engineering com revisão de custo). Layer 2 — project profiles (gerenciado por tech leads de cada domínio de dados). Layer 3 — projetos individuais (gerenciado por times de produto com self-service controlado).

Controles de segurança específicos: KMS CMK dedicada por ambiente para criptografia de dados do domínio, com kms:ViaService condition restringindo uso ao SageMaker e DataZone. SCPs no AWS Organizations bloqueando criação manual de domínios SageMaker fora do pipeline (Deny em sagemaker:CreateDomain exceto para a role do pipeline Terraform). AWS Config Rule customizada verificando que todos os domínios SageMaker têm tag ManagedBy: terraform — qualquer domínio sem essa tag dispara alerta P1.

Observabilidade: CloudWatch Dashboard com métricas de aws/sagemaker/unified-studio namespace, CloudTrail Lake com query salva para detectar modificações manuais no domínio, e custo por projeto via Cost Allocation Tags mapeadas nos sub-módulos de projeto. Esse último ponto é frequentemente negligenciado: o módulo Terraform é o lugar certo para garantir que tags de alocação de custo sejam aplicadas consistentemente em todos os recursos do domínio.