Set Up SageMaker Unified Studio: Domains, Projects, and Lakehouse Access

Every SageMaker engagement we start in 2026 opens with the same question: "Are we on Studio, or on the new Unified Studio?" The answer changes who provisions what, where notebooks live, how data access is granted, and which console URL your team logs into. This tutorial walks through standing up Amazon SageMaker Unified Studio properly — a domain, sign-in, a project, and lakehouse data access — and then getting a notebook that can both query governed data and train a model with the SageMaker Python SDK.

If the rename itself is still fuzzy for your team, read SageMaker vs. SageMaker AI first. Short version: SageMaker AI is the ML platform you already know (training jobs, endpoints, pipelines). SageMaker Unified Studio is the newer, wider workspace that puts SageMaker AI next to Athena, Glue, EMR, Redshift, and Bedrock model access behind one governed front door.

What Unified Studio actually is

Three things get conflated, so be precise with stakeholders:

Name	What it is	You still need it if...
SageMaker AI (Studio)	The ML IDE and control plane: JupyterLab spaces, training jobs, endpoints, pipelines, MLflow	You do model development and deployment. Nothing here is deprecated.
SageMaker Unified Studio	A governed multi-persona workspace with domains, projects, and a business catalog, built on the Amazon DataZone control plane	You have data engineers, analysts, and ML people who need shared, permissioned data
SageMaker Lakehouse	Unified access over S3 (Iceberg) and Redshift data through the Glue Data Catalog	You want one query surface across the lake and the warehouse

Unified Studio does not replace SageMaker AI. It wraps it. Inside a Unified Studio project you can still open JupyterLab, still call sagemaker.estimator.Estimator, and still deploy an endpoint. What changes is who granted you the data and the compute, and the fact that the project — not an individual's IAM role — is the unit of access.

When it is worth adopting

Adopt it if:

• More than one persona touches the same data (analysts querying, engineers building features, ML people training).
• You need auditable, request-and-approve data access rather than a wiki page of bucket names.
• You are already running Redshift plus S3 and want a single catalog.

Skip it for now if a two-person team ships one model from one bucket. The governance layer has real setup cost, and plain SageMaker AI Studio is still fully supported. We say this to clients often enough that it is worth saying here: do not migrate for the logo change.

1. Prerequisites

Before you create anything:

• Identity. Unified Studio expects AWS IAM Identity Center for human sign-in (an organization instance, or an account instance if you are not using AWS Organizations). Decide this first; retrofitting identity is the painful part.
• VPC and subnets. The domain needs a VPC with subnets that can reach AWS services. Private subnets with NAT or VPC endpoints both work; interface endpoints are the usual enterprise answer.
• A Glue Data Catalog in the same account and region as your data.
• Permissions. Whoever runs the setup needs administrator-level rights the first time, because domain creation provisions several service roles.

Pick one region and stay in it for the pilot. Cross-region catalogs are possible, and they are not a good first exercise.

2. Create the domain

The console path (SageMaker console -> Unified Studio -> Create domain) is the one AWS keeps current, and for the first domain it is the right choice: the quick-setup option creates the IAM roles, the default VPC wiring, and the initial project profiles for you. Choose "quick setup" for a pilot, "custom" when a platform team owns networking.

The same control plane is scriptable through the DataZone APIs, which is what you want for a repeatable landing zone:

aws datazone create-domain \
  --name "acme-analytics" \
  --description "Unified Studio domain for ACME data and ML" \
  --domain-execution-role "arn:aws:iam::111122223333:role/service-role/AmazonSageMakerDomainExecution" \
  --service-role "arn:aws:iam::111122223333:role/service-role/AmazonSageMakerDomainService" \
  --domain-version V2 \
  --single-sign-on '{"type":"IAM_IDC","userAssignment":"AUTOMATIC"}' \
  --region us-east-1

--domain-version V2 is the flag that makes it a Unified Studio domain rather than a classic DataZone domain — get that wrong and you will end up in the old console. Creation returns a domain ID (dzd_xxxxxxxx) and a portal URL of the form https://dzd_xxxxxxxx.sagemaker.us-east-1.on.aws. That URL, not the AWS console, is where your users will live. Verify with:

aws datazone list-domains --region us-east-1 \
  --query 'items[].{id:id,name:name,status:status,url:portalUrl}' --output table

Wait for AVAILABLE before doing anything else. Then add users: in the Unified Studio portal, Manage members at the domain level, adding IAM Identity Center users or groups. Add groups, never individuals — the first domain that accumulates 40 hand-added users is the one nobody can audit.

3. Create a project (and understand project profiles)

A project is the working unit: it owns a set of members, a data catalog scope, compute resources, and its own IAM project role. A project profile is the template that decides which capabilities a project gets — an analytics-flavoured profile with Athena, Redshift, and Glue, or an ML-flavoured profile that provisions SageMaker AI.

For an ML team, create the project from the profile that includes SageMaker AI (in most domains it is named something like "All capabilities" or "SQL analytics and ML"). Console is fine; the API equivalent:

aws datazone list-project-profiles --domain-identifier dzd_xxxxxxxx --region us-east-1

aws datazone create-project \
  --domain-identifier dzd_xxxxxxxx \
  --name "churn-model" \
  --description "Churn propensity modeling" \
  --project-profile-id <profile-id> \
  --region us-east-1

Project creation takes a few minutes because it provisions the underlying environments (a Glue database, S3 prefixes, the SageMaker AI space configuration). Each project gets its own S3 location and its own database in the catalog; that isolation is the whole point, so resist the urge to run every team out of one project.

4. Wire up data: the lakehouse view

Inside the project, the Data panel shows three sources: the project's own Glue database (<project>_db or similar), catalogs federated into SageMaker Lakehouse (Redshift, Iceberg tables in S3, and supported third-party sources), and assets published to the SageMaker Catalog by other projects.

Two access patterns matter:

1. Own it. Create tables in the project's database — Glue crawlers, an ETL job, or CREATE TABLE AS SELECT from the query editor. Anything here is automatically readable by project members.
2. Subscribe to it. Find an asset in the catalog, request a subscription, and an owner approves. Lake Formation grants are issued behind the scenes; the requesting project role gets read access with no bucket policy edits.

Subscription is the feature that justifies the platform. It replaces the "email the data engineer, get a bucket policy amended, forget to revoke it" cycle with an auditable grant. Set a real approval owner per domain unit on day one, or every request queues behind a platform engineer who does not know the data.

Query from the project's SQL editor, or from a notebook cell:

%%sql
SELECT customer_id,
       COUNT(*) AS events_30d,
       MAX(event_ts) AS last_seen
FROM churn_model_db.raw_events
WHERE event_ts > current_date - interval '30' day
GROUP BY customer_id

The %%sql magic is available in Unified Studio notebooks and routes to the connection you select (Athena, Redshift, or Spark). Materialize the result to the project's S3 location as Parquet or Iceberg, and you have a training dataset that is governed rather than copied.

5. Train and deploy from inside the project

This is the part teams worry about, and it is undramatic. Open JupyterLab in the project, and the SageMaker Python SDK works as it always did — the difference is that the execution role is the project role:

import sagemaker
from sagemaker.sklearn.estimator import SKLearn

sess = sagemaker.Session()
role = sagemaker.get_execution_role()          # the project role
bucket = sess.default_bucket()                 # the project's S3 location

est = SKLearn(
    entry_point="train.py",
    source_dir="src",
    role=role,
    instance_type="ml.m5.xlarge",
    framework_version="1.2-1",
    py_version="py3",
    output_path=f"s3://{bucket}/churn/models",
    environment={"PROJECT": "churn-model"},
)
est.fit({"train": f"s3://{bucket}/churn/train/"})

Two consequences of the project role worth planning for:

• Anything the training job reads must be granted to the project, not to a personal role. Data pulled in through a subscription is; a random bucket a data scientist used last quarter is not.
• Managed MLflow tracking servers, model registry entries, and pipelines created here are scoped to the project. If you already run a central registry, decide deliberately whether models are registered per project or promoted into a shared account — see A Minimal MLOps Loop for the promotion pattern, and our managed MLflow guide for tracking setup.

Deployment is unchanged: endpoints created from a project are ordinary SageMaker AI endpoints, visible in the SageMaker AI console, scalable and monitorable the usual ways (drift monitoring, safe endpoint updates).

Migration notes for existing Studio users

• Nothing is forced. Existing SageMaker AI (Studio) domains keep working. Unified Studio is a separate domain type; you can run both while you evaluate.
• Notebooks move by copy. There is no in-place conversion of a Studio space into a Unified Studio project space. Get code into Git, then clone it into the project — which is what you should have been doing anyway.
• Costs are the same underneath. Unified Studio itself is not the line item; the compute (JupyterLab spaces, training jobs, Athena scans, Redshift, endpoints) is. Idle JupyterLab spaces inside projects bill exactly like idle spaces outside them, so keep the auto-shutdown lifecycle configuration you already use.
• Budget for identity work. In every migration we have run, IAM Identity Center setup and group mapping took longer than the domain and projects combined.

A sane rollout order

1. One domain in one region, quick setup, in a sandbox account.
2. One pilot project with a real (small) dataset and two personas.
3. Prove the subscription workflow end to end, including a revoke.
4. Codify domain and project creation in CloudFormation or Terraform before the second team arrives.
5. Only then migrate a production workload, starting with training, leaving inference where it is.

Step 4 is the one people skip and regret. Clicking a domain together in the console is a fine way to learn it and a bad way to own it.

---

Rolling out Unified Studio across teams, or deciding whether you should? Our SageMaker consultants do this as a two-to-four week engagement, including the landing-zone templates and the access-governance model. Get in touch.