Amazon Bedrock and Amazon SageMaker AI both appear in almost every AI scenario, often as two options side by side. Both can host models, both can customise them, and both now offer some form of serverless use. So feature lists do not settle it. One question usually does: does the answer come from a model that already knows how to produce it, or does a model have to learn it from your own data?
Two services, two jobs
AWS’s decision guide describes Amazon Bedrock as “a fully managed, serverless platform to build, run, and operate AI applications and agents at production scale”. You call pre-trained foundation models through an API, using the Bedrock SDK, the REST API or OpenAI-compatible endpoints, and you mainly pay per input and output token, with some features priced separately. Customisation is there when you need it: fine-tuning, model distillation, reinforcement fine-tuning and custom model import, with minimal infrastructure to manage. The guide pitches it at developers, and says a basic level of ML expertise is enough.
Amazon SageMaker AI is, in the same guide, “a fully managed service designed to help you build, train, and deploy AI, predictive ML, and classical ML models at scale”. It covers notebooks, pipelines, training jobs, endpoints and HyperPod clusters. Serverless model customisation is priced per token; training jobs, inference and HyperPod are priced by the compute you use. It is aimed at ML practitioners, engineers and data scientists who want control, including over the cost, latency and throughput of serving a model.
The question that decides
Read the requirement for where the knowledge lives.
| The requirement says | It points to |
|---|---|
| Generate, draft, summarise or converse | A foundation model on Bedrock |
| No training data, limited ML expertise, ship soon | Bedrock |
| Predict an outcome from years of labelled records | A model trained on SageMaker AI |
| Explain which features drove each prediction | SageMaker AI, with feature attribution |
| Choose the instances and tune cost against latency | SageMaker AI |
The decision guide’s own examples follow the same line. A content moderation system or a customer support chatbot built on pre-trained models is a Bedrock use case. A healthcare model that predicts patient outcomes from specific biomarkers, or a fraud system “tailored to their unique data and risk factors”, is a SageMaker AI use case. The second pair are predictions that only exist once a model has learned from that organisation’s records.
Those predictions are classical ML. You give the training data a target to predict, which can be a number (regression) or a category such as yes or no (classification). The AWS overview describes exactly that for SageMaker AI Autopilot: provide a tabular dataset, select the target column, and it builds, trains and tunes candidate models.
Why a foundation model is the wrong tool for a score
Suppose a risk team wants a cancellation score for every booking, learned from three years of bookings whose outcomes are known, and auditors want the reasons. A foundation model can be prompted to return a number and a sentence. But it was never trained on those rows, and its sentence is generated text, not a measurement of which inputs moved the number.
What auditors ask for has a precise name: feature attribution. SageMaker’s explainability documentation puts it as a Shapley value “that assigns each feature an importance value for a particular prediction”, and lists “auditing and meeting regulatory requirements” among the uses of explanations. Explaining a prediction needs a model trained on your data, and SageMaker AI is where AWS builds that and its SHAP-based attribution.
The Clarify change
For years the answer to “explain each prediction” on AWS was SageMaker Clarify, which uses a model-agnostic feature attribution approach built on SHAP. Note the current status: AWS says Clarify “is no longer open to new customers”, although existing customers can carry on. For new work, AWS points to the SHAP library directly, “the same engine Clarify uses”, run in your own SageMaker AI pipelines with results logged to SageMaker AI MLflow. It also says plainly that Amazon Bedrock Evaluations “are not a replacement for predictive (tabular/classical ML) bias detection or explainability”. The split holds even here: language and generation on the Bedrock side, predictions from your rows on the SageMaker AI side.
Not always either-or
Two things stop this from being a strict fork. First, before either, check whether a pre-trained AI service already does the job. The machine learning decision guide describes these specialised services as pre-trained models for specific tasks, while SageMaker AI “provides the most flexibility and control” of the managed ML services. Second, the services work together. The Bedrock decision guide describes a common path that starts with Bedrock and moves to SageMaker AI as customisation grows, and custom models trained on SageMaker AI can be imported into Bedrock for serverless inference.
What the exam guides ask
The MLA-C02 guide asks you to “compare and select appropriate ML models, generative AI (GenAI) models, algorithms, and solution templates to meet business needs (for example, interpretability, domain-specific performance, latency)” (Skill 2.1.3), to “evaluate tradeoffs between custom solutions, managed services, pre-trained models, and FMs to meet business needs” (Skill 2.1.4), and to “apply AWS AI services to solve specific business problems” (Skill 2.1.8). The AIF-C01 guide asks you to “explain basic AI concepts and terminologies” (Task 1.1), “identify practical use cases for AI” (Task 1.2) and “describe AWS infrastructure and technologies for building GenAI applications” (Task 2.3). The AIP-C01 guide asks you to “create data processing workflows to handle complex data types including text, image, audio, and tabular data” (Skill 1.3.2) and “enhance input data quality to improve FM response quality and consistency” (Skill 1.3.4).
Scenario questions here turn on one word in the requirement. “Interpretability” or “explain each prediction” rules out a foundation model’s prose. “This week” with no ML team rules out training a language model yourself. The distractors swap the two: a foundation model for a score learned from labelled rows, a SageMaker AI training job for copy a hosted model can write from a prompt, or an employee assistant where an application needs an API.
Play it
The free stage below puts both answers on one board. Larkspur Travel’s risk team wants a cancellation score for every booking, learned from three years of records with known outcomes, and the auditors insist on seeing which features drove each score. Marketing wants campaign copy generated from a brief, called by its own application, shipping this week. Three more rows wait beside them. Try the foundation model on the score and the training job on the copy, and the run shows where each one stops.