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.
Within a fortnight the bill and the latency say otherwise. The invoice extraction is slow, and it sometimes returns a total that is not on the page. The sensitivity check gives a different answer from one run to the next. Nobody has worked out how to get call audio into a text-only model at all. What sits underneath all of it: which of these tasks is genuinely 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. That generality is 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 dominant language of this string”, or “convert this speech to text”, there is one correct behaviour and no call for open-ended reasoning. A purpose-built service is trained for that single behaviour. It costs less per call, answers faster, and returns the same thing every time.
Determinism separates the two most sharply. Textract returns the same structured output for the same document, and every block carries a confidence score from 0 to 100 that you can threshold on. A foundation model asked to read that document generates text token by token. Across calls it can phrase things differently, drift out of the requested format, or return a plausible value that was never on the page. For anything a downstream system parses, or any number a business books against, that variability is a liability.
Cost and latency follow the same line. Purpose-built services are priced per unit of the thing they do: pages processed, characters translated, seconds of audio, images analysed. Textract’s DetectDocumentText lists at USD$0.0015 a page in its first tier, its AnalyzeExpense API at USD$0.01 a page, and Amazon Translate at USD$15 per million characters (us-west-2 list prices, which vary by Region and fall with volume). A page stays one page however dense the text on it, so the unit count does not climb the way a token count does. They are also single-hop APIs, with no prompt to assemble, no examples to ship and no reasoning preamble, so they answer faster.
The other half of the picture is where the purpose-built service stops. Once the task turns open-ended, the narrow service does not cover it. Combining several facts into an argument, generating fluent new text, following nuanced instructions, reasoning about something novel: that is foundation-model work. Summarising an invoice in friendly prose, answering a question that spans several documents, drafting a reply. No amount of OCR or entity detection gets you there.
In most real systems the two are stages in a pipeline rather than rivals. Transcribe turns a call into text, then a foundation model summarises it. Textract turns an invoice into structured fields, then a foundation model handles the awkward cases or writes the summary. The purpose-built service does the deterministic, high-volume front half. The foundation model does the open-ended back half, where generality is what the job needs. The design question is which service owns each stage, not which single service wins.
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 landscape
Amazon Textract. Optical character recognition and document analysis: lines and words, key-value form fields, tables and selection elements, pulled out of images and PDFs. It reads handwriting as well as print. Every block carries a confidence score and a Geometry object holding a bounding box and a finer polygon. For this scenario the relevant API is AnalyzeExpense, tuned for invoices and receipts: it maps whatever the document happens to call a field onto a standard taxonomy (VENDOR_NAME, INVOICE_RECEIPT_ID, DUE_DATE, SUBTOTAL, TAX, TOTAL) and returns line items as ITEM, QUANTITY, UNIT_PRICE and PRICE. Synchronous calls take a single-page document; multipage PDFs and TIFFs go through StartExpenseAnalysis and GetExpenseAnalysis.
Amazon Comprehend. Natural-language processing over text: entities, key phrases, dominant language, sentiment, targeted sentiment, syntax and PII detection, plus custom classification and custom entity recognition trained on your own data. Reach for it when you need to detect or label something in text deterministically rather than reason about it. Two limits shape the design. PII detection covers English and Spanish only. Locating PII entities works in real time, but producing a redacted copy requires an asynchronous analysis job over documents in S3.
Amazon Transcribe. Automatic speech recognition, in batch over files in S3 or over a live stream. It partitions speech by speaker, timestamps the output, accepts custom vocabularies in table format, and can redact PII in the transcript; streaming can also flag PII without removing it. Billing is per second of transcribed audio in one-second increments, with redaction charged on top. It is the front door for anything that starts as speech.
Amazon Translate. Neural machine translation between languages, at USD$15 per million characters for standard and batch translation. Fast and consistent, which is what bulk or latency-sensitive translation needs. A foundation model can translate too, and can do better on nuance or context, but Translate is the deterministic default for straightforward volume.
Amazon Rekognition. Image and video analysis: object, scene and concept detection, text detection, facial analysis and face comparison, and content moderation that returns a hierarchy of unsafe-content labels with confidence scores. 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 stored and streaming video as well as stills.
Amazon Polly. Text-to-speech, across four engines: generative, long-form, neural and standard. The neural engine adds a Newscaster speaking style, and SSML tags control pronunciation and pacing, with the supported tags depending on the engine. It is the output side of a voice pipeline, the counterpart to Transcribe, and a foundation model adds nothing to turning text into audio.
Amazon Lex. Managed conversational bots over voice and text, built around intents and slots, with AWS Lambda for fulfilment and conditional branching for flow control. Its generative features run on Amazon Bedrock. Assisted NLU and assisted slot resolution sharpen recognition inside the configured intents, and the built-in AMAZON.QnAIntent answers from a Bedrock knowledge base when no configured intent matches. The intent-and-slot backbone stays a managed piece either way.
Amazon Personalize. Recommendations and user segments trained on your interaction data, with real-time APIs for serving and batch jobs for bulk lists. It covers “customers who viewed X also viewed” results, next best action, and re-ranking search results. This is not a language task, and a foundation model is the wrong tool for it.
Managed search for retrieval. Amazon Kendra used to hold this slot, and no new build should pick it: it went into maintenance mode on 30 June 2026 and closed to new customers on 30 July 2026. Existing indexes keep running with bug fixes and security updates, and Kendra GenAI indices can still be queried from a Bedrock knowledge base or Amazon Q Business. AWS points new search applications at an Amazon Bedrock managed knowledge base instead. That runs the whole retrieval pipeline: chunking, a selectable embedding model, a managed vector store, hybrid keyword-plus-semantic search, and a RetrieveAndGenerate call that returns a grounded answer with citations. Its connector list is much shorter than Kendra’s, so anything outside it lands in S3 first.
Evaluation
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 and retrieval | Bedrock managed knowledge base | ✓ | ✓ (retrieval) | Mixed | 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 where a foundation model does work nothing else will.
Routing the work
The solution
The invoice extraction is the clearest purpose-built win. Textract’s AnalyzeExpense is built for this exact document type. It returns vendor name, invoice date, due date, subtotal, tax and total against a fixed taxonomy, along with the line items, each field carrying a confidence score and a bounding box. That gives the pipeline two things a prompt cannot. One is a threshold, so low-confidence pages route to a human queue. The other is provenance: a total on the output came from a box on the page, not from a model’s next-token choice. At USD$0.01 a page in the first tier, and one hop, it also costs less and answers faster than shipping a large image into a model and parsing prose back out. The foundation model still has a role, just later. Once the fields exist, a model is the right tool for the friendly summary, or for an invoice whose layout Textract handled poorly.
The sensitivity check is a Comprehend job rather than a prompt. Its PII detection returns a defined set of entity types with confidence scores, the same way every time. Redaction is the part to design around: locating entities works in real time, but producing a redacted copy runs as an asynchronous analysis job over documents in S3. So the pipeline stages the notes through a bucket and reads the redacted output back, rather than calling a synchronous API and expecting masked text. Notes in anything other than English or Spanish fall outside Comprehend PII, and that case needs its own plan. Asking a foundation model “is there anything sensitive here” returns an answer that varies from run to run, with no defined entity list behind it, on a compliance task that has to answer the same way each time. Comprehend also covers the language detection, sentiment and custom classification the product will want next.
The call-centre work makes the pipeline pattern unavoidable. A text-only foundation model cannot ingest audio, so Transcribe does the first stage: speech into text, partitioned by speaker, timestamped, with PII redacted on the way through. One caveat, because the shape of this has changed. Bedrock hosts a speech-to-speech model, Amazon Nova Sonic, which takes streamed audio directly over a bidirectional API and answers in audio. That suits a live conversation. It does not leave the durable, searchable, redacted transcript this product is built on, so it is not a substitute for Transcribe here. Once the transcript exists, the foundation model summarises the call or pulls out the follow-up actions. Search across those transcripts is a managed-search job. If the team wants answers rather than links, that becomes retrieval-augmented generation: the knowledge base finds the passages and the model answers from them. The voice bot is Lex for the intent-and-slot structure and the speech interface, Polly for the spoken responses, and AMAZON.QnAIntent over a Bedrock knowledge base for the turns no intent covers. None of this is a single-tool problem. Forcing the whole thing through one foundation model would be slower, dearer and less reliable than letting each service take the stage it was built for.
Worked example
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. AnalyzeExpense returns the line items, quantities, unit prices and totals against its standard field names, each with a confidence score and a bounding box. The pipeline thresholds on those scores: anything below the bar routes to a human queue, everything above flows on. A foundation model is deliberately absent here. The fixed field names and the scores are why 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 a PII redaction job, which writes a redacted copy back to S3 before the record is stored. Defined entity types, scored, repeatable.
Stage three is the summary, and it is the first genuinely 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 AUD$1,240, due end of month”. It can also flag anything that looks unusual against the extracted numbers. This is generation and light reasoning, so the model’s generality is the right fit.
Two of the three stages are purpose-built services doing deterministic, high-volume work. The foundation model is reserved for the one stage that is actually open-ended. Push all three through a model and the team would spend more, wait longer, and lose the confidence scores that let the total stand. The pipeline puts each task on the tool built for it.
What’s worth remembering
- Generality is the wrong default for a narrow, well-defined task. A purpose-built service tuned for one behaviour costs less per call, answers faster, and returns the same thing every time.
- Determinism is the sharpest divide. Textract, Comprehend, Transcribe, Translate and Rekognition return machine-parseable output with confidence scores; a foundation model generates token by token and can drift.
- A foundation model is the right tool 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 common real design is a pipeline. A purpose-built service does the deterministic front half and feeds a foundation model the open-ended back half.
- Check the edges before committing. Comprehend PII covers English and Spanish and redacts only in an asynchronous job, Textract handles multipage documents only through its async operations, and Bedrock’s Nova Sonic takes audio directly but leaves no stored transcript.
- Amazon Kendra closed to new customers on 30 July 2026, so retrieval for a new build goes to an Amazon Bedrock managed knowledge base.