# IaC para Plataformas de IA: Terraform e SageMaker Unified Studio

O suporte oficial ao Terraform para o SageMaker Unified Studio fecha uma lacuna crítica: plataformas de IA agora podem ser provisionadas com o mesmo rigor de IaC que redes e bancos de dados. Neste artigo, disseço o padrão, sua anatomia modular, quando ele resolve o problema certo e quando ele esconde dívida técnica perigosa.

- URL: https://fernando.moretes.com/blog/iac-para-plataformas-de-ia-terraform-e-sagemaker-unified-studio-amazon-sagem

- Markdown: https://fernando.moretes.com/blog/iac-para-plataformas-de-ia-terraform-e-sagemaker-unified-studio-amazon-sagem/article.md?lang=pt

- Published: 2026-07-03T09:02:52.585Z

- Category: IA & Agentes

- Tags: terraform, sagemaker, iac, mlops, data-governance, platform-engineering, finops, devsecops

- Reading time: 7 min

- Source: [Amazon SageMaker Unified Studio now supports Terraform for provisioning](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-sagemaker-unified-studio-terraform/)

---

Provisionar uma plataforma de IA com cliques no console é o equivalente arquitetural de configurar um banco de dados de produção via SSH. Funciona na primeira vez, falha na segunda, e ninguém sabe o que mudou. O suporte oficial ao Terraform para o Amazon SageMaker Unified Studio, anunciado em 2 de julho de 2026, não é apenas conveniência operacional — é a condição mínima para que equipes de plataforma tratem ambientes de dados e IA com o mesmo contrato de engenharia que já aplicam a VPCs, clusters EKS e pipelines de dados. Vou dissecar o padrão, sua anatomia real e os lugares onde ele falha silenciosamente.

## O Problema Real: Plataformas de IA Fora do Contrato de Engenharia

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.

## Anatomia do Padrão: Módulos Terraform para SageMaker Unified Studio

Fluxo de provisionamento mostrando a composição modular do terraform-aws-sagemaker-unified-studio, da pipeline CI/CD até os recursos provisionados em múltiplas contas AWS

### 🔧 IaC Pipeline

- Git Repo module source (ci)
- CI/CD (GitHub Actions / CodePipeline) (ci)
- S3 + DynamoDB Remote State + Lock (storage)

### 🏗️ Root Module

- SageMaker Unified Studio Domain (ai)
- IAM Roles (provisioned by module) (security)
- Cloud Control API Provider (compute)

### 🧩 Sub-Modules

- Blueprint Sub-Module (ai)
- Project Profile Sub-Module (ai)
- Project Sub-Module (ai)

### ☁️ AWS Services (Domain)

- Amazon DataZone Catalog (data)
- Amazon Bedrock GenAI (ai)
- Amazon EMR Distributed Processing (compute)

### Fluxos

- vcs -> cicd: push / PR
- cicd -> tfstate: lock + read state
- cicd -> ccapi: terraform apply
- ccapi -> domain: provisiona domínio
- domain -> iam: cria roles
- blueprint -> domain: habilita blueprint
- profile -> blueprint: compõe perfil
- project -> profile: instancia projeto
- domain -> datazone: governança
- domain -> bedrock: GenAI tools
- domain -> emr: processamento

## Anatomia do Módulo: Cloud Control API e o Custo da Abstração

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.

## Quando Usar Este Padrão: Condições de Validade

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.

## Anti-Padrões: Onde Este Padrão Falha Silenciosamente

- **Estado monolítico por conta.** Colocar domínio, todos os blueprints, todos os project profiles e todos os projetos em um único `terraform apply` cria um blast radius enorme. Uma mudança em um project profile de um time de dados bloqueia o apply de uma atualização crítica de IAM do domínio.
- **Ignorar o drift silencioso do Cloud Control Provider.** Como discutido, o `read` handler da Cloud Control API não cobre todos os atributos. Confiar apenas em `terraform plan` para detectar drift é insuficiente. Sem AWS Config Rules e CloudTrail alerting cobrindo os recursos do domínio, você terá configurações de segurança alteradas manualmente que o Terraform não detecta — e que um auditor vai
- **IAM roles criadas pelo módulo com permissões excessivas em produção.** O módulo provisiona IAM roles automaticamente, o que é conveniente mas perigoso se aceito sem revisão. Em ambientes financeiros, toda IAM role que acessa dados sensíveis precisa passar por revisão de least-privilege.
- **Sem separação de credenciais entre ambientes.** Usar o mesmo AWS provider configurado com as mesmas credenciais para dev e produção em módulos Terraform diferentes é um erro clássico de blast radius. Configure providers com `assume_role` para roles específicas por ambiente, e use OIDC com GitHub Actions ou CodeBuild para eliminar credenciais de longa duração do pipeline.
- **Blueprints habilitados sem custo baseline.** Cada blueprint habilitado no SageMaker Unified Studio pode provisionar recursos subjacentes (clusters EMR, endpoints Redshift, conexões Bedrock) com custo contínuo. Habilitar todos os blueprints disponíveis em dev "para experimentar" e esquecer de destruí-los é um vetor de custo real.

## Design de Referência: Plataforma de IA Multi-Conta com Governança Financeira

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.

## Lentes Well-Architected para este Padrão

- **security**: Use `create_iam_roles = false` em produção e forneça roles pré-aprovadas. Aplique KMS CMK com `kms:ViaService` condition. Bloqueie criação manual de domínios via SCP. Habilite CloudTrail para todas as chamadas de API do domínio.
- **reliability**: Separe state Terraform por camada para reduzir blast radius. Habilite S3 versioning e DynamoDB PITR para o state remoto. Documente RTO de recriação do domínio como métrica de confiabilidade da plataforma.
- **performance**: Habilite apenas os blueprints necessários por ambiente — blueprints desnecessários aumentam tempo de apply e custo de recursos subjacentes. Meça tempo de `terraform apply` por camada como SLI de plataforma.

> **Separação de State é Mais Importante que DRY:** A tentação com módulos Terraform bem estruturados é consolidar tudo em um único apply para "simplificar". Resista. Em plataformas de IA com múltiplos times, o domínio SageMaker e os projetos individuais têm ciclos de vida completamente diferentes — o domínio muda raramente e com alto impacto, os projetos mudam frequentemente e com impacto isolado. Separar em state files distintos não é burocracia: é a diferença entre um `terraform apply` de 30 segundos para criar um projeto e um de 20 minutos que pode destruir o domínio inteiro se algo der errado.

## Abordagens de Provisionamento: Terraform vs. Alternativas
| Critério | Critério | Terraform + módulo oficial | AWS CDK | CloudFormation manual | Console manual |
| --- | --- | --- | --- | --- | --- |
| Auditabilidade | ✅ Git history + state | ✅ Git history + CDK context | ⚠️ Stack events, sem diff legível | ❌ Apenas CloudTrail | — |
| Drift detection | ⚠️ Parcial via Cloud Control API | ⚠️ Depende do L1 construct | ✅ CloudFormation drift detection nativo | ❌ Nenhum | — |
| Integração com pipelines existentes | ✅ Ecossistema Terraform maduro | ⚠️ Requer Node.js no pipeline | ✅ Nativo AWS | ❌ Não aplicável | — |
| Multi-cloud / portabilidade | ✅ Terraform state portável | ⚠️ AWS-centric | ❌ AWS only | ❌ AWS only | — |
| Curva de aprendizado para times de dados | ⚠️ HCL moderado | ✅ Linguagem familiar (Python/TypeScript) | ❌ YAML/JSON verboso | ✅ UI familiar | — |

> **Minha Nota de Curadoria:** Eu apliquei o padrão de IaC para plataformas de dados em ambientes onde o custo de um domínio mal configurado não é técnico — é regulatório. O que aprendi na prática é que o módulo Terraform é condição necessária mas não suficiente: sem SCPs bloqueando criação manual e sem AWS Config Rules cobrindo os recursos do domínio, equipes vão criar domínios fora do pipeline "só para testar" e esses domínios vão sobreviver para produção. O segundo ponto que eu enfatizaria: a separação de state por camada não é opcional em times com mais de dois squads usando a plataforma — é a única forma de dar autonomia sem criar acoplamento de deploy. Por fim, o suporte a `existing_iam_roles` é o feature mais importante deste módulo para ambientes financeiros: sem ele, o módulo seria inutilizável em qualquer organização com processo de aprovação de IAM separado do pipeline de plataforma.

## Veredicto: Adote, com Controles de Governança Explícitos

O módulo `terraform-aws-sagemaker-unified-studio` é a abordagem correta para qualquer organização que opera SageMaker Unified Studio em ambientes regulados ou com múltiplos times. O design modular composável resolve o problema real de separação de responsabilidades entre Platform Engineering e times de produto. A dependência do Cloud Control Provider é uma limitação conhecida que exige controles compensatórios de drift detection — não é motivo para rejeitar o padrão, mas é motivo para não confiar cegamente no `terraform plan` como única fonte de verdade sobre o estado do domínio. Para ambientes financeiros: use `existing_iam_roles` em produção, separe state por camada, bloqueie criação manual via SCP, e instrumente CloudTrail + AWS Config para cobertura de drift. Com esses controles, este padrão entrega o que promete: plataformas de IA com o mesmo rigor de engenharia que você já aplica ao resto da sua infraestrutura.

**Rating:** Adopt with controls

## Referências

- [AWS What's New: Amazon SageMaker Unified Studio now supports Terraform for provisioning (Jul 2, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-sagemaker-unified-studio-terraform/)
- [GitHub: terraform-aws-sagemaker-unified-studio (aws-ia)](https://github.com/aws-ia/terraform-aws-sagemaker-unified-studio)
- [AWS Blog: Quickly adopt new AWS features with the Terraform AWS Cloud Control Provider](https://aws.amazon.com/blogs/devops/quickly-adopt-new-aws-features-with-the-terraform-aws-cloud-control-provider/)
- [AWS Blog: Deploy Amazon SageMaker Projects with Terraform Cloud (May 2025)](https://aws.amazon.com/blogs/machine-learning/deploy-amazon-sagemaker-projects-with-terraform-cloud/)
- [AWS Blog: Amazon SageMaker Domain in VPC only mode with Terraform (Sep 2023)](https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-domain-in-vpc-only-mode-to-support-sagemaker-studio-with-auto-shutdown-lifecycle-configuration-and-sagemaker-canvas-with-terraform/)
- [AWS Docs: SageMaker Unified Studio Administrator Guide — Supported Regions](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/)
- [AWS Docs: AWS Control Tower AFT Provisioning Framework](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)
- [AWS Architecture Center: AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)