IaC for AI Platforms: Terraform and SageMaker Unified Studio

In regulated financial environments — where every provisioned resource requires an audit trail, change approval and rollback capability — the absence of IaC for AI platforms creates a second-class infrastructure category. MLOps teams build sophisticated pipelines with Step Functions, MSK and Glue, but the SageMaker domain hosting all of it was created manually by an administrator eighteen months ago. Nobody knows exactly which IAM roles were created, which blueprints are active, or whether the staging environment is truly identical to production.

This gap is not cosmetic. When a central bank or SEC auditor asks for evidence that the production credit-model environment was configured according to the approved security policy, the answer "the domain was created manually" is a non-conformance finding. SageMaker Unified Studio aggregates critical services — Amazon DataZone for catalog governance, Amazon EMR for distributed processing, Amazon Redshift for analytics, Amazon Bedrock for GenAI — and each of those services has security configurations that must be auditable and reproducible.

The terraform-aws-sagemaker-unified-studio module addresses this through a composable approach: a root module that provisions the domain with managed IAM roles, and independent sub-modules for blueprints, project profiles and projects. This separation of responsibilities is deliberate and important — it allows different teams to control different platform layers without unnecessary coupling in Terraform state.

The most important technical detail in this launch is not the module itself, but the layer that enables it: the Terraform AWS Cloud Control Provider. Unlike the traditional hashicorp/aws provider, which maps AWS resources to Terraform resources with per-service custom logic, the Cloud Control Provider uses AWS's unified Cloud Control API to create, read, update and delete resources. This means new resource types become available in Terraform much faster — without waiting for HashiCorp to implement specific support.

The practical consequence is twofold. On the positive side, resources like the SageMaker Unified Studio domain, which have managed lifecycles and complex configurations, reach Terraform before the traditional provider supports them. On the negative side, the Cloud Control Provider has different drift detection semantics: it relies on the Cloud Control API's read handler, which for some resources returns only a subset of configurable attributes. This means terraform plan may report "no changes" even when configurations outside the handler's scope were manually altered in the console — exactly the kind of silent drift that destroys IaC reliability in financial environments.

To mitigate this in production, I combine the module with AWS Config Rules that detect drift in DataZone and SageMaker resources, and with CloudTrail + EventBridge to alert on any API call that modifies the domain outside the Terraform pipeline. The SLO here is not "zero drift" — it is "drift detected in under 15 minutes". This distinction matters: chasing zero drift via Terraform alone is more brittle than detecting and correcting drift quickly with proper observability.

This pattern solves a specific problem: provisioning and managing SageMaker Unified Studio domains as versioned, auditable and reproducible infrastructure across multiple accounts and environments. The conditions that make it the right choice are:

1. Multiple environments with required parity. If you have dev, staging and production for ML/AI workloads, and compliance requires that the production configuration be derivable from the same source of truth as staging, the Terraform module is the only approach that delivers this in an auditable way. The ability to create projects with existing IAM roles — rather than always creating new ones — is critical here: in financial environments, IAM roles go through a separate approval process and cannot be created ad-hoc by the platform pipeline.

2. Platform teams separate from product teams. The modular design of terraform-aws-sagemaker-unified-studio — domain in the root module, blueprints and project profiles in independent sub-modules — maps directly to the responsibility model where a Platform Engineering team controls the domain and IAM, while data teams control their own project profiles and projects. This is Data Mesh at the infrastructure level: data domains with controlled autonomy.

3. Need for documented disaster recovery. A manually created SageMaker Unified Studio domain has no defined RTO — nobody knows how long it takes to recreate everything from scratch. With the Terraform module, the environment recreation RTO is the time of terraform apply, which for a typical domain runs between 8 and 20 minutes depending on enabled blueprints. That is a real number that can enter your BIA (Business Impact Analysis).

The pattern is not the right choice when you have a single experimentation environment with no audit requirements, or when the team lacks sufficient Terraform maturity to safely manage remote state, modules and workspaces.

For a bank or asset manager that needs to operate credit models, fraud detection and portfolio analysis in a regulated environment, the reference design I would apply combines the Terraform module with an AWS Organizations account strategy and layered governance controls.

Account structure: Platform tooling account (where remote Terraform state lives in S3 with versioning and KMS CMK, and the DynamoDB lock table uses BillingMode: PAY_PER_REQUEST with point-in-time recovery enabled), AI/ML production account, staging account and development account. The CI/CD pipeline assumes roles via OIDC in each account — never uses access keys.

Terraform state layers: Layer 0 — SageMaker Unified Studio domain + IAM roles (managed by Platform Engineering team, apply requires manual approval in pipeline). Layer 1 — enabled blueprints (managed by Platform Engineering team with cost review). Layer 2 — project profiles (managed by tech leads of each data domain). Layer 3 — individual projects (managed by product teams with controlled self-service).

Specific security controls: Dedicated KMS CMK per environment for domain data encryption, with kms:ViaService condition restricting use to SageMaker and DataZone. SCPs in AWS Organizations blocking manual SageMaker domain creation outside the pipeline (Deny on sagemaker:CreateDomain except for the Terraform pipeline role). Custom AWS Config Rule verifying that all SageMaker domains have the ManagedBy: terraform tag — any domain without this tag triggers a P1 alert.

Observability: CloudWatch Dashboard with aws/sagemaker/unified-studio namespace metrics, CloudTrail Lake with saved query to detect manual domain modifications, and cost per project via Cost Allocation Tags mapped in project sub-modules. This last point is frequently overlooked: the Terraform module is the right place to ensure cost allocation tags are applied consistently across all domain resources.