Initializing Techhub.cafe

juniorAWS Machine Learning

What are SageMaker built-in algorithms and when would you use one?

Updated Aug 1, 2026

Short answer

Built-in algorithms are AWS-optimised implementations (XGBoost, Linear Learner, DeepAR, BlazingText, Object Detection and others) delivered as managed containers, so you provide data and hyperparameters rather than training code.

Deep explanation

Built-in algorithms sit between "call an API" and "write your own training script". You get a container AWS has tuned for its hardware, often with GPU support and distributed training already handled.

Frequently referenced ones:

  • XGBoost — gradient-boosted trees; the default for tabular problems and still the most-used algorithm in production ML.
  • Linear Learner — linear/logistic models trained with several objectives in parallel, picking the best.
  • DeepAR — probabilistic forecasting across many related time series.
  • BlazingText — fast Word2Vec and text classification.
  • K-NN, K-Means, PCA, Random Cut Forest — retrieval, clustering, dimensionality reduction and anomaly detection.
  • Object Detection, Image Classification, Semantic Segmentation — vision, usually with transfer learning.

The catch that dominates real usage: several built-ins require specific input formats. XGBoost in CSV mode expects the target in the first column and no header row — a rule that has silently corrupted countless first attempts.

Python
from sagemaker import image_uris
from sagemaker.estimator import Estimator
from sagemaker.inputs import TrainingInput


container = image_uris.retrieve("xgboost", region="eu-west-1", version="1.7-1")


xgb = Estimator(
    image_uri=container,
    role=role,
    instance_count=1,
    instance_type="ml.m5.2xlarge",
    output_path="s3://my-bucket/models/churn",
)


xgb.set_hyperparameters(
    objective="binary:logistic",
    num_round=300,
    max_depth=5,
    eta=0.2,
    subsample=0.8,
    scale_pos_weight=12,     # class imbalance: negatives / positives
    eval_metric="auc",
)


xgb.fit({
    # target MUST be column 0, no header
    "train":      TrainingInput("s3://my-bucket/churn/train/",      content_type="text/csv"),
    "validation": TrainingInput("s3://my-bucket/churn/validation/", content_type="text/csv"),
})

Supplying a validation channel is what enables early stopping and gives you an honest metric in CloudWatch rather than training-set optimism.

Modern practice note: for deep learning, SageMaker JumpStart has largely displaced the older vision built-ins — it offers pre-trained models you fine-tune with a few lines, which is usually both faster and more accurate than training from scratch.

Real-world example

A telecom built churn prediction with built-in XGBoost in an afternoon: export to S3 as CSV, train, tune with AMT, deploy. No training code was written. When they later needed a custom loss reflecting different costs for false positives and false negatives, they moved to script mode with the same XGBoost library — a natural migration path, since the built-in had already proved the business case.

Common mistakes

  • - Leaving a header row or putting the target anywhere but column 0 for XGBoost CSV — training "succeeds" and predicts nonsense.
  • - Skipping the validation channel, so early stopping never engages and you overfit silently.
  • - Choosing a built-in for a problem needing custom loss or architecture
  • script mode exists for exactly that.
  • - Ignoring `scale_pos_weight` (or equivalent) on imbalanced data and reporting 99% accuracy on a 1% positive class.
  • - Using an outdated pinned version — always retrieve a current framework version rather than copying an old tutorial's tag.

Follow-up questions

  • How do you move from a built-in algorithm to custom code without a rewrite?
  • Why does XGBoost remain the default for tabular data?
  • What is SageMaker JumpStart?

More AWS Machine Learning interview questions

View all →