# SageMaker Unified Studio + Terraform: Retro de Incidente em IaC para IA

A ausência de infraestrutura-como-código reproduzível para plataformas de IA unificadas não é um problema de conveniência — é um vetor de incidentes de governança, drift de configuração e falhas de auditoria em ambientes financeiros. O suporte ao Terraform no Amazon SageMaker Unified Studio, lançado em julho de 2026, fecha uma lacuna crítica que eu vi causar incidentes reais em múltiplos clientes enterprise. Esta retro analisa o padrão de falha, a linha do tempo típica e as mudanças de resiliência que devem seguir.

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

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

- Published: 2026-07-05T09:02:55.880Z

- Category: IA & Agentes

- Tags: sagemaker, terraform, iac, data-governance, mlops, devSecOps, well-architected, incident-retro

- Reading time: 10 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/)

---

Em julho de 2026, a AWS anunciou suporte oficial ao Terraform para o Amazon SageMaker Unified Studio via o módulo open-source `terraform-aws-sagemaker-unified-studio`. Para quem opera plataformas de dados e IA em escala financeira, isso não é uma feature incremental — é a resolução de um padrão de incidente que eu documentei repetidamente: domínios provisionados manualmente, IAM roles criadas fora de controle de versão, blueprints inconsistentes entre ambientes e auditorias que encontram configurações que ninguém consegue explicar. Esta retro reconstrói esse padrão de falha, traça a linha do tempo de um incidente típico e mapeia as mudanças de resiliência que o suporte ao Terraform agora torna possíveis.

## O que aconteceu: o padrão de falha em plataformas de IA sem IaC

O Amazon SageMaker Unified Studio é um ambiente de desenvolvimento unificado onde equipes de dados constroem workflows end-to-end — integração de dados, analytics, machine learning e IA generativa — todos governados por um catálogo compartilhado. Administradores provisionam domínios para dar à organização um workspace gerenciado com controle de acesso, governança de dados e conectividade cross-service. Antes do suporte ao Terraform, o provisionamento de um domínio SageMaker Unified Studio era fundamentalmente um processo de console ou CLI: um administrador navegava pela interface, criava IAM roles manualmente ou usava roles geradas automaticamente pelo serviço, configurava blueprints via UI e criava project profiles sem qualquer representação declarativa versionada.

Em ambientes financeiros, esse padrão é um incidente esperando para acontecer. O problema não é a complexidade técnica do provisionamento em si — é a **ausência de estado declarativo auditável**. Quando um auditor de segurança pergunta "qual é a política IAM exata associada ao projeto X no ambiente de produção?", a resposta não pode ser "preciso verificar no console". Quando um engenheiro de plataforma precisa replicar o ambiente de staging para um novo cliente, a resposta não pode ser "vou refazer manualmente seguindo o runbook". Esses dois cenários — auditoria sem evidência e replicação sem automação — são os vetores primários de incidente que eu vi se materializar em clientes de serviços financeiros operando plataformas de ML.

O drift de configuração é o mecanismo de falha central. Em um ambiente sem IaC, cada intervenção manual no console — uma role ajustada aqui, um blueprint modificado lá, um project profile recriado com parâmetros ligeiramente diferentes — acumula divergência silenciosa entre dev, staging e prod. Essa divergência só se torna visível em três momentos: durante um incidente de segurança, durante uma auditoria de compliance, ou quando uma promoção de código falha em produção porque o ambiente não é o que o time assumia que era.

## Linha do Tempo: Incidente Típico de Drift em Plataforma de IA sem IaC

1. **Dia 0 — Provisionamento manual inicial** — Engenheiro de plataforma cria o domínio SageMaker Unified Studio via console. IAM roles são geradas automaticamente pelo serviço. Blueprints e project profiles são configurados via UI. Nenhum estado declarativo é registrado. O runbook de criação existe como documento Word no Confluence.

2. **Semana 3 — Primeira intervenção não documentada** — Um cientista de dados precisa de acesso a um bucket S3 adicional. Um administrador modifica a IAM role associada ao projeto diretamente no console IAM, sem abrir ticket de change management. A modificação não é refletida em nenhum documento de configuração.

3. **Semana 8 — Staging diverge de produção** — Ao preparar um novo projeto de ML, o engenheiro de plataforma recria o ambiente de staging seguindo o runbook original. O ambiente de staging agora tem configuração de IAM diferente do ambiente de produção. A diferença não é detectada porque não há mecanismo de comparação de estado.

4. **Semana 14 — Falha de promoção para produção** — Um pipeline de dados promovido de staging para produção falha com erro de permissão negada. O diagnóstico leva 4 horas porque a diferença de configuração entre ambientes não é óbvia. O MTTR é inflado por investigação manual de políticas IAM no console.

5. **Semana 20 — Auditoria de compliance detecta desvio** — Auditores internos solicitam evidência das políticas IAM associadas a todos os projetos de ML que processam dados PII. A equipe de plataforma não consegue fornecer evidência versionada. O processo de coleta manual de evidências leva 3 dias e ainda assim produz documentação incompleta. O achado é registrado como observação de auditoria.

6. **Semana 22 — Decisão de remediação** — A equipe de plataforma decide adotar IaC para o SageMaker Unified Studio. Com o suporte ao Terraform agora disponível via módulo `terraform-aws-sagemaker-unified-studio`, o trabalho de remediação começa: importação do estado existente, codificação declarativa de domínios, roles, blueprints e project profiles, e integração ao pipeline CI/CD existente.

> **Causa Raiz: Ausência de Estado Declarativo Auditável:** O incidente não é causado por uma falha técnica pontual — é causado pela ausência estrutural de representação declarativa do estado da plataforma. Quando domínios SageMaker Unified Studio, IAM roles, blueprints e project profiles existem apenas como estado implícito no console AWS, qualquer intervenção manual cria divergência não rastreável. Em ambientes financeiros sujeitos a SOX, PCI-DSS ou regulamentações equivalentes, a incapacidade de demonstrar que a configuração de produção é idêntica à configuração aprovada no processo de change management é, por si só, um achado de auditoria. O Terraform não resolve o problema de governança por si só — mas sem ele, a governança é impossível de implementar de forma sustentável.

## Anatomia do Módulo: O que o Terraform Realmente Provisiona

O módulo `terraform-aws-sagemaker-unified-studio` é estruturado em camadas que mapeiam diretamente para os conceitos administrativos do SageMaker Unified Studio. O módulo raiz provisiona o domínio em si — o workspace gerenciado que representa a unidade organizacional principal — junto com as IAM roles necessárias para operação do serviço. Essa separação é importante: o módulo suporta tanto a criação de novas roles quanto a referência a roles IAM existentes, o que é crítico em ambientes financeiros onde as roles são gerenciadas por um time de segurança separado com seu próprio ciclo de vida de IaC.

Os sub-módulos seguem uma hierarquia que reflete a estrutura de governança do SageMaker Unified Studio: **blueprints** definem as capacidades técnicas disponíveis (por exemplo, um blueprint para projetos de ML com Glue, SageMaker Training e S3), **project profiles** compõem múltiplos blueprints em configurações reutilizáveis para tipos específicos de projeto, e **projects** são instâncias concretas criadas a partir de um project profile. Essa hierarquia permite que times de plataforma definam guardrails no nível do blueprint — por exemplo, restringindo quais regiões podem ser usadas ou quais tipos de instância são permitidos — e que times de produto consumam esses guardrails sem precisar entender a infraestrutura subjacente.

A integração é viabilizada pelo **Terraform AWS Cloud Control Provider**, que expõe recursos AWS via a API Cloud Control em vez de APIs de serviço individuais. Isso tem implicações práticas: o Cloud Control Provider tem semântica de operações ligeiramente diferente do provider AWS tradicional — em particular, operações de criação e atualização são assíncronas e o provider precisa fazer polling para confirmar conclusão. Em pipelines CI/CD com timeouts agressivos, isso pode causar falsos negativos. A configuração de `operation_timeout` no provider precisa ser calibrada para o tempo de provisionamento real do domínio SageMaker Unified Studio, que pode variar de 5 a 15 minutos dependendo da complexidade da configuração.

## Pipeline de Provisionamento: Terraform para SageMaker Unified Studio em Multi-Account

Fluxo de provisionamento declarativo do domínio SageMaker Unified Studio via módulo Terraform, mostrando a hierarquia de módulos, integração CI/CD, controle de acesso IAM e propagação entre contas dev/staging/prod.

### 🔧 IaC Source

- Git Repo terraform-aws-sus (ci)
- CI/CD Pipeline GitHub Actions / CodePipeline (ci)

### 🧩 Terraform Modules

- Root Module Domain + IAM Roles (compute)
- Sub-module Blueprints (compute)
- Sub-module Project Profiles (compute)
- Sub-module Projects (compute)

### 🔐 Security & State

- IAM Roles (new or existing) (security)
- S3 + DynamoDB TF State + Lock (storage)
- Cloud Control Provider API (edge)

### ☁️ AWS Accounts

- SUS Domain Dev Account (ai)
- SUS Domain Staging Account (ai)
- SUS Domain Prod Account (ai)

### Fluxos

- git -> cicd: PR merge dispara
- cicd -> root_mod: terraform apply
- root_mod -> bp_mod: compõe
- bp_mod -> pp_mod: agrega em perfil
- pp_mod -> proj_mod: instancia projeto
- root_mod -> iam: cria ou referencia
- root_mod -> tfstate: persiste estado
- proj_mod -> ccp: via Cloud Control API
- ccp -> dev_domain: provisiona (async)
- ccp -> stg_domain: provisiona (async)
- ccp -> prd_domain: provisiona (async)

## Remediação: Construindo a Fundação de IaC para Plataformas de IA

A remediação de um ambiente SageMaker Unified Studio previamente provisionado manualmente começa com `terraform import` — e aqui mora o primeiro ponto de atrito real. O Cloud Control Provider tem suporte a import, mas a qualidade do import depende da completude do schema CloudFormation subjacente para cada recurso. Em minha experiência com recursos que usam o Cloud Control Provider, é comum encontrar atributos que são write-only (como secrets ou parâmetros de configuração inicial) e que não são retornados nas operações de leitura. Esses atributos precisam ser definidos explicitamente no código Terraform após o import, e o `terraform plan` subsequente vai mostrar diferenças que não representam mudanças reais de infraestrutura — é necessário inspecionar manualmente e usar `lifecycle { ignore_changes }` com critério.

Para novos ambientes — o cenário ideal — a sequência de provisionamento deve seguir a hierarquia de módulos de forma estrita: domínio primeiro, blueprints em seguida, project profiles depois, e projetos por último. Cada camada tem dependências implícitas que o Terraform resolve via `depends_on` ou referências de output, mas é importante não tentar paralelizar o provisionamento de blueprints e o domínio na mesma execução `terraform apply` — o domínio precisa estar em estado `ACTIVE` antes que blueprints possam ser associados, e o Cloud Control Provider pode não capturar essa dependência de estado de forma confiável sem uma configuração explícita de `timeouts`.

A estratégia de workspace Terraform para multi-account deve usar um workspace por conta-ambiente (dev, staging, prod), com state backends separados em S3 com criptografia KMS e tabela DynamoDB para locking. A separação de state é crítica: um `terraform destroy` acidental em um workspace não deve ter visibilidade sobre recursos de outro workspace. O backend S3 deve ter versioning habilitado e MFA delete configurado para o bucket de estado de produção. O acesso ao state deve ser controlado via IAM com condições `aws:PrincipalArn` restringindo quais pipelines CI/CD podem ler e escrever em qual workspace.

## Governança de IAM: O Detalhe que Determina o Sucesso da Remediação

O suporte a roles IAM existentes no módulo `terraform-aws-sagemaker-unified-studio` é, na minha avaliação, a feature mais importante para adoção em ambientes financeiros — e também a mais fácil de implementar incorretamente. Em organizações com maturidade de segurança, as IAM roles para serviços de dados são gerenciadas por um time de segurança ou identidade separado, com seu próprio repositório Terraform, seu próprio ciclo de aprovação e suas próprias políticas de naming convention. A capacidade de referenciar essas roles existentes no módulo do SageMaker Unified Studio — em vez de criar novas — é o que permite integrar o provisionamento da plataforma de IA ao modelo de governança de identidade já estabelecido.

O padrão que recomendo é o seguinte: o repositório de IaC do time de segurança gerencia as roles IAM e exporta os ARNs via outputs do Terraform (ou via SSM Parameter Store para desacoplamento mais forte). O repositório de IaC da plataforma de IA consome esses ARNs como data sources ou parâmetros, e os passa para o módulo `terraform-aws-sagemaker-unified-studio` via a variável `existing_iam_roles`. Isso cria uma separação clara de responsabilidades: o time de segurança controla o que as roles podem fazer, e o time de plataforma controla como o SageMaker Unified Studio usa essas roles.

Um ponto crítico que frequentemente é negligenciado: as IAM roles associadas a projetos SageMaker Unified Studio precisam de permissões não apenas para os serviços de dados (S3, Glue, SageMaker), mas também para o serviço de catálogo unificado que governa o acesso a dados. Em ambientes com Lake Formation habilitado, as roles precisam de grants Lake Formation explícitos além das políticas IAM — e esses grants não são gerenciados pelo módulo Terraform do SageMaker Unified Studio, precisam ser provisionados separadamente. Esquecer esse detalhe é uma fonte comum de erros de permissão pós-deploy que levam horas para diagnosticar porque o erro aparece no nível do catálogo, não no nível IAM.

## Avaliação Well-Architected: Pilares Afetados pela Adoção de IaC para SageMaker Unified Studio

- **security**: IaC declarativo elimina o vetor de drift de IAM que é a causa raiz de achados de auditoria. Com o módulo Terraform, cada mudança em roles, blueprints e project profiles passa por code review e aprovação antes de ser aplicada. O state backend S3 com KMS e DynamoDB locking garante que o estado da plataforma é protegido com o mesmo nível de controle que os dados que ela processa. A condição `aws:PrincipalArn` no bucket de state garante que apenas pipelines CI/CD autorizados podem modificar o estado de produção — eliminando o vetor de modificação manual do state.
- **reliability**: A reprodutibilidade declarativa é a base da confiabilidade em plataformas de IA. Com o módulo Terraform, um domínio SageMaker Unified Studio pode ser recriado em uma nova conta em minutos, não dias. Blueprints e project profiles são versionados e podem ser promovidos entre ambientes com confiança de que o estado resultante é idêntico. O timeout assíncrono do Cloud Control Provider precisa ser configurado explicitamente (recomendo mínimo de 20 minutos para o provisionamento do domínio) para evitar falsos negativos em pipelines CI/CD.

## Anti-Padrões a Evitar na Adoção do Módulo Terraform para SageMaker Unified Studio

- **Monorepo único para todos os ambientes**: Usar um único workspace Terraform para dev, staging e prod com variáveis de ambiente elimina o isolamento de state e torna um `terraform apply` acidental em prod possível a partir de qualquer branch.
- **Criar IAM roles dentro do módulo SageMaker sem revisão de segurança**: O módulo suporta criação de novas roles, mas em ambientes financeiros, roles IAM devem passar pelo processo de revisão de segurança. Criar roles automaticamente sem esse processo viola o princípio de least privilege auditável.
- **Ignorar o timeout assíncrono do Cloud Control Provider**: Não configurar `operation_timeout` adequadamente resulta em pipelines que reportam sucesso quando o recurso ainda está sendo provisionado, levando a erros em steps subsequentes do pipeline.
- **Importar estado existente sem validar atributos write-only**: Após `terraform import`, o `terraform plan` pode mostrar diferenças em atributos write-only que não representam mudanças reais. Aplicar esse plan sem revisão pode causar recriação desnecessária de recursos.
- **Não versionar o módulo Terraform**: Usar `source = "git::..."` sem uma tag de versão fixa significa que uma atualização do módulo upstream pode mudar o comportamento do seu pipeline sem aviso. Sempre pin para uma versão semântica específica.
- **Provisionar Lake Formation grants fora do escopo do módulo sem documentação**: O módulo não gerencia Lake Formation grants, mas os projetos SageMaker Unified Studio dependem deles. Não documentar essa dependência externa leva a erros de permissão pós-deploy difíceis de diagnosticar.

> **Nota do Curador: O que Eu Faria de Diferente:** Em todo projeto de plataforma de dados que operei, o maior arrependimento consistente é não ter estabelecido IaC desde o dia zero — e o SageMaker Unified Studio não é exceção. Se eu estivesse iniciando uma implementação hoje, usaria o módulo `terraform-aws-sagemaker-unified-studio` com workspaces separados por conta, state backend S3 com KMS e lock DynamoDB, e roles IAM gerenciadas por um repositório separado de identidade — com os ARNs consumidos via SSM Parameter Store para desacoplamento real entre os times de segurança e plataforma. O ponto que eu enfatizaria para qualquer equipe: a hierarquia blueprint → project profile → project não é apenas uma abstração técnica, é um modelo de governança — e definir quem tem permissão de modificar cada camada via políticas de branch protection no Git é tão importante quanto a configuração do Terraform em si. A lição mais cara que aprendi é que governança implementada depois de um incidente custa dez vezes mais do que governança implementada no dia zero.

## Veredicto: IaC para Plataformas de IA não é Opcional em Ambientes Financeiros

O suporte ao Terraform no Amazon SageMaker Unified Studio fecha uma lacuna de governança que era, na prática, um bloqueador para adoção enterprise séria da plataforma em ambientes regulados. O módulo `terraform-aws-sagemaker-unified-studio` oferece a hierarquia correta de abstrações — domínio, blueprints, project profiles, projetos — com suporte a roles IAM existentes que permite integração ao modelo de identidade corporativo sem contornar processos de segurança estabelecidos. A integração via Cloud Control Provider tem nuances operacionais (timeouts assíncronos, atributos write-only no import) que precisam ser tratadas explicitamente, mas nenhuma delas é um bloqueador — são trade-offs conhecidos e gerenciáveis. **Minha recomendação é direta: qualquer equipe que está operando ou planejando operar SageMaker Unified Studio em um ambiente sujeito a auditoria de compliance deve adotar este módulo imediatamente, começando por novos ambientes e planejando a migração de ambientes existentes via `terraform import`.** A alternativa — continuar com provisionamento manual — é aceitar que o próximo achado de auditoria sobre drift de configuração de IAM em sua plataforma de IA é apenas uma questão de tempo.

**Rating:** Adoção Imediata / Immediate Adoption

## 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 (open-source module, aws-ia)](https://github.com/aws-ia/terraform-aws-sagemaker-unified-studio)
- [AWS Guidance: Developing a Data & AI Foundation with Amazon SageMaker (Terraform modules)](https://docs.aws.amazon.com/solutions/developing-a-data-and-ai-foundation-with-amazon-sagemaker/)
- [AWS DevOps 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 ML 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/)
- [Amazon SageMaker Unified Studio Administrator Guide](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/)
- [AWS Control Tower: AFT Provisioning Framework (IaC governance reference)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)