Mapping AWS's AI Surface: Bedrock, SageMaker & Purpose-Built Services

AWS does not have one AI service. It has a landscape of them, arranged in layers.

The trouble is that the names do not tell you where each one sits. Rekognition, Bedrock, SageMaker, Comprehend, Q - they sound like siblings, but they operate at very different levels of abstraction. Picking well means seeing the map before you pick a pin.

This page gives you that map. Every other page in this group is a zoom into one region of it.

Summary

• AWS's AI surface divides into three layers: managed foundation models (Amazon Bedrock), build-your-own ML (Amazon SageMaker AI), and purpose-built AI services (Rekognition, Comprehend, Transcribe, Polly, Textract, Lex, Amazon Q, and more).
• Insight: the layers trade control for convenience. Purpose-built services ask almost nothing of you; SageMaker AI asks you to own the model; Bedrock sits in between with managed models you call but do not host.
• Key Concepts: foundation model, inference, endpoint, managed vs self-hosted, task-specific API, Bedrock Runtime.
• When to Use: any time you are deciding which AWS AI service to reach for, before you write a line of integration code.
• Limitations/Trade-offs: higher layers are faster to ship but less customizable; lower layers give full control at the cost of ML and infrastructure work.
• Related Topics: foundation models vs purpose-built services, AI/ML pricing models, and the AI-on-AWS starting tour.

Foundations

Start with the guiding rule: use the highest layer that solves your problem. The higher you go, the less you build.

Purpose-built AI services are the top layer. Each one does a single job behind a plain request-response API. You send an image and Amazon Rekognition returns labels; you send audio and Amazon Transcribe returns text; you send a document and Amazon Textract returns the fields. You bring no model, no training data, and no infrastructure. If a task service exists for your problem, it is almost always the fastest path.

Amazon Bedrock is the middle layer. It is a fully managed service that exposes foundation models - large, general-purpose models - through a single API. You call a model like Anthropic's Claude or Amazon Nova the same way you call any other AWS service. AWS hosts the model; you never manage a GPU. Bedrock fits open-ended language and generative work: summarizing, chatting, extracting, reasoning over text.

Amazon SageMaker AI is the foundation layer. It is the platform for teams that build, train, tune, and deploy their own machine-learning models. You control the data, the algorithm, the instances, and the endpoint. This is where you go when no managed model fits and you need something custom.

The three layers are not rivals. Most real systems use two or three of them together.

Mechanics & Interactions

Each layer is reached through the SDK the same way every AWS service is: create a client, send an operation, read the response. What differs is how much the response already knows.

A purpose-built service is a one-call affair. Here is Amazon Rekognition detecting labels in an image, in both SDKs.

# --- Python (boto3) ---
import boto3
 
rekognition = boto3.client("rekognition", region_name="us-east-1")
result = rekognition.detect_labels(
    Image={"S3Object": {"Bucket": "my-images", "Name": "street.jpg"}},
    MaxLabels=10,
)
for label in result["Labels"]:
    print(label["Name"], round(label["Confidence"], 1))

// --- TypeScript (AWS SDK v3) ---
import { RekognitionClient, DetectLabelsCommand } from "@aws-sdk/client-rekognition";
 
const rekognition = new RekognitionClient({ region: "us-east-1" });
const result = await rekognition.send(new DetectLabelsCommand({
  Image: { S3Object: { Bucket: "my-images", Name: "street.jpg" } },
  MaxLabels: 10,
}));
for (const label of result.Labels ?? []) {
  console.log(label.Name, label.Confidence?.toFixed(1));
}

No prompt, no model choice - the service already knows how to detect labels.

Bedrock is one layer down, so you also choose a model and shape the request. Inference runs through the Bedrock Runtime API, and the modern, model-agnostic entry point is the Converse operation.

# --- Python (boto3) ---
import boto3
 
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
response = bedrock.converse(
    modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
    messages=[{"role": "user", "content": [{"text": "Summarize AWS's AI layers."}]}],
)
print(response["output"]["message"]["content"][0]["text"])

// --- TypeScript (AWS SDK v3) ---
import { BedrockRuntimeClient, ConverseCommand } from "@aws-sdk/client-bedrock-runtime";
 
const bedrock = new BedrockRuntimeClient({ region: "us-east-1" });
const response = await bedrock.send(new ConverseCommand({
  modelId: "anthropic.claude-3-5-sonnet-20240620-v1:0",
  messages: [{ role: "user", content: [{ text: "Summarize AWS's AI layers." }] }],
}));
console.log(response.output?.message?.content?.[0]?.text);

The Converse API keeps one request shape across model providers, so switching from an Anthropic model to an Amazon Nova model is a modelId change, not a rewrite.

SageMaker AI is deeper still. You do not call a ready model - you deploy one to an endpoint first, then invoke that endpoint with sagemaker-runtime. The extra step is the price of owning the model. SageMaker JumpStart softens this by letting you deploy pre-built and open foundation models onto your own SageMaker endpoints, blending build-your-own control with a head start.

Advanced Considerations & Applications

The map has more regions than three headline names. The purpose-built layer is a whole family, grouped by the kind of data it understands.

Two services deserve a note because they blur the layers.

Amazon Q is a generative-AI assistant built on foundation models. Amazon Q Developer helps write and understand code; Amazon Q Business answers questions over your enterprise data. You consume Q as a finished product rather than assembling it from Bedrock yourself.

Bedrock is more than raw model calls. It bundles higher-level building blocks: Knowledge Bases for retrieval-augmented generation over your documents, Agents for multi-step tool-using workflows, and Guardrails for content and safety policy. These let you build generative applications without dropping to SageMaker.

Systems commonly span layers. A document pipeline might use Textract to read a scan, Comprehend to pull entities, and Bedrock to write a natural-language summary. Reading the map as layers, not as a flat list of brand names, is what makes those combinations obvious.

Common Misconceptions

• "Bedrock and SageMaker are competitors, pick one." - They sit at different layers. Bedrock gives you managed models to call; SageMaker gives you a platform to build models. Many teams use both.
• "Purpose-built services are just small models I still have to train." - No. They are fully trained and managed. You send data and read a result; there is no model to train or host.
• "You need SageMaker to use foundation models." - Not for managed models. Bedrock serves foundation models with no SageMaker involvement. SageMaker JumpStart is for hosting models yourself when you want that control.
• "Amazon Q is a separate model you must configure." - Q is a finished assistant product built on foundation models. You use it as-is rather than wiring up inference yourself.
• "All AWS AI services share one API." - Each service has its own operations. What they share is the SDK call model - client, request, response - not a single unified endpoint.

FAQs

Related

• Foundation Models vs Purpose-Built AI Services - when a general model beats a task-specific API.
• AI on AWS Basics - a starting tour and which service fits a first project.
• AWS AI/ML Pricing Models Compared - how each layer bills.
• AI on AWS Best Practices - a decision checklist for picking the right service.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).