Initializing Techhub.cafe

juniorAWS Machine Learning

What is the difference between SageMaker Studio and a notebook instance?

Updated Aug 1, 2026

Short answer

A notebook instance is a single managed EC2 box running Jupyter that you start and stop; Studio is an integrated IDE where notebooks, jobs, pipelines, the registry and experiments share one environment and compute is attached per notebook.

Deep explanation

Notebook instances are the original, simpler model: one EC2 instance, one instance type for everything you do on it, billed while running. If you need a GPU for one experiment, you resize the whole instance.

Studio decouples the workspace from the compute. Each notebook picks its own kernel and instance type, so you can run a light EDA notebook on ml.t3.medium and a training experiment on ml.g5.xlarge in the same session, and switch without moving files. Studio also hosts the visual tooling that has no equivalent on a notebook instance: the Pipelines DAG view, Model Registry, Experiments comparison, Data Wrangler, and Clarify reports.

Operationally the important differences are:

  • Storage — Studio gives each user an EFS home directory that persists independently of any running kernel; a notebook instance uses an EBS volume tied to that instance.
  • Isolation — Studio has user profiles within a domain, so team members get separate spaces and can be given separate execution roles.
  • Cost shape — Studio charges for the kernel instances actually running; shut down the kernel and the charge stops while your files remain.
Python
import boto3
sm = boto3.client("sagemaker")


# Find kernels left running — the usual source of surprise Studio cost
for app in sm.list_apps(DomainIdEquals="d-abc123")["Apps"]:
    if app["Status"] == "InService" and app["AppType"] == "KernelGateway":
        print(app["UserProfileName"], app["AppName"], app["ResourceSpec"]["InstanceType"])
        # sm.delete_app(DomainId=..., UserProfileName=..., AppType=..., AppName=...)

Note the pattern regardless of which you use: do exploration in the notebook, do real work in jobs. A notebook that trains a production model on its own instance is a reproducibility problem — nothing about it is versioned or repeatable. Use the notebook to author the script, then submit a training job.

Real-world example

A data science team of twelve runs one Studio domain with per-user profiles. Analysts default to a small CPU kernel; when someone needs a GPU they switch instance type on that notebook alone. A lifecycle configuration shuts idle kernels down after an hour, which cut their notebook spend by well over half — previously several forgotten GPU notebook instances ran all weekend.

Common mistakes

  • - Leaving Studio kernels running. The domain costs nothing idle, but each running kernel app bills by the hour.
  • - Training production models in a notebook rather than submitting a job, leaving results unreproducible.
  • - Installing packages with `pip install` in a cell and assuming they persist
  • use a lifecycle configuration or a custom image instead.
  • - Sharing one user profile across a team, which destroys per-user attribution and access separation.
  • - Storing large datasets in the Studio home directory rather than S3, inflating EFS cost and slowing startup.

Follow-up questions

  • How do you stop people forgetting to shut kernels down?
  • How do you make a team's notebook environment reproducible?
  • Why not just run notebooks locally against AWS?

More AWS Machine Learning interview questions

View all →