Mental model
SageMaker service vs Python SDK
The SDK is the programming interface; SageMaker is the managed AWS service executing the jobs and resources.
lifecycle requirement / configuration
configured SageMaker object or managed resource
The SDK configures and orchestrates SageMaker resources; the actual training or inference runs on managed AWS infrastructure.
Mental model
What this means before worrying about syntax.
Your Python code constructs job/resource configuration. AWS runs the managed training, hosting, processing, registry and monitoring resources.
- Your local Python process is a control-plane client.
- Managed SageMaker compute runs training/inference; S3 stores durable data/artifacts.
- IAM, VPC, KMS and CloudWatch are part of the production architecture.
Python SDK -> SageMaker API/resources -> managed AWS compute/storage/networking
Implementation anatomy
The sequence you would actually build or configure.
- 1
SDK constructs configuration and calls SageMaker APIs.
- 2
Training jobs receive managed compute and an execution role.
- 3
Endpoints are managed serving resources; batch jobs are finite jobs.
Concrete example
A real model-development or production flow.
PyCharm/notebook submits job
S3 holds train/validation data
Managed training instance runs container
Artifact is uploaded to S3
Managed endpoint runs inference container
Implementation lab
Concrete code, data manipulation and configuration for this lifecycle step.
Control plane: your Python code submits a managed job
from sagemaker.core.helper.session_helper import Session
from sagemaker.train import ModelTrainer
from sagemaker.train.configs import SourceCode
session = Session()
trainer = ModelTrainer(
training_image=TRAINING_IMAGE_URI,
source_code=SourceCode(
source_dir="src",
entry_script="train.py",
),
role=SAGEMAKER_ROLE_ARN,
sagemaker_session=session,
)
# This call submits work to the SageMaker service.
trainer.train(input_data_config=inputs)
Data plane: code running inside the training container
This is the practical boundary: the SDK is outside the job; train.py executes inside the job container.
# train.py -- this code runs on the managed training instance.
import os
train_dir = os.environ["SM_CHANNEL_TRAIN"]
model_dir = os.environ["SM_MODEL_DIR"]
print("training data mounted at:", train_dir)
print("model output must be written to:", model_dir)
Design decisions that matter
- Keep local-development assumptions separate from production execution.
- Design IAM/networking independently of model logic.
Common failure modes
- Local files/imports do not automatically exist in managed containers.
- SDK version on your laptop and framework version inside the image are separate concerns.
Production readiness check
Items to close before treating this step as production-ready.