Cargando...
Cargando...
The definitive guide to choosing between custom ML engineering and managed foundation model access on AWS
SageMaker = train/deploy your own models; Bedrock = consume pre-built foundation models via API
| Feature | SageMaker Build, train, deploy custom ML models | Bedrock API access to 100+ foundation models |
|---|---|---|
Primary Use Case The single most tested distinction: SageMaker = you own the model training; Bedrock = AWS/partners own the model, you consume it | Full ML lifecycle: data prep, training, tuning, deployment, monitoring of CUSTOM models | Build generative AI apps using pre-trained Foundation Models (FMs) without managing infrastructure |
Who Owns the Model Weights Critical for data sovereignty and IP questions. If the exam says 'proprietary model weights must stay in our account,' answer is SageMaker | You own and control all model artifacts stored in your S3 bucket | AWS and model providers (Anthropic, Amazon, DeepSeek, OpenAI, etc.) own the weights — you access via API |
ML Expertise Required Exam scenarios mentioning 'no ML expertise' or 'fastest time to market' for gen AI → Bedrock | High — requires data scientists/ML engineers; you manage algorithms, hyperparameters, training jobs, compute | Low — developers can call APIs with prompt engineering; no ML training expertise needed |
Model Customization Bedrock fine-tuning does NOT give you model weights. SageMaker fine-tuning stores artifacts in YOUR S3. Huge exam trap. | Full control: bring your own algorithm, custom containers, fine-tune any open-source model, full hyperparameter control | Fine-tuning (continued pre-training + fine-tuning) on select models; RAG via Knowledge Bases; model evaluation — but NO access to raw weights |
Supported Model Types Traditional ML (XGBoost, Random Forest, fraud detection on tabular data) = SageMaker. Generative AI text/image/multimodal = likely Bedrock | Any ML model: tabular, NLP, CV, time-series, reinforcement learning, LLMs (open source like Llama, Mistral via JumpStart) | Foundation Models only: LLMs, multimodal, image gen — from Amazon Nova, Anthropic Claude, DeepSeek, MiniMax, Moonshot AI, OpenAI (100+ FMs) |
Infrastructure Management Bedrock is truly serverless for inference. SageMaker endpoints require instance selection and scaling config | Managed but you choose instance types, cluster sizes, scaling policies for training and inference endpoints | Fully serverless — zero infrastructure decisions; AWS manages all compute scaling automatically |
Pricing Model Bedrock on-demand = no upfront cost, pay per token. Bedrock Provisioned Throughput = reserved capacity, hourly charge. SageMaker = instance-hour billing | Pay per instance-hour for training, processing, hosting (notebook instances, training jobs, endpoints); also SageMaker Studio costs | Pay per token (input + output tokens) for on-demand; Provisioned Throughput for reserved capacity (model units × hours); Batch inference discounts available |
Inference Latency Options SageMaker Async Inference = large payloads, long processing. SageMaker Batch Transform = offline bulk scoring. Bedrock Batch = async bulk FM inference at discount | Real-time endpoints, Serverless Inference, Async Inference, Batch Transform — full control over latency/cost tradeoff | Synchronous (InvokeModel), streaming (InvokeModelWithResponseStream), Batch Inference, Converse API — latency controlled by quotas/throughput |
RAG (Retrieval-Augmented Generation) For exam: 'managed RAG without building pipeline' = Bedrock Knowledge Bases. Custom/complex RAG with proprietary models = SageMaker | Build custom RAG pipelines manually using SageMaker + OpenSearch/Kendra + your orchestration code | Native Knowledge Bases feature — managed RAG with S3 data source, automatic chunking, embedding, vector store (OpenSearch Serverless, Pinecone, Aurora, etc.) |
Agents / Agentic AI Exam scenario: 'AI agent that queries databases and calls APIs automatically' = Bedrock Agents + Lambda Action Groups | No native agent framework — must build custom orchestration (e.g., LangChain on SageMaker endpoints) | Native Bedrock Agents — orchestrates multi-step tasks, calls APIs via Action Groups (Lambda), integrates with Knowledge Bases automatically |
Model Evaluation Bedrock Model Evaluation is specifically for evaluating FM outputs (helpfulness, harmfulness, etc.). SageMaker Clarify = bias/explainability for traditional + custom ML | SageMaker Clarify for bias detection, explainability, model quality monitoring; SageMaker Model Monitor for drift | Native Model Evaluation — automated metrics (accuracy, robustness, toxicity) and human evaluation workflows for FMs |
Responsible AI / Guardrails AIF-C01 heavily tests this. Bedrock Guardrails = the answer for 'prevent harmful content from FM responses.' SageMaker Clarify ≠ content filtering | SageMaker Clarify for bias detection; no built-in content filtering for generative outputs | Bedrock Guardrails — content filtering, PII redaction, topic denial, grounding checks, word filters applied to FM inputs/outputs |
Security & Data Privacy Key Bedrock guarantee: your prompts and completions are NOT used to train the underlying FMs. This is a frequent exam assertion to validate | VPC support, KMS encryption, IAM, data stays in your account at all stages | Data NOT used to train base models; VPC support via PrivateLink; KMS encryption; IAM; no data retention by model providers |
MLOps / Pipeline Automation MLOps, model retraining pipelines, feature stores, model registry = SageMaker. Bedrock has no concept of retraining the base FM | SageMaker Pipelines (native CI/CD for ML), Model Registry, Feature Store, SageMaker Projects with CodePipeline integration | No MLOps pipeline concept — FMs are static; you version your prompts/agents/knowledge bases, not training pipelines |
Observability & Logging Bedrock Invocation Logging must be explicitly enabled — it is NOT on by default. Critical for compliance/audit exam scenarios | CloudWatch metrics/logs for endpoints, training jobs; CloudTrail for API calls; SageMaker Model Monitor for data/model drift | CloudWatch metrics for invocations/latency/errors; CloudTrail for API calls; Bedrock Model Invocation Logging to S3/CloudWatch for full request/response audit |
Cost Optimization Tools SageMaker Spot Training = cheapest for fault-tolerant training jobs. Bedrock has no spot concept — cost optimization is on-demand vs. provisioned throughput vs. batch | Spot Training (up to 90% savings), Savings Plans, right-sizing endpoints, Serverless Inference for spiky traffic, Inf2/Trn1 instances | On-demand (no commitment), Batch Inference (lower cost for async), Provisioned Throughput for predictable high-volume workloads |
API Compatibility Bedrock now supports OpenAI-compatible API — teams can migrate from OpenAI to Bedrock with minimal code changes. SageMaker does NOT have OpenAI compatibility | SageMaker Runtime API (InvokeEndpoint); SageMaker SDK (Python); boto3 | InvokeModel API, Converse API (unified multi-model), OpenAI-compatible API (Responses + Chat Completions), boto3 bedrock-runtime client |
Exam Category / Domain On AIF-C01: both appear heavily. On SAA-C03/SAP-C02: Bedrock = 'managed gen AI' answer; SageMaker = 'custom ML' answer. On CLF-C02: high-level distinction only | Traditional ML, MLOps, custom model training, data science workflows | Generative AI, Foundation Models, RAG, Agents, responsible AI for gen AI |
Summary
Choose SageMaker AI when you need to train, tune, and deploy your own custom ML models with full control over algorithms, data, and infrastructure — especially for traditional ML (tabular, CV, NLP) or fine-tuning open-source models with weight ownership. Choose Bedrock when you want to build generative AI applications quickly using pre-trained foundation models via API, with native features for RAG (Knowledge Bases), agentic workflows (Agents), content safety (Guardrails), and model evaluation — without any ML infrastructure management. The core decision axis is: Do you need to OWN and TRAIN a model (SageMaker) or CONSUME a pre-built FM (Bedrock)?
🎯 Decision Tree
If scenario involves: training data + custom algorithm + model weights ownership → SageMaker | traditional ML (tabular/fraud/forecasting) → SageMaker | MLOps pipeline/model registry/feature store → SageMaker | open-source LLM fine-tuning with weight control → SageMaker JumpStart | generative AI app with no ML training → Bedrock | RAG with managed vector store → Bedrock Knowledge Bases | AI agent calling APIs/databases → Bedrock Agents | content filtering on FM outputs → Bedrock Guardrails | fastest gen AI prototype → Bedrock on-demand | high-volume predictable FM inference → Bedrock Provisioned Throughput | audit log of every FM prompt+response → Bedrock Invocation Logging to S3
CRITICAL — Model Weight Ownership is the #1 decision axis: If any exam scenario mentions 'proprietary model,' 'own the weights,' 'export model artifacts,' or 'full algorithm control,' the answer is SageMaker. Bedrock fine-tuning creates a private model copy but NEVER gives you the actual weights. This distinction appears in AIF-C01, SAA-C03, and SAP-C02.
CRITICAL — Bedrock Guardrails vs. SageMaker Clarify are NOT interchangeable: Guardrails = runtime content filtering for FM inputs/outputs (block harmful topics, redact PII, prevent jailbreaks). Clarify = bias detection and explainability for trained ML models. AIF-C01 heavily tests responsible AI — 'prevent toxic FM responses at runtime' = Bedrock Guardrails, NOT Clarify.
CRITICAL — Bedrock Invocation Logging is OFF by default: For any exam scenario requiring audit trails, compliance logging, or monitoring of FM prompts/responses, you must explicitly enable Bedrock Model Invocation Logging (to S3 and/or CloudWatch). Assuming it's automatic is a guaranteed wrong answer.
IMPORTANT — RAG architecture questions: 'Managed RAG with no pipeline code' = Bedrock Knowledge Bases (handles chunking, embedding, vector store, retrieval automatically). 'Custom RAG with proprietary embedding model' or 'RAG with your own model' = SageMaker + OpenSearch/Kendra with custom code. The word 'managed' is your Bedrock signal.
IMPORTANT — Cost model differences matter for SAA-C03/SAP-C02: SageMaker = instance-hour billing (you pay even when idle unless using Serverless Inference). Bedrock on-demand = pure pay-per-token (no idle cost). For unpredictable/spiky generative AI workloads, Bedrock on-demand is almost always more cost-effective than a persistent SageMaker endpoint.
IMPORTANT — Traditional ML (tabular data, classification, regression, anomaly detection, forecasting) always maps to SageMaker, never Bedrock. Bedrock is exclusively for Foundation Models / generative AI. If the scenario involves XGBoost, Random Forest, fraud detection on structured data, or time-series forecasting — it's SageMaker.
NICE-TO-KNOW — SageMaker was renamed to 'Amazon SageMaker AI' on December 3, 2024, but ALL API namespaces, CLI commands (aws sagemaker), managed policies (AmazonSageMaker*), and service endpoints remain unchanged. Exam questions may use either name — treat them as identical.
The #1 exam trap: Assuming Bedrock fine-tuning gives you the same control as SageMaker fine-tuning. Candidates see 'fine-tuning' in a Bedrock context and assume they can export model weights, run the model on-premises, or fully control the training process — NONE of this is true with Bedrock. Bedrock fine-tuning creates a private customized model version that stays within AWS managed infrastructure; you never receive the weights. If a scenario requires weight portability, on-premises deployment, or complete training control, SageMaker is the only correct answer. A secondary trap: Using 'accuracy' as the evaluation metric for imbalanced datasets in SageMaker — always use F1, precision/recall, or AUC-ROC for imbalanced classes.
CertAI Tutor · AIF-C01, SAA-C03, SAP-C02, DEA-C01, CLF-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns