When machine learning fits, and which AWS AI service does what

Most exam questions in this domain are a short story with a hidden verb. A company has some data and wants to read it, see it, hear it, predict from it, recommend with it or talk about it, with as little machine learning work as possible. The right answer is almost always the one AWS service built for that verb. This article does two things: it sets out how to decide whether machine learning belongs in a problem at all, and it walks the shelf of AWS AI services one by one so that every verb, input and output has a name attached. The previous article supplied the vocabulary; the next one is for when nothing on the shelf fits and you build your own.

The map

Read this first when short on time. Every branch is a section below.

Should this be machine learning at all?

Machine learning is the right tool when the pattern you need lives in data rather than in anyone's head, when there is enough of that data, and when a prediction that is usually right is worth more than a rule that is always exact; when any of those fails, a rule, a lookup or a simple heuristic is the better engineering.

The exam guide states this as a task in its own right: "determine when AI/ML solutions are not appropriate". The reasons fall into four groups.

The logic is already known

If a person can write the rules down and they fit on a page, write them down. Tax brackets, shipping rates, "lock the account after five failed logins", a validation that a postcode has the right shape: these are rule-based systems, and a rule wins on every axis that matters for them. It is exact, it is explainable in one sentence, it costs nothing to run, it needs no data and it never drifts. Machine learning replaces the rules only when the rules would never end: describing a cat in pixels, spotting fraud in ten thousand interacting signals, ranking a million products for one person.

There is no data, or no labels

A supervised model needs examples with answers; without them there is nothing to learn from. A new product with no sales history cannot be forecast from its own data; a fraud pattern that has never happened cannot be learned; a document type nobody has labelled cannot be classified into categories nobody has defined. Sometimes the fix is to buy or generate data (SageMaker Ground Truth for labelling, a pre-trained model that already learned the general shape), and sometimes the honest answer is to start with rules, collect data as the system runs, and revisit later.

The answer must be deterministic

Some decisions must give the same output for the same input every time, be auditable line by line, or be exactly right rather than usually right. Calculating interest, applying a legal threshold, enforcing a safety interlock: a model that is 99.5 percent accurate is a model that is wrong one time in two hundred, and in these settings that is a defect, not a score. Generative models add non-determinism on top (the same prompt can give different words), which is why the exam expects you to know they do not fit a task that needs exact repeatability.

The cost outweighs the benefit

Machine learning has a bill: data collection and cleaning, labelling, people who know how to train and evaluate, compute for training and for inference, and then monitoring and retraining forever, because the world drifts. The exam wants a cost-benefit analysis before the build: what is the value of being right more often, and does it exceed that bill? The practical discipline is a baseline: implement the simplest heuristic first (predict yesterday's value, recommend the bestsellers, flag any transaction over a threshold in a new country) and measure it. If a model cannot beat the baseline by enough to pay for itself, the heuristic ships. Often the heuristic ships anyway, as the fallback for when the model is unavailable.

flowchart TD
  S([A problem to solve]) --> R{Rules known?}
  R -- "yes, and few" --> RB["Write the rules<br/>exact, explainable, no data needed"]
  R -- "no, or too many" --> D{Data exists?}
  D -- No --> C["Collect data first<br/>start with a heuristic, label as you go"]
  D -- Yes --> X{Exactness required?}
  X -- Yes --> RB
  X -- No --> B{Beats baseline?}
  B -- "not by enough" --> H["Ship the heuristic<br/>it already gets most of the value"]
  B -- "yes, and pays for itself" --> ML["Machine learning<br/>managed service first, custom model if needed"]

Heuristic

A simple hand-made rule of thumb that gives a good-enough answer cheaply: "recommend the bestsellers", "forecast last week's average".

Baseline

The score of the simplest sensible approach, measured first so that a model has something to beat.

Deterministic

Giving exactly the same output for the same input every time. Rules are; most models are for a fixed version, and generative models are not unless configured to be.

Matching the technique to the problem

Once a problem has earned machine learning, the shape of the answer picks the technique: a number means regression, a category means classification, a number over time means forecasting, groups mean clustering, "unusual" means anomaly detection, "what would this person like" means recommendation and "in what order" means ranking.

The fundamentals article defined the first four; three more appear constantly in scenarios. Forecasting is regression where the axis is time and the past values of the same series are the main features: demand next week, traffic next hour, energy tomorrow. Recommendation predicts which items a particular user will like, usually by learning from the interactions of many users (people who watched this also watched that, called collaborative filtering) plus item and user attributes. Ranking orders a list for a purpose: search results by relevance, a feed by engagement, recommendations by likelihood to convert. Recommendation and ranking are usually built together.

Collaborative filtering

Recommending by similarity of behaviour: users who interacted with the same items are assumed to share tastes, so what one liked is suggested to the other.

Related time series

Extra series that move with the target and help predict it: weather, price, promotions alongside demand.

Where machine learning shows up: the applications the exam names

The exam's list of real-world applications is a list of the verbs a business wants performed on unstructured or behavioural data: see, read, hear, speak, decide, recommend, find and talk; each maps to a managed AWS service, and knowing the mapping is most of the domain.

Computer vision covers tagging photos, detecting objects and people, reading text out of images, verifying identity by face, moderating uploaded content and inspecting products on a line. Natural language processing covers classifying and routing text, extracting names, dates and amounts, judging sentiment, redacting personal data, translating and summarising. Speech recognition turns calls, meetings and voice commands into text; speech synthesis turns text into a voice. Recommendation systems pick products, videos and articles for a person. Fraud detection scores transactions, sign-ups and logins. Forecasting predicts demand, capacity and cash. Document processing chains OCR and NLP to turn paper into data. Chatbots and voice assistants hold a conversation to complete a task. Search finds the right document for a question rather than the right keyword.

Picking the layer: a managed API, Bedrock or SageMaker

AWS sells machine learning at three heights, and most service-choice questions are really asking which height: a ready-made AI service you call with your data and no model of your own, Amazon Bedrock for generative tasks on foundation models, or Amazon SageMaker for training and hosting a model you own.

The first article drew the stack; this is the decision rule. Start at the top. If a managed AI service (Rekognition, Textract, Comprehend, Transcribe, Polly, Translate, Lex, Kendra, Personalize, Forecast, Fraud Detector) does the task, use it: there is no model to train, no infrastructure, no ML expertise needed and the least operational overhead, and the service improves underneath you. If the task is generative (write, summarise, answer, chat, generate an image or code), the layer is Amazon Bedrock (or Amazon Q, which is Bedrock with an application around it). Drop to SageMaker only when the managed services cannot do the task, when the data is so specific that a general model is not accurate enough, or when the business requires full control over the model, the training data and the hosting.

Several managed services have a middle rung for the "almost fits" case: you supply examples, the service trains and hosts a custom model, and you still write no ML code. Rekognition Custom Labels learns your own object classes (your logo, your part numbers) from a few hundred labelled images. Comprehend custom classification and custom entity recognition learn your document categories and your domain terms. Transcribe custom vocabularies and custom language models teach the recogniser your product names. Translate custom terminology pins how your brand terms are translated. Lookout for Vision learns your product's defects from a small set of good and bad photos. Each is the answer when a scenario needs a custom model "without machine learning expertise".

flowchart TD
  S([A task with data]) --> G{Generative?}
  G -- Yes --> BR["Amazon Bedrock or Amazon Q<br/>foundation models by API"]
  G -- No --> M{Managed fits?}
  M -- Yes --> AI["Managed AI service<br/>Rekognition, Textract, Comprehend,<br/>Transcribe, Polly, Translate, Lex,<br/>Kendra, Personalize, Fraud Detector"]
  M -- "almost" --> CU["Customise the service<br/>Custom Labels, custom classifiers,<br/>custom vocabularies"]
  M -- No --> SM["Amazon SageMaker<br/>train and host your own model"]

Seeing: Amazon Rekognition, Amazon Textract and Lookout for Vision

Three services take pixels in: Rekognition understands what is in a photo or video, Textract reads the text and structure out of a document image, and Lookout for Vision spots defects in product images; the exam separates them by whether the picture is a scene, a document or a part on a production line.

Amazon Rekognition

Rekognition is pre-trained computer vision behind an API. Send an image (or point it at a video in S3, or a Kinesis Video Stream for live analysis) and ask for one of its analyses. Label detection returns objects, scenes and activities with confidence scores and, for many, bounding boxes ("Dog 98 percent, Beach 91 percent"). Face detection finds faces and returns attributes: apparent age range, emotions, glasses, eyes open. Face comparison says whether two faces are the same person; face search matches a face against a collection you have indexed, which is how identity verification and "find photos of this person" work, with Face Liveness to check a real person is in front of the camera. Celebrity recognition names public figures. Text in image reads signs, captions and labels (short text in a scene; long documents belong to Textract). Content moderation flags unsafe or unwanted content in images and video across a hierarchy of categories, the answer whenever a scenario mentions user-generated uploads. PPE detection checks for helmets, gloves and masks. Video analysis does all of this over time, with people tracking and segment detection (shot changes, black frames). Custom Labels lets you train your own classes with a few hundred labelled images and no ML code.

Amazon Textract

Textract is OCR that understands document structure. Plain text detection returns lines and words with their positions. Analyze Document adds forms (key-value pairs: "Name: Jane Smith" comes back as a key and a value even when the layout is irregular), tables (cells with row and column indexes), signatures, layout (titles, headers, paragraphs, lists) and queries, where you ask in plain words ("What is the invoice total?") and get the answer field back without writing rules for each template. Analyze Expense is tuned for invoices and receipts (vendor, total, line items); Analyze ID reads passports and driving licences into standard fields; Analyze Lending classifies and extracts mortgage packages. Synchronous calls handle single pages; asynchronous jobs handle multi-page PDFs in S3. Textract does OCR only; understanding the meaning of the text is Comprehend's job, which is why the two chain.

Amazon Lookout for Vision

Lookout for Vision is anomaly detection on images for industrial inspection: train it on a small set of normal and (optionally) defective product photos and it flags scratches, dents, missing components and misalignments on a production line, with the option to run the model at the edge. AWS has stopped taking new customers for it, but the exam still names it. Its distinguishing keywords are manufacturing, defects and quality inspection.

Bounding box

The rectangle around a detected object or face, returned as coordinates relative to the image size.

Collection

A Rekognition index of face vectors you have stored, searched to identify a person across images.

Key-value pair

A form field and its filled-in value, as Textract returns them from a document regardless of layout.

Reading: Amazon Comprehend, Comprehend Medical and Amazon Translate

Comprehend takes text in and returns what it is about, who and what it mentions, how it feels and what language it is in; Comprehend Medical does the same for clinical text with medical codes attached; Translate turns text from one language into another.

Amazon Comprehend

Comprehend is pre-trained natural language processing as an API, synchronous for short text and as asynchronous jobs for a corpus in S3. Its analyses: entities (people, places, organisations, dates, quantities, commercial items, with confidence scores); key phrases (the noun phrases that carry the meaning); sentiment (positive, negative, neutral, mixed, for the whole text) and targeted sentiment (the sentiment toward each entity, so "the food was great but the service was slow" gets two opinions); language detection across a hundred-odd languages; syntax (parts of speech); PII detection that finds names, addresses, card numbers and the like and can redact them; events (who did what to whom, when, in news-like text). Two features are trainable on your own data with no ML code: custom classification (route support tickets into your categories, tag documents by type) and custom entity recognition (recognise your product codes, policy numbers, internal names). Topic modelling is the unsupervised one: give it a pile of documents and it groups them by the words they share, returning topics you then name.

Amazon Comprehend Medical

Comprehend Medical is Comprehend trained on clinical language. It extracts medical entities (conditions, medications with dosage and frequency, tests, treatments, procedures, anatomy), detects protected health information (PHI) for redaction, and links what it finds to standard ontologies: ICD-10-CM codes for diagnoses, RxNorm for medications and SNOMED CT for clinical concepts. Any scenario with doctors' notes, discharge summaries or clinical trial records points here, and the same split exists for speech (Transcribe Medical).

Amazon Translate

Translate is neural machine translation between more than seventy languages, in real time for a sentence or as a batch job for a bucket of documents, with automatic source-language detection. Custom terminology is a glossary that forces your terms to translate a fixed way (brand names, product names, legal phrases); active custom translation goes further by letting you supply parallel example translations to shift the style; formality settings and profanity masking control tone. It translates text only; audio goes through Transcribe first, and a translated voice comes back through Polly.

Named entity

A real-world thing mentioned in text with a name or value: a person, a company, a place, a date, an amount.

PII and PHI

Personally identifiable information (names, addresses, card numbers) and protected health information (the medical version). Both detectable and redactable by Comprehend and Comprehend Medical.

Custom terminology

A Translate glossary that fixes how specific source terms are rendered in the target language.

Listening and speaking: Amazon Transcribe, Amazon Polly and Amazon Lex

Transcribe turns speech into text, Polly turns text into speech, and Lex turns a typed or spoken sentence into an intent with its parameters so that a bot can act on it; the three chain into a voice assistant, and Lex is built on the technology behind Alexa.

Amazon Transcribe

Transcribe is automatic speech recognition: audio in, a transcript out with a timestamp and confidence per word. It works on files in S3 (batch) and on live audio (streaming, for captions and live agent assist). Speaker diarisation (AWS calls it speaker identification or partitioning) labels who said what; channel identification separates the agent and the customer on a stereo call recording. Custom vocabularies add product names and jargon the recogniser would otherwise mangle; custom language models go further by training on your domain text; vocabulary filtering masks or removes words you list. It detects the spoken language automatically, can redact PII from the transcript, and adds toxicity detection for moderation of voice chat. Transcribe Medical handles clinical dictation and conversation with medical vocabulary; Transcribe Call Analytics adds contact-centre features (sentiment per turn, talk time, interruptions, issue detection, call summaries) on top of the transcript.

Amazon Polly

Polly is text to speech: text in, an audio stream or file out, in dozens of voices and languages. Voice engines range from standard through neural (NTTS, noticeably more natural) to long-form and generative voices for the most human-sounding output. SSML (Speech Synthesis Markup Language) controls how the text is spoken: pauses, emphasis, pronunciation, whispering, a newscaster speaking style. Lexicons fix the pronunciation of specific words or expand abbreviations ("W3C" spoken as "World Wide Web Consortium"). Speech marks return the timing of each word or sentence so that an app can highlight text as it is read or animate a face.

Amazon Lex

Lex builds conversational interfaces: chatbots and voice bots. You define intents (the things a user might want: BookHotel, CheckBalance), give each a set of sample utterances ("I want to book a room", "reserve a hotel for me") from which Lex learns to recognise paraphrases, and declare the slots each intent needs (city, check-in date, number of nights) with slot types, built-in or your own. Lex runs the dialogue: recognises the intent, prompts for missing slots, confirms, and then calls an AWS Lambda function for fulfilment (do the booking) and optionally for validation at each turn. It accepts text and speech directly (it contains its own speech recognition, the same technology as Alexa), and integrates with Amazon Connect for phone systems, with messaging platforms, and with Polly for the spoken reply. It is not a large language model: it recognises intents you defined and fills slots you declared, which is exactly what a transactional bot needs.

sequenceDiagram
  autonumber
  participant U as Caller
  participant T as Transcribe
  participant L as Lex
  participant P as Polly
  U->>T: audio, "book a room in Leeds"
  T->>L: text with confidence
  L->>L: intent BookHotel, slot city filled
  L->>P: "For which dates?"
  P->>U: spoken prompt
  U->>T: audio, "the 12th for two nights"
  T->>L: text
  L->>L: slots complete, Lambda fulfils
  L->>P: "Booked. Anything else?"
  P->>U: spoken confirmation

Speaker diarisation

Splitting a transcript by who is speaking, so each segment is labelled with a speaker number.

SSML

Speech Synthesis Markup Language: tags around text that tell a text-to-speech engine how to say it, with pauses, emphasis and pronunciations.

Intent, utterance, slot

In Lex, what the user wants to do, an example sentence expressing it, and a piece of information needed to do it.

Searching and recommending: Amazon Kendra and Amazon Personalize

Kendra finds the document or passage that answers a natural-language question across a company's scattered content, and Personalize predicts which items a particular user wants to see next; both are pre-trained services fed with your data, and both are what the exam means by "search" and "recommendation" without building a model.

Amazon Kendra

Kendra is intelligent enterprise search. You point connectors at where the documents live (Amazon S3, SharePoint, Salesforce, ServiceNow, Confluence, Google Drive, databases, websites and many more) and it builds an index. Users ask questions in plain words ("how many days of parental leave do I get?") and Kendra returns the specific passage that answers, ranked by understanding rather than by keyword matching, alongside document results and FAQ matches you have curated. It respects the source systems' access control, so people see only what they may see, and it learns from click and thumbs-up feedback (incremental learning). It also serves as a retriever for generative applications: Amazon Q Business and Bedrock knowledge bases can use a Kendra index as the store they pull passages from, which is the subject of the applications article. Amazon OpenSearch Service is the other search engine on the exam, a general-purpose search and vector database you operate yourself; Kendra is the managed, question-answering one.

Amazon Personalize

Personalize is the recommendation technology from Amazon.com packaged as a service. You provide three datasets: interactions (user X clicked, watched or bought item Y at time T, the essential one), items (metadata such as category, price, genre) and users (age band, membership tier). You pick a recipe, which is Personalize's word for a pre-built algorithm for a use case: user personalisation ("recommended for you"), similar items ("customers who viewed this also viewed"), personalised ranking (reorder a given list for this user), trending now, next best action. Personalize trains a private model on your data and serves it as a real-time campaign (recommendations in milliseconds, updated as new interactions stream in) or as batch recommendations for email. It needs no ML expertise, handles the cold-start problem for new items using their metadata, and supports business rules (filters such as "exclude already purchased", "promote in-stock items").

flowchart TD
  I["Interactions<br/>user, item, timestamp, event"] --> P["Amazon Personalize<br/>recipe: user personalisation,<br/>similar items, personalised ranking"]
  M["Items and users<br/>category, price, genre, tier"] --> P
  P --> C["Campaign<br/>real-time recommendations API"]
  P --> B["Batch job<br/>recommendations file in S3"]
  E["New click or purchase"] -->|"event tracker"| P

Connector

A Kendra component that crawls a content source (S3, SharePoint, a database) and keeps the index up to date, carrying the source's permissions along.

Recipe

A pre-built Personalize algorithm configuration for a specific recommendation use case.

Cold start

Recommending items or serving users that have no interaction history yet; Personalize uses item and user metadata to cover the gap.

Predicting: Amazon Forecast, Amazon Fraud Detector, the Lookout family and Monitron

Four services turn structured business or sensor data into predictions without a data scientist: Forecast predicts time series, Fraud Detector scores risky events, Lookout for Metrics and Lookout for Equipment find anomalies in business metrics and machine sensors, and Monitron does the same for factory equipment with its own sensors.

Amazon Forecast

Forecast is managed time-series forecasting, built on the same technology Amazon uses for its own demand planning. You upload the target time series (sales per item per day), optionally related time series (price, promotions, weather) and item metadata (category, colour), and it trains a predictor (its AutoPredictor picks and blends algorithms including DeepAR and statistical models), then returns forecasts with probabilistic quantiles: a P10, P50 and P90 so the planner can choose how much stock-out risk to carry. AWS stopped onboarding new customers in 2024, steering them to SageMaker Canvas's forecasting; the exam guide still lists Forecast and the questions are about what it does.

Amazon Fraud Detector

Fraud Detector scores events (a sign-up, a transaction, a login, a guest checkout) for fraud risk. You define an event type with its variables (email, IP address, amount, device), supply historical events with labels (fraud, legitimate), and it trains a model with one of its model types: Online Fraud Insights for general events, Transaction Fraud Insights for payments, Account Takeover Insights for logins, each enriched with fraud patterns Amazon has learned across its own businesses. The trained model produces a score; you then write rules on top ("if score is above 900 or the country is on the block list, then review") that map to outcomes (approve, review, block), which is the combination of learned score and hand-written rule from the first section, in one service, evaluated in real time through an API.

Lookout for Metrics, Lookout for Equipment and Monitron

Amazon Lookout for Metrics watches business and operational metrics (revenue per region, sign-ups per hour, error rates) from sources such as S3, Redshift, CloudWatch and RDS, learns their normal patterns including seasonality, and alerts on anomalies with a ranked list of the contributing dimensions ("orders fell, mostly in the mobile app, mostly in one country"). Amazon Lookout for Equipment takes the sensor streams from industrial machines (pressure, temperature, flow, vibration from your existing sensors) and learns the normal multi-sensor pattern to warn of abnormal behaviour before a failure, which is predictive maintenance. Amazon Monitron is the end-to-end version for teams without sensors: AWS-supplied wireless vibration and temperature sensors, a gateway, and a service plus mobile app that flag developing faults in motors, pumps and fans. All three are anomaly detection in the sense of the previous article, and AWS has closed all of them to new customers while the exam continues to name them.

flowchart TD
  E["Event<br/>sign-up: email, IP, device, amount"] --> M["Fraud Detector model<br/>trained on your labelled events<br/>plus Amazon fraud patterns"]
  M -->|"score 0 to 1000"| R["Your rules<br/>score above 900, or blocked country"]
  R -->|"outcome"| O["Approve, review or block<br/>returned to the application in real time"]

Quantile forecast

A forecast given as several percentiles (P10, P50, P90) instead of one number, so a planner can trade the cost of too much stock against the cost of too little.

Predictive maintenance

Servicing equipment when sensor data says a fault is developing, instead of on a fixed schedule or after a breakdown.

Outcome

In Fraud Detector, the action a rule returns when its condition matches: approve, review, block, or any label you choose.

Documents end to end: chaining the services and adding people

Because each managed service does one thing well, real solutions chain them: Textract reads the document, Comprehend understands it, Translate converts it, Polly speaks it, and Amazon Augmented AI routes the results the machines are not sure about to a person; the exam draws this pipeline often and asks which box does which step.

Picture an insurer receiving claim forms as photos and PDFs in many languages. Textract turns each page into text, key-value pairs and tables (the claim number, the policyholder, the itemised amounts). Comprehend takes the free-text description of the incident and extracts entities (dates, places, vehicle models), the sentiment and any PII to redact, and a custom classifier routes the claim to the right team. Translate renders the description into the adjuster's language. Polly reads the summary aloud for an accessibility service or a phone line. Glue such as AWS Lambda, Step Functions and S3 event notifications runs the steps in order; none of it needs a model to be trained.

flowchart TD
  S["Scanned claim form<br/>PDF or photo in S3"] --> T["Amazon Textract<br/>text, key-value pairs, tables, queries"]
  T --> C["Amazon Comprehend<br/>entities, sentiment, PII, custom class"]
  T -->|"low confidence"| A["Amazon A2I<br/>human review, corrected result"]
  A --> C
  C --> TR["Amazon Translate<br/>adjuster's language"]
  TR --> P["Amazon Polly<br/>spoken summary"]
  TR --> D["Claims system<br/>structured record"]

Amazon Augmented AI (A2I)

Amazon A2I adds human review to any prediction. You define a human review workflow (a flow definition): the conditions that trigger review (Textract confidence below a threshold on a key field, Rekognition moderation scores in an uncertain band, or any custom condition for a SageMaker model), a task template the reviewer sees, and a workforce: your own employees (a private workforce), a vendor from AWS Marketplace, or Amazon Mechanical Turk's public crowd. Reviewed results land in S3 and can be fed back as training data. It has built-in task types for Textract key-value pairs and Rekognition image moderation, and a custom type for everything else. It is the exam's answer to "some predictions must be checked by a person" and to "keep humans in the loop for sensitive decisions".

Human review workflow

An A2I definition of when a prediction goes to a person, what they see, and who the reviewers are.

Private workforce

Your own staff as A2I or Ground Truth reviewers, used when the data cannot leave the company.

Confidence score

The service's own estimate, usually 0 to 100, of how likely a returned result is correct. Thresholds on it drive human review.

Generative and developer services: Bedrock, Amazon Q, CodeGuru, DevOps Guru and DeepRacer

The generative layer is Amazon Bedrock and the assistants built on it, Amazon Q Business and Amazon Q Developer; beside them sit three older ML-powered developer services the exam still names, CodeGuru for code, DevOps Guru for operations and DeepRacer for learning reinforcement learning.

Amazon Bedrock is the managed service for foundation models: one API to call text, image and embedding models from Amazon (Titan, Nova), Anthropic, Meta, Mistral, Cohere, Stability AI and others, plus knowledge bases for retrieval-augmented generation, agents that call your APIs, guardrails for safety, model customisation and evaluation. It is the answer whenever a scenario says generate, summarise, converse, or "foundation model"; the Bedrock article is the full treatment. Amazon Q Business is a ready-made generative assistant for a company's own data: connect it to documents and applications (it shares Kendra's connectors) and employees ask questions, get answers with citations, and take actions, with the source permissions respected. Amazon Q Developer (which absorbed Amazon CodeWhisperer) suggests and explains code in the IDE, answers AWS questions in the console, helps with troubleshooting, and can carry out multi-step development tasks; Amazon Q also appears inside QuickSight (natural-language BI) and Connect (agent assistance). The generative AI stack article places all of these.

Amazon CodeGuru is machine learning applied to code: CodeGuru Reviewer finds defects and security issues in pull requests (now folded into Amazon Q Developer's code review, and closed to new customers as a standalone), CodeGuru Profiler finds the most expensive lines in a running application, and CodeGuru Security scans for vulnerabilities. Amazon DevOps Guru is anomaly detection for operations: it learns the normal behaviour of an application's CloudWatch metrics, logs and events, raises insights when something deviates (a latency climb, an error-rate spike, a database bottleneck) and recommends a fix, before the alarm thresholds anyone set would have fired. AWS DeepRacer is the 1/18th-scale car and the console for training its driving policy with reinforcement learning in a simulator, kept in the exam as the canonical RL example; AWS has wound down the racing league and the console, but the concept is what is tested.

Build your own: when the shelf has nothing that fits

Amazon SageMaker is the layer for training, tuning, hosting and monitoring a model of your own, and it is the right answer only when the managed services cannot do the task, cannot reach the accuracy the business needs on its specific data, or cannot give the control a regulator or an architecture demands.

The cases that genuinely need SageMaker are recognisable. The prediction target is specific to the business and no service predicts it (customer churn, loan default, machine yield, ad click-through). The data is proprietary and the features are the company's own. A managed service exists but its general model is not accurate enough on unusual data (rare medical images, a niche language, an industrial process). The model must be explainable in a specific way, must run on specific hardware or in a specific network, or must be versioned and audited under the company's own controls. Or the team wants to run a particular open-source model or a particular algorithm. In each case SageMaker supplies the pieces: notebooks in Studio, no-code model building in Canvas, pre-trained models from JumpStart, labelling with Ground Truth, training jobs with built-in or custom algorithms, tuning, endpoints of every kind, and monitoring. The next article is the tour.

The cheat sheet: problem, service, keyword

Every service in this article, one row each, with the input it takes, what it returns and the words in a scenario that point at it; this table is the thing to be able to reproduce from memory.

Recap