Scheduling Amazon SageMaker Notebook Instance
sagemaker:StopNotebookInstanceCan ZopNight schedule 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.
How the stop works
| Field | Value |
|---|---|
| Behaviour | notebook stopped via sagemaker:StopNotebookInstance and started via sagemaker:StartNotebookInstance on schedule. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
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.