Skip to main content

Module 2 — Studio, notebooks and working environments

You will spend more time in a notebook than on any single training job, so it is worth knowing exactly what you are running and what it is costing you. This module covers Studio, the older notebook instances, the image and kernel model, and the auto-shutdown extension that keeps the invoice honest.

Domain, user profiles and spaces​

SageMaker Studio lives inside a domain, an account-level object that carries the authentication mode (IAM or IAM Identity Center), the VPC configuration, the default execution role and the shared EFS storage. One domain per team is the usual pattern. Inside the domain, each engineer gets a user profile with an individual execution role, private EFS folder and a set of spaces — a space being an isolated JupyterLab instance that can be started, stopped and resized without touching the profile.

The consequence to remember is that a stopped space costs nothing but its EFS storage (a few cents per gigabyte per month), while a running space is billed for whichever instance it is on. Starting a space is a matter of seconds; there is no reason to leave one running when you leave for lunch.

Studio versus notebook instances​

Two options coexist and the vocabulary is easy to confuse.

SageMaker Studio is the recommended path since 2020: a browser IDE with notebooks, a terminal, a debugger, the model registry and the pipelines UI in one place. Each notebook runs on a kernel instance that Studio starts on demand from a Docker image.

Notebook instances are the older offering: a single EC2 instance running a JupyterLab, provisioned once and left running until you stop it. They still exist, they are simpler to reason about, and they are the more expensive default because they do not share resources with anything else and a single kernel change forces a restart.

For the rest of this course, "notebook" means a Studio notebook unless stated otherwise.

Images, kernels and the environment you actually get​

Each Studio notebook picks an image (a Docker image) and a kernel (a specific Python interpreter inside that image). The built-in images come pre-loaded: SageMaker Distribution for general Python 3.11 with the main ML libraries, Data Science for pandas and scikit-learn only, PyTorch 2.1.0 Python 3.10 CPU for PyTorch training, and half a dozen framework-specific variants. Choosing the smallest image that contains what you need speeds up kernel startup by a factor of two or three.

If a library is missing, pip install --user writes to the private EFS folder and persists across restarts of the same profile, but not across image changes. For anything more than a one-off dependency, build a custom image: a small Dockerfile on top of a public SageMaker image, pushed to ECR, then registered in the domain. That image is then available in the "Change image" menu of every notebook in the domain.

FROM public.ecr.aws/sagemaker/sagemaker-distribution:1.8-cpu

USER root
RUN pip install --no-cache-dir pyarrow==15.0.0 shap==0.44.0
USER 1000

Choosing the kernel instance​

The instance types available to a notebook are a subset of the full EC2 catalog, prefixed with ml.. For interactive work, three families cover most cases: ml.t3.medium at about $0.05 per hour for reading data and light plots, ml.m5.large at about $0.12 per hour for pandas on a few gigabytes, and ml.g4dn.xlarge at about $0.74 per hour when you need a GPU to prototype a neural network. Never train a real model on a notebook instance — module 4 covers dedicated training jobs on transient instances, which are cheaper and cleaner.

Auto-shutdown, the extension that pays for itself​

The JupyterLab Auto-Shutdown extension, published by AWS, terminates a kernel after a configurable idle period (usually 60 minutes). It is a two-line script to add to the domain's lifecycle configuration:

#!/bin/bash
set -eux
pip install --quiet sagemaker-studio-autoshutdown-extension

The gain is not theoretical. A ml.g4dn.xlarge kernel forgotten open on a Friday runs 65 hours until Monday morning, at 65 × $0.74 ≈ $48. Multiplied across a team of eight and repeated monthly, that is the wage of a junior engineer wasted on idle Jupyter. The auto-shutdown makes the failure mode expire on its own.

Never store credentials in a notebook

An IAM access key hard-coded in a cell reappears in EFS snapshots, in exports and eventually in a screenshot on Slack. The execution role of the notebook already grants the access it needs; use it. If you must reach a resource in another account, assume a cross-account role via boto3.client('sts').assume_role(...) at runtime — never paste a static key.

Summary​

  • One domain per team, one user profile per engineer, spaces you start and stop like laptops.
  • Studio replaces the older notebook instances; kernel instances are billed like any other, so stop them.
  • Images and kernels define your environment; a custom image on ECR is the reliable way to add libraries.
  • Auto-shutdown is not optional: the forgotten Friday kernel is the most common line on the invoice.

Next module: get the churn dataset onto S3 in a form the training jobs of module 4 can consume.