Skip to main content
In this lesson we cover Amazon SageMaker Domains and the SageMaker Studio web IDE. You’ll learn why Studio was introduced, how a SageMaker Domain maps to the Studio experience, the trade-offs between quick and manual domain setup, and how to launch Studio and manage user profiles. We will:
  • Review limitations of SageMaker Jupyter notebook instances and why Studio is preferable for team workflows.
  • Explain the components and architecture of a SageMaker Domain and how Studio uses them.
  • Compare quick setup vs. manual (organization) setup choices.
  • Walk through accessing Studio from the AWS Management Console and managing user profiles and personal apps.

​
Limitations of Jupyter notebook instances

SageMaker supports single-user Jupyter notebook instances, but they present practical and operational limits for teams and production workflows:
  • One instance per user leads to many long-running VMs when teams each create an instance.
  • Billing continues while instances run; they do not auto-stop by default, increasing costs if users forget to shut them down.
  • No built-in experiment tracking or standard reproducibility workflow.
  • No automatic Git integration—each user must clone or configure repositories manually.
  • Notebook instances provide only the Jupyter environment; integrating other SageMaker features often requires manual work.
These limitations motivate an integrated, collaborative IDE that bundles notebooks, experiment tracking, Git, and orchestration tools.
Limitation AreaNotebook InstancesSageMaker Studio
Multi-user collaborationNo (one-to-one)Shared workspaces available
Experiment trackingNone built-inSageMaker Experiments, MLflow integrations
Git integrationManualBuilt-in or mountable repos
Cost controlManual stop requiredCentralized management and policies
Multi-IDE supportJupyter onlyJupyterLab, RStudio, Code Editor, and more
A presentation slide titled "Problem: Jupyter Instances Limited." It lists five numbered issues: no experiment tracking; manual Git setup; each user manages instances independently; manual stop risks extra charges; and limited to notebooks requiring external tools.

​
Experiment tracking and reproducibility

Tracking experiment inputs (data versions, preprocessing, model code, hyperparameters) and outputs (metrics, model artifacts) is essential for reproducibility and collaboration. Without a standard approach, teams risk losing context from prior runs—hyperparameters or dataset versions can be forgotten, and results become hard to compare. SageMaker Studio addresses this by offering integrated experiment tools: Third-party tools (CometML, Truera, etc.) can still be used, but Studio reduces dependency overhead by providing first-class experiment features and easier reproducibility.

​
SageMaker Domain and Studio architecture

SageMaker Studio is deployed inside a SageMaker Domain. A Domain is an administrative boundary that groups users, shared storage, execution roles, and policy controls. Main components include:
  • Shared file system: an Amazon EFS share is created for the Domain so users can access shared files. Note that Studio storage architectures and trade-offs have evolved; evaluate EFS performance and costs for production use.
  • User profiles: each person must have a user profile in the Domain to open Studio. An AWS account or IAM user alone does not grant Studio access; the user profile binds the user to the Domain.
  • Studio applications: the browser IDE exposes multiple applications (JupyterLab, RStudio, Code Editor, and other Studio apps).
  • Execution role(s): IAM role(s) define what AWS resources Studio and user workloads can access (S3 buckets, model APIs, etc.).
A dark-themed diagram titled "Solution: SageMaker Domain and Studio" showing the architecture and components of an AWS SageMaker domain. It highlights user profiles, shared Elastic File System (EFS) storage, Studio applications (JupyterLab, R Studio, Code Editor, Studio Classic), and the IAM execution role.

​
What Studio provides over notebook instances

Moving from isolated notebook instances to a SageMaker Domain + Studio yields several operational and developer productivity benefits:
  • Shared workspaces and file storage for team collaboration.
  • Built-in or easily mounted Git repositories to support version-control driven workflows.
  • Native experiment tracking (SageMaker Experiments) plus integrations like MLflow.
  • Orchestration with SageMaker Pipelines to build repeatable ML workflows: https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines.html
  • Fine-grained IAM control for datasets, models, and pipelines.
  • Multiple hosted IDEs: JupyterLab, RStudio (check licensing), and a hosted VS Code-like Code Editor.
Summary of benefits:
FeatureNotebook InstancesStudio (Domain)
CollaborationLimitedShared EFS, shared notebooks
Experiment managementExternal toolingBuilt-in and integrated
OrchestrationManualSageMaker Pipelines
IDE optionsJupyter onlyJupyterLab, RStudio, Code Editor
Access controlInstance-levelDomain + IAM roles + user profiles
Studio Classic vs. current Studio
  • Studio Classic refers to the original UI and older architecture. AWS recommends using the current SageMaker Studio, which exposes newer capabilities and UI updates. Plan migration if you still use Studio Classic.

​
Accessing SageMaker Studio (console walkthrough)

To open Studio from the AWS Management Console:
  1. Open Amazon SageMaker.
  2. In the left navigation under “Applications and IDEs”, click Studio.
When creating a Domain, the console presents two provisioning paths: quick setup (single-user) and manual (organization) setup. Choose based on your needs: rapid evaluation vs. production readiness.
A presentation slide titled "Workflow: Creating a Domain" showing the Amazon SageMaker "Set up SageMaker Domain" screen. It displays side-by-side options for a single-user (quick setup) and an organization setup with feature checklists and a "Set up" button.

​
Quick setup vs. manual setup

  • Quick setup: fastest path to a Domain. It creates a Domain with defaults (region default VPC, default user profile). Ideal for personal learning, experiments, or proofs-of-concept.
  • Manual setup: required for production or regulated environments. It allows full control over VPC/subnets, KMS encryption keys, authentication (federated SSO via AWS Identity Center / Microsoft Entra), and granular IAM policies.
Use quick setup for learning, demos, and short-term experimentation. For production, compliance, or private-network workloads, select manual setup to control networking, encryption, and authentication.
Manual setup considerations:
  • Security & access control: design custom IAM roles and policies, configure KMS keys, and integrate identity federation where needed.
  • Infrastructure & resources: choose subnets, EBS or other storage choices, and configure VPC endpoints for secure access.
  • Integration & compliance: enable audit logging, align with organizational policies, and integrate required services.
A presentation slide titled "Workflow: Creating a Domain" showing a three-column table of "Manual Setup Considerations." The columns list bullet points under "Security & Access Control," "Infrastructure & Resources," and "Integration & Compliance" (IAM/VPC/encryption, subnet/EBS/resource settings, and integration/audit items).
A dark-themed presentation slide titled "Workflow: Creating a Domain" with the subtitle "When to Choose Manual Setup." It lists six reasons: precise security control, integration with existing infrastructure, compliance with policies, cost optimization, custom network configurations, and specific authentication methods.
JupyterLab 3 notebooks on SageMaker Studio Classic have reached end of support. If you are still using Studio Classic, migrate to the current SageMaker Studio and newer JupyterLab versions to continue receiving security fixes and feature updates.

​
Domains, user profiles, and launching Studio

After a Domain is created:
  • The Studio section in SageMaker will show an “Open Studio” action under Applications and IDEs.
  • Domains contain user profiles—each person needs a user profile associated with the Domain to launch Studio. Having IAM credentials alone does not grant access.
  • Quick setup creates a default user profile; manual setup requires you to create user profiles explicitly.
To view or manage user profiles:
  1. In the SageMaker console sidebar, open “Admin configurations” → “Domains”.
  2. Click the domain name, then open the “User profiles” tab.
From the “User profiles” tab you can launch Studio on behalf of a user. The launch menu exposes the user’s available personal apps (for example: Studio, Canvas, TensorBoard, Profiler, Spaces) so the user can select which application to open.
A screenshot of an "Workflow: User Profiles" page in Amazon SageMaker showing domain details and the "User profiles" tab with a listed default user. A "Personal apps" launch menu is open on the right, showing options like Studio, Canvas, TensorBoard, Profiler, and Spaces.
When you open SageMaker Studio, it opens in a new browser tab at a Studio-specific endpoint (for example: https://studio-<unique-id>.<region>.sagemaker.aws), which is distinct from the AWS Management Console URL.

​
Summary

SageMaker Domains + SageMaker Studio deliver a managed, collaborative, and production-capable environment that addresses limitations of single-user notebook instances. Key takeaways:
  • Studio provides shared file storage, integrated experiment tracking, and pipeline orchestration.
  • Studio supports Git integration and multiple IDEs (JupyterLab, RStudio, Code Editor).
  • For rapid evaluation, use quick setup. For production, compliance, or private-network requirements, choose manual setup and design networking, encryption, and IAM accordingly.
  • Ensure migration from Studio Classic and older JupyterLab versions to benefit from continued support.
Links and references

Watch Video