Choose ML and AI modeling approaches

For example, suppose an insurer wants the claim number, date, and total from scanned invoices: one engineer proposes training a document model, and another proposes calling the AnalyzeExpense operation of Amazon Textract, which extracts relevant data from almost any invoice or receipt^[1]. Both may deliver the fields, but only the first needs labeled examples and a training job. Two questions settle choices like this one: what must the model output, and what is the lowest build effort that meets the quality, latency, and cost requirements?

Choosing among traditional machine learning (ML), generative AI, and AWS AI services is Task 2.1, 'Choose appropriate modeling approaches for ML and AI solutions'^[2], in the AWS MLA-C02 exam guide's ML Model and Foundation Model (FM) Development domain (24%). The same domain lists 'Task 2.2: Train, fine-tune, and customize models for ML and AI solutions'^[2] as a separate task; see Train and customize ML and AI models. Amazon Bedrock defines model customization as providing training data to a model^[3], so customization here means changing weights through training, not changing what a request carries (prompts, inference parameters, retrieved passages); retrieval is a separate way to supply knowledge.

Question 1: the required output

The output requirement helps eliminate unsuitable candidates. Outputs such as a discrete category, a continuous number, a group of similar records, a future value, a bounding box, a pixel mask, a vector, or a generated paragraph each point to a different family of models; the sections below map them to AWS options.

Question 2: the lowest build-effort level

The options fall into four build-effort levels, a grouping that is not AWS terminology but follows AWS guidance: Amazon SageMaker AI (formerly Amazon SageMaker) documentation orders its implementation options by increasing levels of effort^[4] (pre-trained models, then built-in algorithms, then your own code in a supported framework, then a custom container image), and the AWS decision guide describes a progressive journey^[5] that starts with Amazon Bedrock prompt engineering and Retrieval Augmented Generation (RAG), moves to customization when model behavior must change, and reaches training jobs when you need full infrastructure control.

1. Level 1, task-specific AWS AI service: a pre-trained API for one job, such as Amazon Textract for documents, Amazon Rekognition for images and video, Amazon Comprehend for text, or Amazon Transcribe for speech. Comprehend, for example, uses a pre-trained model, so there is no need for you to provide training data^[6]. Custom features that train on your examples, such as Amazon Comprehend Custom (custom classification and custom entity recognition), which builds customized models on your behalf^[6], still count as Level 1 (see AWS AI services).
2. Level 2, FM used as-is: a large pre-trained model called through Amazon Bedrock, given task instructions in the prompt and current knowledge through RAG, which retrieves relevant source passages and adds them to the prompt at request time. A pre-trained Amazon SageMaker JumpStart model deployed without further training also sits here: SageMaker AI describes pre-trained models as ready to deploy, or to fine-tune and deploy, using SageMaker JumpStart^[4].
3. Level 3, customized FM: the same kind of model with its weights (the parameters it learned in training) changed by supervised fine-tuning, reinforcement fine-tuning, distillation, or continued pre-training. Fine-tuning a JumpStart model or applying LoRA in SageMaker AI^[7] (Low-Rank Adaptation, which trains a small set of added weights while the base model weights stay frozen; see Customizing a foundation model) is also FM customization.
4. Level 4, model you train yourself: a model trained on your data in Amazon SageMaker AI, using no-code Amazon SageMaker Canvas, automated Amazon SageMaker Autopilot, a built-in algorithm, your own training script (script mode), or a custom container.

Move to the next level only when a stated requirement fails at the current one: the AI service, including its custom features, cannot produce your business-specific categories, the FM cannot hold a required format, a prediction depends on your own tabular history, or you need control over training and hosting. The figure below orders the levels by build effort, following AWS's increasing levels of effort^[4], with a failed requirement on each arrow.

The takeaway: name the output, start at the lowest level that can produce it, and let a failed requirement, not habit, move you to the next level.

The lowest build-effort level is a task-specific AWS AI service: a pre-trained API that returns a finished result for one kind of input. When its output matches the requirement and its quality is good enough, use the service. Its pre-trained capabilities need no training data from you, and its custom features build models on your behalf using your data; custom training outside the service earns its extra effort only when the service, including its custom features, cannot produce what is needed. Amazon SageMaker Canvas exposes several of these services as Ready-to-use models, powered by Amazon Rekognition, Amazon Textract, and Amazon Comprehend^[8]. They need no model building, which also means they are not the Canvas feature for training a predictor on your own data; that is a Canvas custom model, described in How much to build below.

Amazon Textract: documents

Textract splits document work by how much structure you need back:

Requirement	Textract capability
Lines and words only	Text detection (DetectDocumentText)
Form fields, table cells, signatures	Document analysis (AnalyzeDocument) with the forms, tables, or signatures feature
Specific facts asked as questions	Document analysis with the Queries feature
Invoice and receipt fields	Expense analysis (AnalyzeExpense)

Document analysis^[9] returns five categories of extraction: text, forms, tables, query responses, and signatures. Forms come back as key-value pairs (the key Name: linked to the value Jane Doe). Text detection does not supply that relationship: it is generic optical character recognition (OCR), which converts an image of text into a machine-readable text format^[10], and its lines and words are enough only when the application never needs those relationships. With Queries you pass a question such as What is the customer's SSN? and Textract returns the answer in its own response structure, so the application does not have to inspect every extracted word. Custom Queries adapt this pre-trained capability by training an adapter on your own annotated sample documents. Invoices and receipts are handled through a separate process, expense analysis, rather than generic document analysis, so assembling invoice fields from text detection output and custom parsing rebuilds something Textract already provides.

The processing mode follows the document. The synchronous operations work on single-page documents^[11] and return results in near real time; they include DetectDocumentText, AnalyzeDocument, and AnalyzeExpense. Multipage documents need the asynchronous operations, such as StartDocumentAnalysis for asynchronous document analysis.

Amazon Rekognition: images and video

Rekognition label detection finds common labels^[12], such as cars, tomatoes, and basketballs, without training a model. When the categories are specific to your business, such as your logo, your products on a shelf, or particular machine parts, use Amazon Rekognition Custom Labels: you supply a small set of training images, typically a few hundred or less, and it trains a model that classifies whole images or detects object locations with bounding boxes. Like Textract Custom Queries above and Comprehend custom classification and custom entity recognition below, Custom Labels trains on your examples yet stays at Level 1 of the build-effort levels, because the service selects the right machine learning algorithms and trains a model^[12] for you.

Content moderation is a separate capability. DetectModerationLabels^[13] detects inappropriate, unwanted, or offensive content in images, and StartContentModeration does the same asynchronously for video. Each result carries a label from a three-level category taxonomy plus a confidence score; labels detected below the MinConfidence threshold you set are not returned, and without a setting the threshold is 50 percent. Your application applies its own review policy to those labels and scores. Ordinary label detection does not answer the moderation question, and text sentiment analysis cannot inspect an image at all.

Amazon Comprehend: text

Amazon Comprehend^[6] returns insights from a pre-trained model, including entities, key phrases, personally identifiable information (PII), dominant language, sentiment, targeted sentiment, and syntax. Sentiment and targeted sentiment differ in scope, and custom classification and custom entity recognition differ in output:

• Sentiment returns the dominant sentiment of a whole document (positive, neutral, negative, or mixed). Targeted sentiment returns the sentiment associated with each specific entity mentioned. A review that praises one product and criticizes another needs targeted sentiment, because one document-level label collapses the two opinions into a single result.
• Custom classification organizes whole documents into your own categories. Custom entity recognition finds your specific terms and noun-based phrases inside the text. A document's category and the entities it mentions are different outputs, so choose the custom model type by the output the application needs.

Comprehend offers two processing styles: real-time analysis for small workloads, and asynchronous analysis jobs for large document sets. An interactive feature that needs an answer per request uses real-time analysis; a large corpus goes to an asynchronous job instead of being forced through interactive calls one document at a time.

Amazon Transcribe: speech

Amazon Transcribe^[14] converts speech to text from two kinds of input. Media files already stored in an Amazon S3 bucket use batch transcription; a live media stream uses streaming transcription. The two follow different rules: supported media formats differ, and streaming is not supported for every language, so confirm the language before choosing streaming. A batch job over stored files cannot serve a live captioning requirement.

The takeaway: when an AWS AI service already returns the output you need, the decision becomes which operation or mode to call, not which model to train.

Choosing an FM (Level 2 of the build-effort levels) runs in two passes: the model card's hard constraints remove models that cannot do the job, and a task evaluation picks among the survivors. A model card is the per-model specification page in the Bedrock documentation; it lists one model's input and output modalities, context window, maximum output tokens, and supported features. It is not Amazon SageMaker Model Cards^[15], the SageMaker AI feature for documenting your own ML models for governance and reporting.

Pass 1: hard constraints from the model card

Modalities: check input and output separately

Input and output modalities (the kinds of data a model takes in and produces, such as text, image, or video) are listed separately, and image input is not image output. The Amazon Nova Lite model card^[16] lists text, image, and video as inputs but text as the only output: Nova Lite can describe a photo, not create one. The Stable Image Ultra model card^[17] lists text input and image output, which is what an image-generation requirement needs.

Embedding models versus generative models

The output check also separates embedding models: an embedding model returns numbers, not prose. Amazon Titan Text Embeddings V2^[18] takes text and outputs a vector (1,024 dimensions by default) that represents its meaning, and the similarity search itself is performed by your vector database, not by the embedding model. An application that needs semantic search therefore stores embedding vectors in a vector index, and a separate generative model writes the answer from the retrieved text. Storing generated prose in place of those vectors leaves the index nothing it can compare by meaning.

Context window and maximum output: two separate limits

A request must fit two separate limits on the model card: check the context window^[19] against the input context the request needs, and check the maximum output tokens, which separately cap how many tokens the model can generate, against the required response length. The Nova Lite card lists a 300K-token context window but 10K maximum output tokens, so it can read a very long document and still cannot return a response longer than its output limit. A requirement such as turning a very long contract into a long, detailed brief must fit both numbers.

Features: one model and version, not a family

The Nova Lite card lists response streaming and the Converse API as supported, while the Stable Image Ultra card lists the Converse API as not supported and the Invoke API as supported. Customization support varies the same way: the Amazon Bedrock FAQ^[20] describes continued pre-training for Amazon Titan models, not for every model in Bedrock. Before committing, check the exact model ID for every feature the design depends on (streaming, the intended API, a customization method) rather than assuming that a sibling model's support carries over.

Pass 2: measured quality, latency, and cost

A model card's capability labels, such as its modality support, prove compatibility; they do not prove that a model is accurate on your domain. Amazon Bedrock evaluations^[21] run candidate models against a custom prompt dataset tailored to your use case (or a built-in dataset) and score the responses with computed metrics, with a second model acting as judge, or with human workers. Run the shortlist on prompts representative of the real task and compare the scores; supporting text generation only makes a model eligible.

Then weigh quality, latency, and cost together. Bedrock offers models at different price-performance points; the Nova Lite card, for example, describes it as Amazon's low-cost multimodal model. If a smaller, faster model passes the same evaluation, it meets the requirement at lower cost and latency; a more capable model is justified when the task needs capability the smaller one measurably lacks. The AWS MLA-C02 exam guide lists 'Evaluate cost implications of using FMs for inference in production' under Task 4.2^[22]; see Optimize ML and AI costs and performance.

Where the model runs: Amazon Bedrock or Amazon SageMaker AI

Where the model runs is a separate decision, made after both passes. Bedrock is a fully managed, serverless service: you call FMs through an API and do not manage any infrastructure^[20]. Amazon SageMaker AI is for building, training, and deploying models with more control; the AWS decision guide^[5] recommends it when you need access to the container or orchestration layer to manage cost, latency, and throughput tradeoffs directly. For fine-tuning, the Bedrock FAQ recommends Bedrock for a managed, API-driven approach with fewer hyperparameters (settings fixed before training), and SageMaker AI for advanced techniques, for both full fine-tuning (sometimes called full-rank fine-tuning) and parameter-efficient fine-tuning (training a small set of added weights rather than all model weights^[7]; see Full fine-tuning versus LoRA below), and for customizing the training recipe. Building your own serving stack for a model Bedrock already offers adds hosting work the requirement did not ask for.

The takeaway: filter by the model card, decide by your own evaluation, and pay for more capability only when a measured requirement needs it.

One rule settles most customization questions: RAG supplies knowledge, customization changes behavior. When answers depend on private or changing information, a knowledge base retrieves it at request time, which removes the need to continually train your model to use your private data^[23]; fine-tuning a model every time a product catalog changes turns each content update into a training job. Customization (Level 3) is for changing how the model responds, or how much it costs to run, when prompting and retrieval are not enough.

Four methods, chosen by the data you hold

Amazon Bedrock documents supervised fine-tuning, reinforcement fine-tuning, and distillation^[3] on its customization page, and continued pre-training in the Bedrock FAQ^[20]. Each needs a different kind of training data, so the data you hold usually picks the method; the comparison table Knowledge versus behavior after the last section lines the four up against RAG, and the paragraphs below give each one's mechanism.

Supervised fine-tuning trains on labeled examples (input-output pairs) so the model learns which outputs to generate for which inputs, with its parameters adjusted toward them. It fits a well-defined style, format, or task behavior that prompting alone cannot hold. With only unlabeled prompts and no target responses, it has nothing to learn from.

Reinforcement fine-tuning replaces labeled pairs with reward functions that evaluate response quality; the model learns iteratively from the feedback scores, and you can write the reward functions in AWS Lambda. Choose it when you can grade a response but cannot write the one correct answer in advance.

Distillation transfers knowledge from a larger teacher model to a smaller, faster, more cost-efficient student model: Bedrock generates the teacher's responses to your use-case prompts and uses them to fine-tune the student. The result is a new, separately trained student, so evaluate its task quality rather than assuming it inherits everything the teacher can do. Choosing between existing models request by request (intelligent prompt routing, described on the next page) never produces such a student.

Continued pre-training continues training an Amazon Titan base model on large amounts of unlabeled data, adapting it from a general corpus to a domain such as medicine, law, or finance while preserving most of its base capabilities. The FAQ notes that you can then fine-tune the adapted model for downstream tasks with significantly fewer labeled records. It adapts the model to a domain corpus; distillation instead learns from a teacher's responses rather than directly from raw documents.

Full fine-tuning versus LoRA

Within a fine-tuning workflow you also choose how many weights change. Full fine-tuning updates all of the model's weights. LoRA (Low-Rank Adaptation)^[7], a parameter-efficient option in SageMaker AI, trains a small set of low-rank matrices (adapters) while the base model weights stay frozen. Here adapter means LoRA's low-rank matrices for an FM you fine-tune, not the Textract Custom Queries adapter from AWS AI services. SageMaker AI documents LoRA as reaching near full fine-tuning quality at significantly lower cost, with faster training and smaller output artifacts; the adapter still needs the base model at inference unless you merge the two. When the compute budget covers only adapter training, full fine-tuning is the wrong commitment.

Training cost grows with every epoch

Bedrock charges model training by the tokens processed: the tokens in the training corpus multiplied by the number of epochs^[3], plus monthly storage for each custom model. An epoch is one full pass over the training data, so doubling the epochs doubles the training tokens even when the dataset is unchanged. Choose the epoch count from validation results and the budget, rather than treating extra passes as free quality.

The takeaway: route knowledge to RAG, let the training data you actually hold choose among the four customization methods, and budget for every epoch.

For example, suppose an assistant must answer from manuals in Amazon S3, from tables in an Amazon Redshift data warehouse, and from contracts that reference each other, and one team wants the retrieved chunks while another wants a finished answer: Amazon Bedrock Knowledge Bases^[20] supplies a managed retrieval pattern for each case. Once RAG is the answer, the patterns differ in where the data lives and in who assembles the answer.

The managed pipeline for documents

For unstructured documents, a knowledge base automates the pipeline you would otherwise build. The common practice it implements^[23] is to convert the data to text, split it into manageable pieces (chunks), convert each chunk to an embedding, and write the embeddings to a vector index while keeping a mapping from every chunk back to its original document. At runtime an embedding model converts the user's query to a vector, the vector index returns the chunks most similar to it, and the prompt is augmented with those chunks before it goes to the model. Knowledge bases can ingest content from Amazon S3^[20], the web, and other sources, so an existing document repository in S3 needs no custom document-to-vector pipeline. Extraction services such as Textract are a different layer: they turn a page into text and fields but provide no vector retrieval.

Retrieve or RetrieveAndGenerate

Knowledge Bases exposes the runtime path at two depths. Retrieve^[24] returns the most relevant source chunks as an array and stops there, which suits an application that composes the answer with its own prompt and model logic. RetrieveAndGenerate joins Retrieve with model invocation and returns a natural-language answer that includes citations to the source chunks. Choose by who composes the answer: calling RetrieveAndGenerate in a retrieval-only component generates an answer the application then has no use for. The figure below traces both depths over the same pipeline.

Structured data stores

When reference data sits in a supported structured store and the task needs SQL queries, consider querying it directly rather than exporting every row to text for embedding. A knowledge base can connect to structured data sources such as an Amazon Redshift data warehouse or the AWS Glue Data Catalog^[20] and convert natural-language questions into SQL queries against the existing schema. The GenerateQuery operation performs only that conversion, returning a query in a form suitable for the structured store, for applications that want to inspect or run the query themselves; RetrieveAndGenerate uses it automatically when the knowledge base is connected to a structured store, as described on the retrieval operations page^[24].

GraphRAG for answers that span documents

Some answers depend on relationships: a contract references an amendment, which names a supplier described in a third document. Plain vector search returns passages that are individually similar to the question and can miss the connecting ones. GraphRAG with Amazon Neptune Analytics^[25] runs an initial vector search, then retrieves the graph nodes or chunk identifiers linked to the retrieved chunks and traverses the graph to expand the context. It fits questions whose facts must be connected across multiple documents, and it supports only Amazon S3 as the data source.

The takeaway: consider a vector knowledge base for documents in S3, a structured knowledge base for tables, or GraphRAG for cross-document relationships; then choose Retrieve or RetrieveAndGenerate by who writes the answer.

When no AI service or FM produces the required prediction, for example churn predicted from your own customer history, you train a model on your data (Level 4). The first decision is the problem type, and it comes from the target, the column you want to predict, not from the input columns.

Labeled data: supervised learning

If each training record includes a target value, the problem is supervised^[4]. A categorical (mathematically discrete) target makes it classification, binary or multiclass; a mathematically continuous target makes it regression. Numbers can hide categories: a column that stores 1, 2, and 3 for bronze, silver, and gold tiers is still a categorical target, so the task is classification even though every value is numeric. SageMaker AI built-in algorithms such as Linear Learner and XGBoost^[26] handle both classification and regression, so you configure the training objective for the target's type.

Forecasting is supervised too, but its target is the future of a sequence. DeepAR^[26] is a supervised algorithm for forecasting scalar (one-dimensional) time series, the built-in choice when you must predict future behavior from historical data, such as sales of a product. Assigning a category to today's record and predicting next month's values are different outputs, so a forecasting requirement calls for a forecasting algorithm.

Unlabeled data: unsupervised learning

In this comparison, unsupervised learning discovers structure without supplied targets. Cluster analysis finds groupings whose members are as similar as possible to one another, and K-Means^[26] is the built-in choice, for example to find high-, medium-, and low-spending customers from transaction histories when no segment labels exist. A supervised classifier cannot be trained on that data, because nothing tells it what the categories are, and clustering in turn groups records rather than forecasting a future sequence.

Anomaly detection finds the records that differ from the rest. Random Cut Forest (RCF)^[27] is an unsupervised algorithm that associates an anomaly score with each data point: low scores mean normal and high scores indicate an anomaly, with scores beyond three standard deviations from the mean score commonly treated as anomalous. The score measures unusualness, not a business outcome. A high-scoring transaction is a candidate for investigation, not confirmed fraud; a supervised fraud classifier learns from labeled outcomes.

SageMaker AI lists a built-in algorithm for each of these problem types^[26], and the figure below arranges them as a decision. The takeaway: check for labels first, then let the target's type (category, number, future value) or the unsupervised goal (groups, unusual records) pick the algorithm.

When you train on your own data in SageMaker AI (Level 4), text and image problems follow the same output-first rule as tabular ones, with more possible shapes: a discovered theme, a known category, a generated sequence, a set of object locations, or a class for every pixel. Each shape has its own SageMaker AI built-in algorithm. First check the options in AWS AI services: Rekognition Custom Labels^[12] classifies whole images or detects objects with bounding boxes, and Comprehend custom classification^[6] sorts documents into your own categories.

Text: discover topics, assign categories, or generate a sequence

• Topic modeling discovers themes. The built-in Latent Dirichlet Allocation (LDA) and Neural Topic Model (NTM)^[26] algorithms are unsupervised: they organize documents into topics that are not known in advance. Discovered topics need not match the categories your business uses, so topic modeling is the wrong choice when the requirement is a defined label set.
• Text classification assigns predefined categories learned from labeled examples, for example sorting library books into academic disciplines; BlazingText and Text Classification - TensorFlow are the built-in options.
• Sequence-to-sequence generates a new sequence. The SageMaker AI Sequence-to-Sequence algorithm^[28] is supervised: the input is a sequence of tokens and the output is another sequence of tokens, as in machine translation, text summarization, and speech-to-text. A text classifier assigns one or more categories from a fixed set, so it cannot express an arbitrary translated sentence.

BlazingText^[29] has two modes with different outputs, so the mode matters as much as the algorithm. Its text classification mode is supervised and assigns documents to categories. Its Word2vec mode is unsupervised and maps words to vectors (word embeddings) that place semantically similar words close together; those vectors are representations for other models to use, not category predictions. Pick the mode by the output the application needs.

Images: image-level labels, boxes, or every pixel

The three built-in image approaches differ in how fine-grained the answer is. Image classification labels the image as a whole; object detection returns a bounding box and label for each object^[26] it finds; semantic segmentation tags every pixel of the image with a category, which captures object shapes that a rectangle cannot, as the figure below shows, coarsest to finest. Choose the coarsest output that satisfies the requirement: a whole-image label when that is all the application uses, boxes when it must locate objects, and segmentation when it needs pixel boundaries.

The takeaway: in text and vision, ask whether the output is a discovered theme, a known category, a generated sequence, a location, or a per-pixel class, and the algorithm follows.

When a model must be trained on your own data in SageMaker AI (Level 4), the next choice is how much of the work you do yourself. First check whether a pre-trained Amazon SageMaker JumpStart model already fits: JumpStart provides pre-trained models, pre-built solution templates, and examples^[26] for popular problem types, and pre-trained models are ready to deploy, or to fine-tune and deploy^[4], which is Level 2 or Level 3 in Choosing a modeling approach above. Within Level 4, AWS offers options from no code to fully custom code; pick the least effort that still gives the control the requirement needs. The options, in roughly increasing effort:

• Amazon SageMaker Canvas^[8] builds a custom model without code: you import your data, build a model, evaluate its performance, and generate predictions. Its custom model types are numeric prediction (regression), categorical prediction for 2 or 3+ categories (binary and multiclass classification), time series forecasting, single-label image prediction, and multi-category text prediction. Canvas Ready-to-use models, by contrast, are the pre-trained AWS AI services from earlier and do not train on your data.
• Amazon SageMaker Autopilot^[30] automates model development (automated machine learning, AutoML): it analyzes and preprocesses the data, explores a variety of algorithms, searches for optimal hyperparameters, trains and evaluates the candidates, and ranks them by performance on a validation set. As of November 30, 2023, AWS described Autopilot's user interface as migrating into SageMaker Canvas as part of the updated Studio experience, and its AutoML API remains available through the SDKs. Automatic model tuning searches hyperparameters for the algorithm configurations you supply, including multiple algorithms in one tuning job; it is not a substitute for Autopilot's end-to-end preprocessing and model-development workflow.
• A SageMaker AI built-in algorithm needs no training code: the only inputs are the data, hyperparameters, and compute resources^[4]. When a built-in algorithm fits the data and task, reimplementing it in a framework script adds development work without adding capability.
• Script mode runs your own training script in a supported framework, such as scikit-learn, TensorFlow, or PyTorch, for an algorithm no built-in covers. A custom container image is the highest-effort option, for packages outside the supported frameworks.

The SageMaker AI implementation guidance rates the effort of these code paths. The ratings compare the paths with each other, all within Level 4 of the build-effort levels, so Low means low within Level 4, not Level 1; AWS's Level of effort column is not a build-effort level number. The same algorithm implementation guidance^[4] also rates Spark ML, open-source XGBoost (the XGBoost framework run with your own training script^[31], which is separate from the built-in XGBoost algorithm in Traditional ML), MXNet, and Chainer, which the table below leaves out:

Implementation	Requires code	Level of effort
Built-in algorithm	No	Low
Scikit-learn	Yes	Medium
TensorFlow or PyTorch	Yes	Medium-high
Custom image	Yes	High

The takeaway: check for a fitting JumpStart model first; within Level 4, start from Canvas or Autopilot when they cover the task, use a built-in algorithm when you already know the algorithm, and write code only for logic none of them supplies.

The most accurate candidate is not always the right one. Interpretability and compute support also bear on the choice: whether people must understand how the model reaches a prediction, and which training resources the algorithm can actually use.

Interpretability

Some requirements, such as a credit decision that must be justified to a customer or regulator, call for decision logic a person can read directly. AWS guidance notes that simple models are considered more interpretable^[32], because the effect of each input on the output is easier to understand: in a linear regression model, the magnitudes of the coefficients give a global feature importance, and a feature's contribution to one prediction is its coefficient times the feature's value. When readable decision logic is a stated requirement, an inherently interpretable model can be the right choice even if a more complex candidate scores somewhat higher, provided the simple model still meets the required predictive performance.

Feature attribution methods (SHAP is a common one) explain an already trained, complex model by assigning each input an importance score for a prediction. That helps, but it does not make the model's internal logic simple, and the same guidance warns that feature importance scores can be misleading and should be verified, ideally with subject matter experts.

Compute support

The algorithm you pick also fixes which hardware can shorten training. SageMaker AI built-in algorithms come with parallelization across multiple compute instances and GPU support for applicable algorithms^[4], but some algorithms are excluded by inherent limitations, so check the algorithm's own page before sizing the training job. The Sequence-to-Sequence and BlazingText algorithm pages, for example, document limits of this kind:

• The Sequence-to-Sequence algorithm^[28] supports only GPU instance types and trains on a single machine, although it can use an instance with multiple GPUs. Adding training instances does not distribute it.
• BlazingText^[29] text classification runs on a single CPU instance or on a single GPU instance using one GPU; only its batch skip-gram Word2vec mode spreads across multiple CPU instances.

Managed training runs what the algorithm supports; it does not add distribution the algorithm lacks. For an FM, the epoch count discussed in Customizing a foundation model above affects training tokens and cost.

The takeaway: a stated interpretability requirement can outrank a small accuracy gain, and an algorithm's documented compute support decides which training resources are supported.

The AWS MLA-C02 exam guide asks you to evaluate tradeoffs between custom solutions, managed services, pre-trained models, and FMs to meet business needs^[2] (Skill 2.1.4) under Task 2.1, "Choose appropriate modeling approaches for ML and AI solutions," and the table below applies that skill: it pairs each requirement with a modeling approach and an alternative ruled out, and names in italics the section that explains it.

Requirement	Modeling approach	Alternative ruled out, and why
Extract totals and vendor names from receipts	Textract AnalyzeExpense	Text detection plus custom parsing: rebuilds the purpose-built expense analysis (AWS AI services)
Process 40-page PDF files	Textract asynchronous operations	Synchronous calls: they handle single-page documents (AWS AI services)
Opinions about each product in one review	Comprehend targeted sentiment	Document sentiment: one label collapses opinions about different entities (AWS AI services)
Detect our own logo in photos	Rekognition Custom Labels	Label detection: its pre-trained labels cover common objects, not your logo (AWS AI services)
Live captions for a meeting	Transcribe streaming	Batch transcription: it expects media files already stored in S3 (AWS AI services)
Generate product images from text	An FM whose model card lists image output	A multimodal model with image input only: it returns text (Selecting a foundation model)
Long, detailed briefs from very long documents	A model whose context window and output limit both fit	Choosing on context window alone: the output limit is separate (Selecting a foundation model)
Answers must reflect a catalog updated daily	RAG with a knowledge base	Repeated fine-tuning: every update becomes a training job (Customizing a foundation model)
Teacher-level quality at lower cost	Distillation	Prompt routing: it chooses between existing models and trains no student (Customizing a foundation model)
Responses can be scored, but no single correct answer	Reinforcement fine-tuning	Supervised fine-tuning: it needs a target response for each input (Customizing a foundation model)
App composes answers with its own prompt	Knowledge base Retrieve	RetrieveAndGenerate: it generates an answer the app does not use (RAG architecture patterns)
Segment customers; no segment labels exist	K-Means	A supervised classifier: there are no labels to train on (Traditional ML)
Flag unusual transactions	Random Cut Forest	Treating the score as confirmed fraud: it measures unusualness (Traditional ML)
Outline each defect's exact shape	Semantic segmentation	Object detection: a box does not classify each pixel (Text and image algorithms)
Train a churn model with no coding	Canvas custom model	Canvas Ready-to-use models: pre-trained, not trained on your data (How much to build)
Decision logic must be readable	A simple interpretable model that meets the accuracy bar	The most accurate complex model plus attributions: its logic stays complex (Criteria beyond accuracy)

The takeaway: find the phrase that fixes the output, the data, or the timing, and the right approach usually follows from one of the sections above.