The situation
A team is building a document-processing product. Scanned supplier invoices land in an S3 bucket; the team needs the line items and totals pulled out, the free-text notes checked for anything sensitive before storage, and a short plain-language summary of each invoice for the accounts inbox. There is also a call centre attached to the same business: recorded support calls that someone wants transcribed, searched, and eventually summarised, plus an ambition to add a voice bot that can handle “where is my order” without a human.
The first instinct, because the team has a Bedrock account and a working prompt library, is to do all of it with a foundation model. Feed the model the invoice image and ask for the fields. Feed it the notes and ask “is there anything sensitive here”. Feed it the call audio, or rather a transcript from somewhere, and ask for a summary. One model, one interface, one mental model.
The bill and the latency tell a different story within a fortnight. The invoice extraction is slow and occasionally hallucinates a total that isn’t on the page. The sensitivity check is inconsistent from run to run. And nobody has worked out how to get audio into a text-only model in the first place. The question underneath all of it: which of these tasks is actually a foundation-model job, and which is a solved problem that AWS already sells as a managed API.
What actually matters
A foundation model is a general reasoning and generation engine, and generality is exactly what makes it the wrong default for a narrow, well-specified task. When the job is “turn this scanned page into text and tables”, or “detect the language of this string”, or “convert this speech to text”, the task has one correct behaviour and no need for open-ended reasoning. A purpose-built service is trained and tuned for that single behaviour, so it is cheaper per call, lower in latency, and far more consistent than a model you steer with a prompt and hope stays on task.
Determinism is the property that separates the two most sharply. A managed service like Textract returns the same structured output for the same document every time, with confidence scores you can threshold on. A foundation model asked to read the same document is generating text token by token, so it can phrase things differently across calls, drift out of the requested format, or invent a plausible value that wasn’t on the page. For anything a downstream system parses or a business relies on for a number, that variability is a liability, not a feature.
Cost and latency compound the point. Purpose-built services are priced per unit of the thing they do (pages processed, characters translated, seconds of audio, images analysed), and that price is typically a fraction of what the equivalent foundation-model call costs in tokens, without the token count ballooning on a large document. They are also single-hop APIs with no prompt to assemble, no examples to ship, and no reasoning preamble to pay for, so they answer faster.
The other half of the picture is knowing where the purpose-built service stops. The moment the task turns open-ended, needs to combine several facts into an argument, generate fluent new text, follow nuanced instructions, or reason about something novel, the narrow service has nothing to offer and the foundation model is the right tool. Summarising an invoice in friendly prose, answering a question that spans several documents, drafting a reply: these are generation and reasoning, and no amount of OCR or entity detection gets you there.
Which leads to the pattern that matters most in practice. The two are not rivals for most real systems; they are stages in a pipeline. Transcribe turns a call into text, then a foundation model summarises it. Textract turns an invoice into structured text and tables, then a foundation model reasons over the awkward cases or writes the summary. The purpose-built service does the deterministic, high-volume, well-defined front half cheaply and reliably, and the foundation model does the open-ended back half where its generality earns its keep. Choosing well is less “which one” than “which does each stage”.
What we’ll filter on
- Is the task well-defined and single-purpose (one correct behaviour, like OCR or speech-to-text), or open-ended (reasoning, generation, novel instructions)?
- How cost- and latency-sensitive is the workload, especially at volume or on large inputs?
- Does the output need to be deterministic and machine-parseable, with managed accuracy and confidence scores, rather than free-generated text?
- Is this a self-contained task, or a building block that feeds a larger generative flow (a front-half stage before a foundation model)?
The service landscape
Amazon Textract. Optical character recognition and document analysis: raw text, key-value form fields, and tables extracted from scanned pages, PDFs, and images, with confidence scores per element. Use it when the job is getting structured content out of documents. It beats asking a model to “read this scan” because it returns coordinates and confidences, handles multi-page documents at volume, and does not invent values.
Amazon Comprehend. Natural-language processing over text: entities, key phrases, dominant language, sentiment, and PII detection and redaction, plus custom classification and custom entity models you can train. This is the reach-for service when you need to detect or label something in text deterministically, such as flagging and redacting personal data before storage, rather than reasoning about it.
Amazon Transcribe. Automatic speech recognition, turning audio into text with speaker labels, timestamps, custom vocabularies, and automatic PII redaction in the transcript. It is the front door for anything that starts as speech; a text-only foundation model cannot ingest audio, so Transcribe is what makes the audio available to the rest of a pipeline.
Amazon Translate. Neural machine translation between languages. Fast, cheap per character, and consistent, which is what you want for bulk or latency-sensitive translation. A foundation model can translate too, and can be better on nuance or context, but Translate is the deterministic, cost-effective default for straightforward translation at volume.
Amazon Rekognition. Image and video analysis: object and scene detection, text in images, face detection and comparison, and content moderation. When the task is “what is in this picture” or “is this image safe”, Rekognition is the tuned, per-image-priced answer, and it covers video as well as stills.
Amazon Polly. Text-to-speech, synthesising natural-sounding voices from text, including neural voices and SSML control over pronunciation and pacing. It is the output side of a voice pipeline, the counterpart to Transcribe, and there is no reason to involve a foundation model in turning text into audio.
Amazon Lex. Managed conversational bots built around intents and slots: it recognises what the user wants (the intent) and collects the required parameters (the slots), and integrates with Lambda for fulfilment. Lex handles the structured dialogue-management and speech interface of a bot; increasingly a foundation model sits behind it for the open-ended turns, but the intent-and-slot backbone is a solved, managed piece.
Amazon Personalize. Real-time recommendations and personalisation, trained on your interaction data, serving “customers who did X also did Y” style results. This is not a language task at all, and a foundation model is the wrong tool for it; Personalize is the purpose-built service for recommendation ranking.
Amazon Kendra. Managed intelligent search across your enterprise content, with natural-language queries and relevance tuning, connectors to common data sources, and semantic ranking. It is frequently the retrieval layer in a retrieval-augmented generation setup, finding the right passages that a foundation model then answers from.
Side by side
| Task | Purpose-built service | Well-defined? | Deterministic output | Typical cost vs FM | Where the FM fits |
|---|---|---|---|---|---|
| OCR, forms, tables from documents | Textract | ✓ | ✓ | Lower | Reason over / summarise extracted text |
| Entities, sentiment, PII, classify | Comprehend | ✓ | ✓ | Lower | Nuanced or novel judgement calls |
| Speech to text | Transcribe | ✓ | ✓ | Lower | Summarise / analyse the transcript |
| Machine translation | Translate | ✓ | ✓ | Lower | Nuance-heavy or context-dependent translation |
| Image / video analysis | Rekognition | ✓ | ✓ | Lower | Describe or reason about the scene |
| Text to speech | Polly | ✓ | ✓ | Lower | Generate the text that gets spoken |
| Intent / slot conversational bot | Lex | ✓ (structured dialogue) | Partly | Lower for the backbone | Open-ended conversational turns |
| Recommendations | Personalize | ✓ | ✓ | Not an FM task | ✗ |
| Enterprise search | Kendra | ✓ | ✓ | Lower | Answer from retrieved passages (RAG) |
| Open-ended generation / reasoning | none | ✗ | ✗ | n/a | The foundation model is the tool |
The bottom row is the honest boundary: when the task is genuinely open-ended, there is no purpose-built service, and that is precisely when the foundation model earns its cost.
The picks in depth
The invoice extraction is the clearest purpose-built win, and it is where a foundation model both costs more and is less trustworthy. Textract is built to pull text, form fields, and tables out of scanned pages, and it returns each element with a confidence score and a position on the page. That gives the pipeline something a model prompt cannot: a threshold to route low-confidence pages to a human, and a guarantee that a total on the output was a total on the page rather than a plausible-looking number the model generated. Priced per page and answering in one hop, it is cheaper and faster than shipping a large image into a model and parsing prose back out. The foundation model still has a role here, just later: once Textract has the structured fields, a model is the right tool to write the friendly summary or to reason about an invoice whose layout Textract found awkward.
The sensitivity check is a Comprehend job, not a prompt. Detecting and redacting personal data is exactly what Comprehend’s PII detection does, deterministically, with a defined set of entity types and confidence scores, and it can redact in place. Asking a foundation model “is there anything sensitive here” gets you an answer that varies run to run and carries no guarantee, which is the last thing you want on a compliance-shaped task where consistency is the whole point. Comprehend also covers the language detection, sentiment, and custom classification the product will want next, all as managed APIs rather than prompts to maintain.
The call-centre work is where the pipeline pattern is unavoidable. A text-only foundation model cannot ingest audio at all, so Transcribe is not optional; it is the stage that turns speech into text with speaker labels and timestamps, and it can redact PII in the transcript on the way through. Only once there is a transcript does the foundation model come in, to summarise the call or extract the follow-up actions. Search across the transcripts is a Kendra job, and if the team wants answers rather than links, that becomes retrieval-augmented generation with Kendra finding the passages and the model answering from them. The voice bot is Lex for the intent-and-slot structure and the speech interface, Polly for the spoken responses, and a foundation model behind Lex for the open-ended turns the intents do not cover. Not one of these is a single-tool problem, and trying to force the whole thing through a foundation model would be slower, dearer, and less reliable than letting each service own the stage it was built for.
A worked example: the invoice pipeline, stage by stage
Take a single scanned supplier invoice landing in S3, and trace what each stage should own.
Stage one is extraction, and it belongs to Textract. It returns the line items, quantities, unit prices, and totals as key-value pairs and table cells, each with a confidence score. The pipeline thresholds on those scores: anything below the bar routes to a human queue, everything above flows on. A foundation model is deliberately not in this stage, because determinism and confidence scores are the whole reason the numbers can be trusted.
Stage two is the sensitivity pass, and it belongs to Comprehend. The free-text notes on the invoice go through PII detection, which flags and redacts personal data before the record is stored. Deterministic, defined entity types, no prompt to drift.
Stage three is the summary, and this is the first stage that is genuinely a foundation-model job. Given the structured fields from Textract, the model writes a short plain-language summary for the accounts inbox (“Supplier X, three line items, total £1,240, due end of month”), and can flag anything that looks unusual against the extracted numbers. This is generation and light reasoning, so the model’s generality is finally the right fit.
The shape of the answer is the point. Two of the three stages are purpose-built services doing deterministic, cheap, high-volume work, and the foundation model is reserved for the one stage that is actually open-ended. Had the team pushed all three through a model, they would have paid more, waited longer, and traded Textract’s confidence scores for a total they could not fully trust. The pipeline is not a compromise; it is each task on the tool built for it.
What’s worth remembering
- A foundation model is a general engine, and generality is the wrong default for a narrow, well-defined task; a purpose-built service tuned for one behaviour is cheaper, faster, and more consistent.
- Determinism is the sharpest divide: Textract, Comprehend, Transcribe, Translate, and Rekognition return consistent, machine-parseable output with confidence scores, while a foundation model free-generates and can drift or hallucinate.
- Purpose-built services are priced per unit of work (page, character, second, image) and answer in a single hop with no prompt to assemble, so they cost and latency less than the equivalent token-heavy model call.
- Match the service to the task: Textract for documents, Comprehend for text NLP and PII, Transcribe for speech-to-text, Translate for translation, Rekognition for images and video, Polly for text-to-speech, Lex for intent-and-slot bots, Personalize for recommendations, Kendra for enterprise search.
- The foundation model wins the moment the task turns open-ended: fluent generation, reasoning across several facts, nuanced instructions, or a novel case with no managed service behind it.
- The most common real design is a pipeline, not a contest: a purpose-built service does the deterministic front half and feeds a foundation model the open-ended back half.
- A text-only foundation model cannot ingest audio or images directly, so Transcribe and Textract are often not optional; they are what make the input available to the rest of the flow.
- Compliance-shaped tasks like PII detection want Comprehend’s consistency, not a prompt whose answer varies from run to run.
- Kendra plus a foundation model is the retrieval-augmented-generation pattern: the managed search finds the passages, the model answers from them.
- Before reaching for a prompt, ask whether the task is one well-defined thing AWS already sells as an API; the answer is often yes, and the model belongs a stage later.