AWS AI Services Explained: Bedrock, SageMaker AI and Amazon Q

View the full Getting to Know AWS AI: Services, Use Cases and the Reality of Adoption →

AWS AI is not one product, and choosing the wrong part of its portfolio can mean using an expensive model platform for a task that needs a focused API. Amazon Bedrock, SageMaker AI, Amazon Q and services such as Textract and Transcribe can work together, but they serve different jobs: generative-AI application building, machine-learning lifecycle management, ready-made assistance, and defined document, media and language tasks.

That range helps only when the categories are clear. Otherwise, it’s easy to choose an expensive, complicated platform for a job that needs one focused API call — or mistake a polished AI assistant for a toolkit for building a customer-facing application.

The practical map is simple. Amazon Bedrock is chiefly for building generative-AI applications with foundation models. Amazon SageMaker AI covers the wider machine-learning lifecycle: preparing data, developing, training, deploying and governing models. Amazon Q is AWS’s ready-made generative AI assistant line for business users and developers. Then come specialist services — Textract, Transcribe, Translate and the rest — for defined media, language and document tasks, without requiring a team to become machine-learning engineers.

They can appear in the same architecture. They aren’t interchangeable.

AWS AI is a portfolio, not a shortcut

AWS markets an extensive AI and machine-learning estate, but the product names can hide a basic distinction. Some services expose a ready-to-call capability. Others provide a platform for building and operating models. Others are finished assistants for a particular user.

For many organisations, the right entry point isn’t the fashionable one. If the job is extracting tables from supplier invoices, a document-analysis service is a more direct answer than a general-purpose large language model. If the job is a tailored fraud model trained on years of internal transactions, a prompt to a foundation model is unlikely to be the whole answer.

Generative AI has blurred some boundaries, as AWS adds generative features to older services and links Bedrock with SageMaker AI. The underlying choices remain. If anything, they matter more.

The terms worth getting right

Machine learning (ML) is the broad discipline of using data to develop systems that recognise patterns or make predictions. A model might estimate delivery times, classify support tickets or identify unusual payment activity. Not all machine learning generates prose, images or code.

Generative AI is the subset designed to produce new output: text, software code, images, audio or other content. It often uses large language models (LLMs) for text-based work, but generative AI is broader than chat interfaces.

Foundation models are large, broadly trained AI models that can be adapted to numerous tasks. AWS describes them as models with many parameters trained on massive and diverse datasets; depending on the model, they can generate text or images, process multiple input types, or create embeddings — numerical representations used to compare meaning and retrieve related material. Amazon Bedrock provides access to Amazon’s own models and a changing catalogue from third-party model providers. The catalogue and feature availability aren’t identical in every AWS Region, so a model name on a product page isn’t a deployment plan.

Training is the process of adjusting a model using data so it learns a task or becomes more effective for one. Traditional ML training may mean building a model from tabular operational data. With foundation models, the more realistic enterprise operation is often fine-tuning or another form of customisation, not training a frontier-scale model from scratch.

Inference is when a trained model is put to work. You submit an image, question, audio clip or feature set; the deployed model returns a label, prediction, transcription or generated response. For generative models, settings such as output length and randomness affect what comes back. Inference isn’t a technical footnote: it’s the live service an application depends on.

Managed AI APIs package a particular AI capability behind an AWS API. The customer supplies input and handles the result, while AWS operates the underlying model and infrastructure. They are deliberately narrower than Bedrock or SageMaker AI. Usually, that’s the point.

Agents aren’t simply chatbots with a newer label. In the Bedrock sense, an agent combines a foundation model with instructions and, where configured, a knowledge base and action groups. The model can use retrieved information or invoke defined actions while trying to complete a task. That can be useful, but the surrounding workflow, permissions and action design still determine whether it is safe or dependable. An agent is an application pattern, not proof that a process has been properly automated.

Amazon Bedrock: the generative-AI building layer

Amazon Bedrock is the natural AWS starting point when the requirement is to put a foundation model into an application without running the model-serving infrastructure yourself. Developers can call supported models through managed APIs, select models based on capability and constraints, and use Bedrock features around them, including prompt management, knowledge bases, model customisation, flows and agents.

That makes Bedrock the relevant service for a bespoke generative-AI feature: a summarisation function in an existing product, an internal question-answering tool grounded in selected company documents, a content-processing pipeline, or an application that needs model choice rather than commitment to one provider’s API.

Model choice deserves a little scepticism. Testing models and changing them can be useful, but moving from one to another can still alter output quality, prompt behaviour, supported input types, regional options and cost. A common API reduces integration work; it doesn’t make different models identical.

Bedrock also isn’t synonymous with a chatbot. A chat interface may be the first thing a team demonstrates, but the service also suits background generation and classification-style workflows. Nor does using a knowledge base turn a model into a source of truth. Retrieval-augmented generation, usually shortened to RAG, adds selected material to the model’s context before it generates an answer. It can make answers more relevant and attributable, but the application still needs sensible retrieval, permissions and evaluation.

SageMaker AI: when the model lifecycle is the work

Amazon SageMaker AI is AWS’s managed machine-learning platform. Its centre of gravity differs from Bedrock’s: it is intended for data scientists and developers who need to build, train and deploy models, as well as monitor quality and document governance through the ML lifecycle.

This is where a team goes when the distinctive value lies in its data, its model-development process or its control over deployment. Examples include training a demand-forecasting model, developing a computer-vision classifier for a particular class of equipment, or hosting a model with custom inference logic and fine-grained control over serving infrastructure.

That doesn’t make SageMaker AI a specialist-only product. It includes managed and automated options alongside notebook- and code-led workflows. But it remains a platform where data preparation, experiment design, validation, deployment and monitoring are central. Those are real jobs, not details AWS has made disappear.

The usual Bedrock-versus-SageMaker question is slightly wrong. Choose Bedrock when the main job is consuming or adapting a supported foundation model in a generative application. Choose SageMaker AI when the main job is creating, training, hosting or governing an ML model and its lifecycle. The two can meet: a model developed or fine-tuned in SageMaker AI may be deployed through SageMaker infrastructure or, for supported cases, imported into Bedrock for managed inference.

Amazon Q: an assistant, not the general platform

Amazon Q Developer is a generative AI assistant for people who need help understanding, building, extending and operating applications and workloads on AWS. It can work in AWS interfaces and development environments, offering code help alongside assistance with AWS questions and operational tasks.

Amazon Q Business, meanwhile, is aimed at organisational knowledge and work. AWS positions it as an assistant that can answer questions from approved connected data and help carry out configured tasks.

Both are products people use directly. They may be powered by Bedrock, but that doesn’t make them substitutes for Bedrock. A developer building an in-house service that needs a model API, retrieval design and application logic should look at Bedrock. A team wanting an AWS-aware coding assistant or an enterprise assistant for staff should begin by evaluating Amazon Q’s specific capabilities and connectors.

Keep that distinction intact in procurement discussions. “We need an AI assistant” and “we need a platform to build an AI capability” are materially different requirements, even if both eventually invoke a foundation model.

The focused services: often the least theatrical answer

AWS’s prebuilt AI services are often the sensible route for a tightly defined task. They remove much of the model-selection and application-building work, while returning structured results with boundaries a team can test.

• Amazon Rekognition analyses images and video. It can identify labels such as objects, scenes and activities, and offers other image and video analysis features. Treat results as model outputs to validate against the real use case, especially where people or consequential decisions are involved.
• Amazon Textract extracts text and document structure from image files and PDFs. It can identify forms, tables, key-value pairs, signatures and specialised document types such as invoices and receipts. Textract extracts what the document appears to say; it doesn’t establish whether an invoice, figure or form entry is correct.
• Amazon Transcribe converts speech to text, either from stored media or streaming audio. It includes options such as speaker partitioning and customisation features, but transcription quality will still vary with audio quality, vocabulary, accents and overlapping speech.
• Amazon Translate performs machine translation between supported languages. It is a translation service, not a multilingual policy or legal-review process; specialist terminology and high-stakes wording deserve human review.
• Amazon Polly converts text to synthesised speech, with voice and output-format choices. It is the converse of Transcribe, but not a translation tool: it speaks the language present in the supplied text.
• Amazon Lex is for building voice and text conversational interfaces with configured intents, slots and dialogue flows. It is useful where a conversation must reliably collect defined information and invoke business logic. Don’t casually conflate it with an open-ended Bedrock agent.
• Amazon Comprehend analyses text for entities, key phrases, language, sentiment and related natural language processing (NLP) outputs. Think of it as structured text analysis, not a general writing assistant.

These services can be composed. A document workflow might use Textract to turn scans into structured text, Comprehend to tag or classify it, and Bedrock to produce a human-readable summary. That combination isn’t automatically better than one service; each extra step introduces data movement, latency, cost and another result to assess.

Choose the route that matches the first useful problem

Start with the noun in the problem statement, not the word “AI”. “We need to extract purchase-order fields” points somewhere different from “we need to let customers ask questions in natural language”. The former may need Textract; the latter may need Bedrock, retrieval and a designed application experience. A requirement to predict a business outcome from proprietary history may instead call for SageMaker AI.

Part 2, What Can AWS AI Actually Do? Practical Services and Use Cases Compared, examines how these families are used in practice and where their boundaries matter. Part 3, Should You Adopt AWS AI? A Practical Test for Cost, Risk and Readiness, turns to the less glamorous questions: whether the data, skills, security model, budget and expected value justify putting any of this into production.