# Scheduling Amazon SageMaker Notebook Instance

> Notebook schedules call sagemaker:StopNotebookInstance, ending the ML-compute charge while the attached ML storage volume (minimum 5 GB) persists and bills. Only /home/ec2-user/SageMaker survives the cycle: conda environments and packages installed elsewhere reset, lifecycle-configuration scripts rerun at every sagemaker:StartNotebookInstance, and start takes minutes.

Source: https://zop.dev/integrations/aws/sagemaker-notebook/schedule
Updated: 2026-08-19

---

## Stop ends the instance-hours

`sagemaker:StopNotebookInstance` halts the notebook's compute billing on the spot. For
GPU-backed notebooks that is the dominant charge, and idle-but-running notebooks left on
overnight are among the most common wasted spend on ML accounts. The paired
`sagemaker:StartNotebookInstance` runs on the morning cron.

## One directory survives

Persistence on a notebook instance is a single path: files under /home/ec2-user/SageMaker live
on the attached ML storage volume and come back after a stop. Everything outside it is
ephemeral instance state: conda environments created at the system level, apt and pip installs
outside the persisted path, kernels, /tmp scratch. A researcher who spends the afternoon
compiling a custom library into a system environment finds it gone at 8am unless it was
installed into, or scripted from, the persistent directory.

## Lifecycle configurations run again

The on-start lifecycle script executes at every scheduled start, not just the first boot. That
is the sanctioned home for environment rebuilds: reinstall packages, remount data sources,
re-register kernels. Keep the script fast. Lifecycle scripts have tight execution limits, and
a slow rebuild delays the notebook's availability past the cron time.

## The volume keeps billing

The ML storage volume, 5 GB minimum and sized at creation, bills per GB-month regardless of
instance state, as do any EFS mounts the notebook uses. Small money next to a GPU instance
rate, but it is why a "stopped" notebook never quite reaches zero on the invoice.

## Long jobs and the evening cutoff

A training cell still executing at the stop time is killed mid-run, and Jupyter will not warn
anyone. Notebooks are the wrong home for overnight training anyway. Jobs that must outlive the
schedule belong in SageMaker training jobs, which run on their own billed-per-job compute and
are untouched by the notebook's calendar.

The same cutoff applies to SSH sessions and background processes people forget about. Everything
alive on the instance ends at the stop, without ceremony.