The Purpose-Built AI Services

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

The Purpose-Built AI Services
Orientation: the three-layer stack
AWS's AI portfolio has three layers, and knowing which layer a scenario belongs to resolves a large share of exam questions before you evaluate any specific service.
The bottom layer is SageMaker AI — you bring data, train a model, own the endpoint. Maximum control, maximum effort, and you need labeled data and ML expertise.
The middle layer is Bedrock — foundation models via API, no training, no infrastructure. Flexible across an enormous range of tasks because the model is general.
The top layer is the purpose-built AI services in this file — Comprehend, Kendra, Lex, Rekognition, Textract, Transcribe, and Augmented AI. Each does one thing. You call an API, get structured output, and never think about a model at all.
The instinct in 2026 is to reach for a foundation model for everything, and the exam deliberately punishes that. A foundation model can transcribe audio, read a form, or classify sentiment — usually worse, more expensively, less deterministically, and without the structured output downstream systems need. When a managed service does exactly the task, it is the answer, particularly under a least-overhead qualifier.
The inverse trap also exists. Purpose-built services return structured, predefined output: a label set, an entity type, a confidence score. When a scenario needs open-ended interpretation — describe what's happening in this image, identify emerging aesthetic trends, summarize this in the voice of our brand — no fixed label set can express the answer, and that's a foundation model problem. This is exactly the distinction that decided your fashion-trends question.
A useful shorthand: if the answer fits in a schema you could write down in advance, use a purpose-built service. If it doesn't, use a foundation model.

Amazon Textract
What it is
Textract extracts text, structure, and data from scanned documents and images. Beyond plain OCR, it recognizes document structure: forms (returning key-value pairs, so "Date of Birth" is linked to its value), tables (preserving rows and columns), queries (you ask "what is the policy number?" in natural language and it returns just that field), signatures, and specialized analysis for invoices, receipts, identity documents, and lending packages.
It offers synchronous APIs for single-page documents and asynchronous APIs for multi-page PDFs, returning JSON with bounding-box geometry and per-element confidence scores.
Why it exists and where it fits
Plain OCR returns a wall of text and loses the relationships that make a document meaningful — a form's value belongs to its label, a table cell belongs to its row and column. Textract preserves that structure, which is what makes downstream automation possible.
In generative architectures Textract is very often step one of the pipeline: scanned documents are unreadable to a text model, so Textract converts them into text a foundation model or knowledge base can then use. A common correct architecture is S3 upload → EventBridge or S3 notification → Lambda → Textract → Bedrock for summarization or classification → store. Recognizing that pattern is worth as much as knowing the service.
Constraints
Asynchronous jobs are required beyond a page limit, and results are retrieved by job ID rather than returned inline. Handwriting support exists but is less reliable than print. Confidence scores are per-element, which is what makes a human-review threshold implementable. Pricing is per page and rises with the analysis type — forms and tables cost more than raw text detection, which matters at volume.
When not to use it
For digital documents that already contain text — a native PDF or Word file needs a parser, not OCR. Textract is for scans and images.
For open-ended reasoning about a document. Textract tells you what the document says and how it's laid out. It doesn't tell you whether the contract is favorable or what the risks are. That's a foundation model reading Textract's output.
When the document type has a specialized alternative that fits better — for pure speech, images, or video, this is the wrong service entirely.

Amazon Transcribe
What it is
Transcribe converts speech to text. It supports batch transcription of audio files in S3 and streaming transcription over WebSocket or HTTP/2 for real-time use, across many languages with automatic language identification.
Its useful features are mostly about accuracy and safety in specific contexts: custom vocabularies and custom language models to handle domain jargon, product names, and acronyms that a general model mangles; speaker diarization to label who spoke when; channel identification for separating agent and customer on a two-channel call recording; automatic content redaction for PII in both the text and the audio itself; and Transcribe Medical and Call Analytics as domain variants, the latter adding sentiment, talk-time, and issue detection for contact centers.
Where it fits
Voice is unstructured input that nothing downstream can use until it's text. So Transcribe is the front door of nearly every voice-driven generative architecture: call recordings → Transcribe → Bedrock for summarization and action items → store and index. Contact center analytics is the canonical scenario, and it usually pairs with Amazon Connect.
The feature to remember for compliance scenarios is redaction, because it operates on the audio as well as the transcript. When a stem says call recordings containing payment card data must be retained but scrubbed, that's Transcribe redaction rather than a downstream text filter — the sensitive audio itself is the liability.
Constraints and boundaries
Accuracy degrades with poor audio quality, heavy accents, and crosstalk, and custom vocabulary is the lever for domain terms — a stem complaining that product names are transcribed wrongly is asking for that, not for a different service. Streaming and batch have different feature availability. There are file size and duration limits for batch jobs.
Don't confuse it with Lex. Transcribe converts speech to text and stops. Lex understands the text as intent and manages a conversation. "Transcribe the call for analysis" is Transcribe; "let the caller book an appointment by voice" is Lex.

Amazon Rekognition
What it is
Rekognition analyzes images and video. Its capabilities: label detection (objects, scenes, activities from a large predefined taxonomy), face detection and analysis, face comparison and search against a collection you build, celebrity recognition, text in image, content moderation against categories like explicit and violent content, and personal protective equipment detection. For video it adds person tracking, segment detection, and streaming video events.
Rekognition Custom Labels is a distinct mode: you supply labeled examples of categories the general model doesn't know — your specific manufacturing defects, your product SKUs — and it trains a custom model for them.
Where it fits, and the two traps
Rekognition is the answer for structured visual detection: is there a person in this frame, does this face match that one, is this image safe to publish, is the worker wearing a hard hat. Content moderation at scale is a very common scenario, and face search against a collection is the identity-verification one.
The first trap is Custom Labels under an overhead qualifier. Custom Labels is real and effective, but it requires labeled training data and a training step. Any stem saying "least operational overhead" or "without training a model" excludes it — and it's frequently offered precisely because it sounds sophisticated.
The second trap is the boundary with multimodal foundation models, which is worth being precise about because it decided your sample question. Rekognition answers "which of these known things are present?" It returns labels from a taxonomy — or from one you trained. A multimodal FM answers "what is going on here, in your own words?" — open-ended description, comparison, aesthetic judgment, reasoning about context.
So: moderating uploads for explicit content → Rekognition, deterministic and cheap. Identifying emerging style trends across fashion show footage → multimodal FM, because "trend" isn't a label you can enumerate in advance. If the required output is a category from a list, Rekognition. If it's a description or a judgment, a foundation model.
Constraints
Custom Labels needs labeled data and produces a model with inference hours you pay for while it runs. Face collections have size limits and are Regional. Video analysis is asynchronous with results via SNS. Accuracy varies with image quality, angle, and lighting, and confidence thresholds are yours to set. Facial analysis carries genuine legal and ethical constraints in some jurisdictions, which occasionally appears as a governance consideration.

Amazon Comprehend
What it is
Comprehend is natural language processing over text, returning structured results: entity recognition (people, places, organizations, dates, quantities), key phrase extraction, sentiment (positive, negative, neutral, mixed) and targeted sentiment (sentiment toward specific entities), language detection, syntax analysis, topic modeling across a document collection, and PII detection and redaction via DetectPiiEntities.
Custom classification and custom entity recognition let you train on your own labels — your support ticket categories, your industry-specific entity types. Comprehend Medical is a domain variant for clinical text.
Where it fits
Comprehend is the cheap, deterministic, structured-output option for text analysis at volume. When a stem describes classifying thousands of documents into known categories, or extracting entities into a database, Comprehend does it more cheaply and more consistently than a foundation model — and returns confidence scores, which foundation models don't natively provide.
The PII detection capability is the one most likely to appear in a discrimination question, so hold the three-service split precisely:
Guardrails — in the model request/response path, in real time. "Don't let PII reach the model or the user."
Comprehend — an API you call on arbitrary text in your own pipeline. "Redact PII from these documents before we index them."
Macie — scheduled scanning of data at rest in S3. "Find out whether we have PII in our buckets."
Intercept, process, discover.
When not to use it
For open-ended understanding. Comprehend classifies into categories and extracts predefined entity types. "Summarize the customer's underlying frustration and suggest a response" is a foundation model task.
When the categories aren't known in advance, since custom classification needs labeled examples per category.
When nuance matters more than throughput. Comprehend's sentiment is four buckets. If a stem needs graded, explained, or contextual judgment, that's generative.

Amazon Kendra
What it is
Kendra is a managed intelligent search service for enterprise content. You create an index and connect data sources through a large catalog of connectors — S3, SharePoint, Confluence, Salesforce, ServiceNow, Box, Google Drive, databases, web crawlers — and it crawls, indexes, and serves natural-language search with semantic understanding rather than keyword matching. It returns ranked documents, extracted passages, and direct answers, plus FAQ support and relevance tuning by field.
Its defining capability: Kendra crawls and honors the access control lists of the source systems, so a user's search results are filtered at query time to documents they're already permitted to see.
Why that ACL capability decides questions
Reproducing enterprise permissions in a vector store means rebuilding a permissions model that already exists in SharePoint — and keeping it synchronized as it changes. Kendra does this natively.
So when a stem says users must only see results for documents they have permission to access in the source system, that is Kendra, even in a generative architecture where Knowledge Bases would otherwise be the default. Kendra can serve as the retrieval layer with a Bedrock model generating on top, which is how it appears in RAG designs.
The second reason to choose it is connector breadth — a stem listing several enterprise repositories to be searched together points here rather than at building ingestion for each.
Constraints
Kendra is provisioned, not serverless: you pay for index capacity continuously, and it is not cheap. This makes it a poor fit for small corpora and a frequent cost-question subject. Developer Edition has no SLA and isn't for production. Capacity scales in units for both storage and query throughput. Connector syncs are scheduled, so freshness is bounded by sync frequency.
And the definitional limit: Kendra retrieves; it does not generate. It returns documents, passages, and extracted answers. Conversational generation requires a model on top.
Kendra vs. Knowledge Bases vs. OpenSearch
Knowledge Bases — managed RAG through generation, least overhead, default for grounding a generative app.
Kendra — managed enterprise search, decisive when source-system ACLs must be enforced at query time or when connector breadth across enterprise repositories is the requirement.
OpenSearch — build it yourself, chosen for hybrid lexical/vector search, custom relevance scoring, or an existing investment.

Amazon Lex
What it is
Lex is a service for building conversational interfaces — chatbots and voice bots — using the same technology as Alexa. You define intents (what the user wants: BookFlight), utterances (example phrasings that map to an intent), slots (parameters the intent needs: origin, destination, date), and prompts for eliciting missing slots. Lex handles automatic speech recognition, natural language understanding, and dialog state, calling a fulfillment Lambda once it has gathered what it needs.
It integrates natively with Amazon Connect for phone-based self-service, and supports generative enhancements such as using a foundation model for slot resolution or descriptive bot building.
Where it fits, and the boundary with agents
Lex is the answer for structured, task-oriented conversation with deterministic fulfillment — checking an order status, booking an appointment, resetting a password, routing a call. Its strength is exactly its constraint: the set of things it can do is enumerated, so it behaves predictably, is testable, and cannot invent an answer.
That boundary against generative alternatives is where exam questions live. A Bedrock-powered agent handles open-ended conversation and can reason its way through problems you didn't enumerate — but it's non-deterministic and needs guardrails. Amazon Q Business answers questions from enterprise content without you defining intents at all.
The discriminator is whether the conversation space is known and bounded. A defined set of transactional tasks → Lex. Open-ended questions over a knowledge corpus → Q Business or a Bedrock/Knowledge Bases application. Open-ended problems requiring multi-step tool use → an agent.
Hybrid designs are common and often correct: Lex for the transactional intents, with a fallback intent routing anything else to a generative layer.
Constraints
Every intent must be defined and trained with sample utterances, which is real ongoing maintenance — this is the operational-overhead argument against Lex when a stem emphasizes it. Coverage is limited to what you built, and out-of-scope requests hit the fallback intent. Fulfillment logic lives in Lambda, which you own. Slot types, session duration, and language support each have limits, and voice quality depends on the telephony path.

Amazon Augmented AI (A2I)
What it is
A2I provides managed human review workflows for machine learning predictions. You define a flow definition specifying the conditions that trigger review — typically a confidence score below a threshold, a random sampling rate, or all predictions for a sensitive category — plus the worker task template and the workforce (private, vendor, or Mechanical Turk). When a prediction meets the condition, A2I routes it to a human, collects the judgment, and returns results to S3.
It integrates natively with Textract and Rekognition and can be wired to any custom model or workflow, including generative ones.
Why it matters
Every ML system has a confidence distribution, and the tail is where errors concentrate. A2I formalizes the idea that the model handles the confident majority and humans handle the ambiguous minority — which is often the only architecture that clears an accuracy bar that no model reaches alone, and it produces labeled data that improves the model over time.
For generative systems it's the human-in-the-loop control that governance questions ask for: high-stakes outputs — a medical summary, a legal document, a customer-facing communication — reviewed before they take effect.
The distinction that gets tested
Ground Truth labels data before training. A2I reviews predictions during production inference. Both use human workforces and both can use Mechanical Turk, which is why they're confusable. Building a training dataset → Ground Truth. Reviewing live low-confidence predictions → A2I. Before versus during.
Constraints
Human review adds latency measured in minutes to hours, so A2I is asynchronous by nature and can't sit in a synchronous request path. It costs per review, so thresholds are a real cost lever — set the confidence bar too high and you route everything to humans, defeating the automation. Mechanical Turk means a public workforce, disqualifying for confidential data.

The layer-selection rule, restated
When a scenario involves unstructured data, work through it in this order:
Does a purpose-built service do exactly this? Speech → Transcribe. Scanned documents → Textract. Known visual categories → Rekognition. Text classification and entity extraction → Comprehend. Enterprise search with permissions → Kendra. Bounded task conversation → Lex. If yes, and the stem has an overhead qualifier, that's very likely the answer.
Does the task need open-ended interpretation, generation, or reasoning? If the required output can't be expressed as a category, an entity, or a transcript, it's a foundation model in Bedrock.
Is a custom model genuinely required? Only when the task is specific to your data, you have labeled examples, and no managed service covers it. Under an overhead qualifier, this is usually the distractor.
Does accuracy need a human backstop? A2I for reviewing predictions, Ground Truth for building training data.
And note that these compose. Many correct architectures chain layers: Textract extracts, Comprehend redacts PII, Bedrock summarizes, A2I reviews the low-confidence results. An option using one service where the scenario needs a chain is often wrong for being incomplete rather than for naming the wrong service.

Test yourself
Scanned invoices must be summarized and risk-assessed. Which services, in which order, and why isn't one of them enough?
Call recordings must be retained for compliance with card numbers removed. Which service and which feature — and why isn't downstream text redaction sufficient?
Moderate user-uploaded images for explicit content versus identify emerging visual trends in them. Different services — state the rule that separates them.
Users must search SharePoint, Confluence, and S3 together, seeing only permitted documents. Which service, and what specifically disqualifies Knowledge Bases?
A stem describes a bot handling five transactional tasks with strict predictability. Why Lex over a Bedrock agent, and what would flip it?
Comprehend, Guardrails, and Macie all detect PII. Give the one-word verb that distinguishes each.
A document extraction pipeline needs 99% accuracy and the model reaches 94%. What's the architecture, and what's the cost lever inside it?

Unstarred

Dunk (exclude from study)

The Purpose-Built AI Services

Review Questions

Todos

Sensemaker