Skip to main content
How do you create a SageMaker training job? Programmatically — using an estimator object from the SageMaker Python SDK. An estimator encapsulates the training-job configuration: compute resources (for example, ml.c5.24xlarge), input data locations (Amazon S3 paths), and the output location where the model artifact (TGZ) will be saved. When you call an estimator’s fit(), SageMaker provisions the requested instance(s), pulls the chosen container image with the algorithm, runs training, and tears down the instances when the job completes. Because SageMaker manages the underlying Amazon EC2 instances, you don’t manage them directly and are billed only while the training resources are running.
A slide titled "Workflow: Estimator Object Class" that explains an estimator represents a machine learning training job. Three boxes note its responsibilities: sets up computing resources, manages data input and storage, and runs training on AWS SageMaker.

Estimator class and convenience subclasses

The Estimator base class represents generic training jobs. SageMaker also provides convenience subclasses for many built-in algorithms and frameworks (for example, LinearLearner, XGBoost wrappers, scikit-learn, PyTorch, TensorFlow). These subclass wrappers automatically pick the correct container image for the algorithm so you don’t need to specify an image URI manually. Below is a concrete example using the LinearLearner estimator subclass for a regression task. It shows creating the estimator, specifying instance type/count, S3 input/output, hyperparameters, and launching training with .fit().
Replace the example role ARN with your execution role or use get_execution_role() in a SageMaker notebook. Ensure the Amazon S3 paths exist and are accessible to the execution role.
This simple example will:
  • Provision the instance(s),
  • Pull the LinearLearner container,
  • Read training data from S3,
  • Run training using the specified hyperparameters,
  • Write the model artifact (TGZ) to the specified output path.
Using the SDK keeps your code compact and focused on the ML task rather than infrastructure plumbing.

Custom containers and the base Estimator

If you need a custom container image or an algorithm wrapper not available as a convenience class, use the Estimator base class and supply an image URI. The example below shows how to retrieve a SageMaker-provided XGBoost image URI and construct a base Estimator.

Hyperparameters — controlling training behavior

Hyperparameters are preset configuration values that control training behavior. They are passed to the training container and affect optimization, regularization, preprocessing, and loss computation. Many convenience estimator classes accept a hyperparameters dictionary; otherwise set them in your training script or container. Common hyperparameters and considerations:
A presentation slide titled "Workflow: HyperParameters" that defines hyperparameters as preset configurations for a machine learning algorithm before training. It lists three points: algorithm-specific settings for model training; can be set explicitly for LinearLearner; and SageMaker uses defaults if not specified.

Regularization and preprocessing hyperparameters

Regularization helps prevent overfitting and improves generalization:
  • L1 regularization (sparsity): pushes some weights toward zero, which can effectively remove irrelevant features.
  • L2 regularization (weight decay): penalizes large weights to produce smoother models.
Preprocessing flags (for example, normalize_data or normalize_label) instruct the container to perform scaling/normalization before training. Use these only if your data pipeline hasn’t already standardized the features/labels.

Loss function

The loss function describes what the training process minimizes. For regression, common choices include:
  • absolute loss (L1): sum of absolute residuals — more robust to outliers
  • squared loss (L2): sum of squared residuals — penalizes large errors more heavily
Selecting a loss function affects sensitivity to outliers and convergence dynamics.

Automated hyperparameter tuning (SageMaker Hyperparameter Tuning)

Manually searching hyperparameters is time-consuming. SageMaker Hyperparameter Tuning automates this by launching multiple training jobs (trials) across a defined hyperparameter search space and selecting the best trial based on an objective metric (for example, validation RMSE or validation accuracy). You must define:
  • objective_metric_name: the metric to optimize and whether to minimize or maximize,
  • hyperparameter_ranges: continuous or discrete ranges for each hyperparameter,
  • max_jobs: total number of trials,
  • max_parallel_jobs: number of concurrent trials,
  • metric_definitions: regex patterns to extract the objective metric from training logs (ensure the regex matches the container’s log format).
Example: building a HyperparameterTuner around an XGBoost estimator.
The tuner will run up to max_jobs training trials and return the best hyperparameter set according to the specified objective metric. Ensure the metric extraction regex matches the container’s log output so SageMaker can parse the metric successfully.

Quick summary

  • Use estimator subclasses for built-in algorithms (LinearLearner, XGBoost wrappers, etc.) — the SDK chooses the correct container image.
  • Use the base Estimator to supply a custom container image.
  • Configure hyperparameters to control optimization, regularization, preprocessing, and loss.
  • Use SageMaker Hyperparameter Tuning to automatically search for the best hyperparameters; define search space, objective metric, and job counts.
  • Always ensure S3 data paths and IAM execution roles are correctly configured and permissioned.

Watch Video