SageMaker AI components along the ML lifecycle
Amazon SageMaker AI is a set of managed components, one or more per stage of the machine learning lifecycle: prepare data, train and tune, track and register, deploy, monitor. The decision rule: read the scenario’s lifecycle stage first, then pick the component built for that stage. Feature Store stores features, Pipelines automates steps, Model Registry versions and approves models, and endpoints or batch transform serve predictions. Since 2026, several well-known components are also closed to new customers, which matters for questions written before that.
The lifecycle, component by component
Descriptions below follow the SageMaker AI documentation. The status column was checked on October 9, 2026 against the AWS feature pages; “Available” means no closure notice was found for that feature, not a guarantee of future support.
| Stage | Component | What it does | Status |
|---|---|---|---|
| Label data | Ground Truth | Builds labeled training datasets using human workers plus ML | Closed to new customers from July 30, 2026 |
| Review predictions | Augmented AI (A2I) | Human review loops for ML predictions | Closed to new customers from July 30, 2026 |
| Prepare data | Data Wrangler | Import, analyze, prepare and featurize data in Studio with little or no code | Available |
| Prepare data | Processing jobs | Run preprocessing, feature engineering and evaluation as managed jobs | Available |
| Features | Feature Store | Central store of features; Online store for low-latency inference, Offline store for training and batch inference | Available |
| Low-code | Canvas, Autopilot | Canvas builds models without code; Autopilot builds classification and regression models for users without ML knowledge | Available |
| Train and tune | Training jobs, built-in algorithms, script mode, automatic model tuning | Train on managed instances; tuning searches hyperparameters | Available |
| Start from a model | JumpStart | Pretrained models and solution templates you can deploy or fine-tune | Available; some models delisted on March 13, 2026, existing endpoints keep working |
| Track | Experiments, managed MLflow | Experiment tracking and reproducibility | Available |
| Debug training | Debugger | Inspect training tensors and detect training problems | Closed to new customers |
| Explain and test bias | Clarify | Bias detection and SHAP-based explanations | Closed to new customers |
| Version | Model Registry | Versions, lineage, approval workflow, cross-account deployment | Available |
| Document | Model Cards | One place to document a model for governance and reporting | Available |
| Automate | Pipelines, Projects | Workflows and CI/CD for ML | Available |
| Monitor | Model Monitor | Data quality, model quality, bias drift and feature attribution drift | Closed to new customers |
| Role design | Role Manager | Persona-based least-privilege roles | Closed to new customers |
AWS’s July 30, 2026 notice names Mechanical Turk, Ground Truth, Augmented AI, Studio Lab, Model Monitor, Clarify, Debugger, Role Manager, Geospatial and Profiler. “Closed to new customers” means existing customers keep using the feature and AWS adds no features; it does not mean the concept disappeared. For drift monitoring, AWS now documents open-source monitoring solutions on SageMaker AI MLflow with CloudWatch as the replacement path. Studio Classic is maintained for existing workloads only; the current Studio replaced it.
Check which names the exam guides use. The AIF-C01 guide (version 1.1) names SageMaker Model Cards and JumpStart, and its revisions page lists Clarify. The MLA-C02 guide names Feature Store, Data Wrangler, automatic model tuning, MLflow on SageMaker AI and Model Registry, and asks for drift detection pipelines without naming Model Monitor.
Choosing an inference option
| Option | Use when | Limits worth knowing |
|---|---|---|
| Real-time endpoint | Interactive, low-latency, steady traffic | Billed for instances while running; supports autoscaling and multi-model endpoints |
| Serverless inference | Idle periods between spikes, cold starts acceptable | Memory 1024 to 6144 MB; endpoint concurrency up to 200; no GPU, no multi-model endpoints, no VPC configuration, no data capture |
| Asynchronous inference | Large payloads, long processing, latency tolerant | Payloads up to 1 GB, processing up to one hour, can scale to zero; request and result go through Amazon S3 |
| Batch transform | Offline scoring of a large dataset, no persistent endpoint | Pay for instances during the job; MaxPayloadInMB must not exceed 100 MB |
Multi-model and multi-container endpoints share instances across models, the cost lever when many endpoints sit underused. Shadow tests compare a new variant against production with live traffic.
Worked example: a weekly churn model
A team has customer tables in S3 and wants weekly churn scores.
- Run a Processing job or Data Wrangler flow to clean and join the tables, and write the engineered features to Feature Store (Offline store, because scoring is batch).
- Train with a built-in algorithm or a script-mode job, and run automatic model tuning to search hyperparameters.
- Log runs to MLflow; register the winning model in Model Registry with a pending approval status.
- A Pipeline chains steps 1 to 3 and the approval, so retraining is repeatable. This is the building block of MLOps basics.
- Deploy for batch transform, not an endpoint: scores are needed once a week, so there is nothing to keep running between jobs.
- Watch for drift. Model Monitor is closed to new customers, so a new design uses the AWS-documented alternatives or a custom drift check. The metrics to watch are explained in ML basics: overfitting and metrics.
At no step did the team need Bedrock. If the next requirement were a document-summarising assistant, the answer would flip; Bedrock vs SageMaker AI explains that boundary, and AWS AI services lists the pre-trained alternatives to training anything.
Which exams test this
| Exam | Where it appears | Where on this site |
|---|---|---|
| AIF-C01 | Domain 1 (20%), task 1.3: AWS services for each pipeline stage, MLOps ideas, inference types (batch, real-time, asynchronous, serverless). Domain 2 (24%), 2.3: SageMaker AI and JumpStart for GenAI apps. Domains 4 and 5: Model Cards for transparency and data lineage | AI and ML fundamentals explained |
| MLA-C02 | Domain 1 (28%): Feature Store ingestion, Data Wrangler transforms. Domain 2 (24%): built-in algorithms, script mode, automatic model tuning, MLflow, shadow variants. Domain 3 (24%): inference strategies, endpoints in a VPC, SDK deployment, Model Registry. Domain 4 (24%): inference instance families, cost | Data preparation: Feature Store and Data Wrangler, Model development, Deployment and orchestration |
How the questions are built
Questions give a symptom or constraint and ask for the component. Constraint words: “approval workflow” and “versions” mean Model Registry; “reuse features between training and real-time inference” means Feature Store with an Online store; “labeled by humans” means Ground Truth; “idle most of the day” means serverless or async; “once a night, no latency need” means batch transform; “payload of hundreds of megabytes, minutes of processing” means async. The common traps: choosing a real-time endpoint for an offline job (the exam’s standard cost mistake); picking serverless for a GPU model, which serverless does not support; and picking Model Monitor with a multi-model endpoint, which Model Monitor does not support. Model Monitor also computes statistics on tabular data only.
Name confusion is the other trap: SageMaker became SageMaker AI on December 3, 2024, and older material may be stale. Secure designs add IAM roles, VPC placement and encryption; AWS IAM basics covers the execution-role side.
Practice questions
Question 1. A model must be scored against 20 million records every night. Nobody needs the results before morning, and the team does not want to pay for infrastructure during the day. Which SageMaker AI option fits best?
- A. A real-time endpoint with autoscaling
- B. Batch transform
- C. Serverless inference
- D. A multi-model endpoint
Show answer
Answer: B
Batch transform runs inference over a dataset without a persistent endpoint, and you pay for instances only during the job. A real-time endpoint is billed while running, including idle hours. Serverless inference is meant for spiky request-response traffic with small payloads, not 20 million records in one run. Asynchronous inference is built for queued individual requests with large payloads, not for scoring a whole dataset offline.
Question 2. Data scientists keep retraining a fraud model, and the compliance team requires versioned models with an explicit approval step before anything is deployed to production, including to another AWS account. Which component provides this?
- A. SageMaker Model Registry
- B. SageMaker Feature Store
- C. SageMaker Data Wrangler
- D. SageMaker Processing jobs
Show answer
Answer: A
Model Registry provides model versioning, lineage tracking, an approval workflow and cross-account deployment support. Feature Store keeps features and does not manage model versions. Data Wrangler prepares data and has no approval workflow. Processing jobs run preprocessing or evaluation code and do not version or approve models.
Go deeper
- Amazon SageMaker AI features, the official component list.
- Deploy models for inference and the inference cost optimization guidance.
- Model Monitor availability change, with the replacement approach.
- Related: MLOps basics and LLM evaluation.