AWS offers two primary managed paths to production AI: Amazon Bedrock (API-first, managed inference, no infrastructure) and Amazon SageMaker (full ML lifecycle, training, hosting, MLOps). These services overlap significantly for foundation model work. Organizations consistently conflate them in architecture decisions and in cost analysis, with expensive results. This note dissects the cost surface of each service, the seams between them, and the hybrid patterns that work at enterprise scale.
The choice between Bedrock On-Demand and SageMaker JumpStart for serving the same foundation model is primarily a question of traffic volume and operational complexity tolerance.
Bedrock On-Demand charges per token consumed. There is no infrastructure to provision, no idle instance cost, and no minimum commitment. Costs scale linearly with usage.
SageMaker JumpStart deploys a foundation model to a dedicated endpoint on an instance you select. You pay the instance-hour rate 24/7 regardless of traffic. JumpStart simplifies deployment but does not eliminate the infrastructure management surface — you choose instance type, handle auto-scaling configuration, and absorb idle cost.
Cost Comparison: Same Model at Different Traffic Volumes
The following table models Llama 3.3 70B serving on each platform. Bedrock On-Demand rate: $0.72 per million input tokens, $0.72 per million output tokens. SageMaker JumpStart on ml.g5.48xlarge: approximately $16.35/hour list price (on-demand), capable of ~1,200 tokens/second sustained.
| Monthly Token Volume | Bedrock On-Demand | SageMaker (ml.g5.48xlarge, 24/7) | Break-even |
|---|---|---|---|
| 50M tokens | $36 | $11,772 | Bedrock wins by 326× |
| 200M tokens | $144 | $11,772 | Bedrock wins by 81× |
| 500M tokens | $360 | $11,772 | Bedrock wins by 32× |
| 1B tokens | $720 | $11,772 | Bedrock wins by 16× |
| 5B tokens | $3,600 | $11,772 | Bedrock wins by 3.3× |
| 10B tokens | $7,200 | $11,772 | Bedrock wins by 1.6× |
| 15B tokens | $10,800 | $11,772 | Near parity |
| 20B tokens | $14,400 | $11,772 | SageMaker wins by 1.2× |
Key threshold: The SageMaker dedicated endpoint becomes cheaper than Bedrock On-Demand at approximately 15–16 billion tokens per month on this model/instance pairing — roughly 500 million tokens per day. Very few enterprise workloads reach this threshold without Provisioned Throughput on Bedrock or Reserved capacity on SageMaker already in place.
Bedrock Provisioned Throughput compresses this crossover. For Llama 3.3 70B on Bedrock, provisioned throughput costs approximately $21.18/hour per model unit (1-month commitment), guaranteeing latency and throughput SLAs. At that rate, a single provisioned unit costs ~$15,250/month — nearly identical to running a dedicated SageMaker instance at list price, with Bedrock handling all infrastructure.
Conclusion: For workloads under ~10B tokens/month, Bedrock On-Demand is almost always the cheaper path. SageMaker dedicated endpoints justify the cost at high, predictable throughput or when you need full control over serving infrastructure (custom batching, speculative decoding, mixed-precision serving).
2. SageMaker Fine-Tuning → Bedrock Deployment: Full Pipeline Costs
The most common enterprise pattern involves fine-tuning a base model in SageMaker (where training tooling is mature) and then deploying the fine-tuned weights to Bedrock (where inference is managed). The cost model has three distinct phases.
Phase 1: Training on SageMaker
Training cost depends on model size, dataset size, and tuning technique. Parameter-efficient fine-tuning (LoRA/QLoRA) dramatically reduces GPU hours required.
| Model Size | Technique | Instance | Est. Duration | Instance Cost | Total Compute |
|---|---|---|---|---|---|
| 7B (Llama 3.1) | QLoRA | ml.g5.2xlarge ($1.52/hr) | 4–6 hours | $1.52/hr | $6–$9 |
| 7B | Full fine-tune | ml.g5.12xlarge ($7.09/hr) | 12–18 hours | $7.09/hr | $85–$128 |
| 13B | QLoRA | ml.g5.4xlarge ($2.03/hr) | 6–10 hours | $2.03/hr | $12–$20 |
| 13B | Full fine-tune | ml.p3.8xlarge ($12.24/hr) | 18–24 hours | $12.24/hr | $220–$294 |
| 70B | QLoRA | ml.g5.48xlarge ($16.35/hr) | 10–18 hours | $16.35/hr | $164–$294 |
| 70B | Full fine-tune | ml.p4d.24xlarge ($32.77/hr) | 48–96 hours | $32.77/hr | $1,573–$3,146 |
Overhead on top of compute: Storage (EBS for training checkpoints at ~$0.10/GB-month), S3 for dataset and model artifacts (~$0.023/GB-month), and SageMaker’s management layer adding approximately 20% over equivalent raw EC2 cost. A 70B QLoRA run that appears to cost $200 in GPU time will land at $240–$260 fully loaded.
SageMaker HyperPod reduces training cost for large runs by 40–60% via checkpointing and resilient distributed training across spot instances — relevant for multi-epoch 70B+ fine-tuning.
Phase 2: Model Export and S3 Staging
After training completes, artifacts are written to S3. A 70B model in FP16 is approximately 140 GB. A 7B LoRA adapter is typically 0.5–2 GB. S3 storage for staging is negligible ($3.22/month for 140 GB). The cost to stage the model for Bedrock import is effectively zero.
Phase 3: Bedrock Custom Model Import
Import itself is free — AWS charges no fee to bring weights into Bedrock. Supported architectures include Llama 2/3/3.1/3.2, Mistral, Mixtral, and Flan families.
Post-import, inference is billed on Bedrock’s custom model on-demand rate, which charges based on the number of model copies active and their duration, billed in 5-minute increments. This is functionally serverless — if no requests arrive, no compute runs, and cost drops to zero.
Total pipeline cost example (Llama 3.1 8B, QLoRA fine-tune, Bedrock deployment):
| Step | Cost |
|---|---|
| Training compute (ml.g5.2xlarge, 5 hours) | $7.60 |
| EBS storage during training | $0.50 |
| S3 staging (8B model, 2 weeks) | $0.35 |
| Bedrock import | $0 |
| Bedrock on-demand inference (100M tokens/month) | ~$15–$30 |
| One-time training cost | ~$8–$10 |
| Ongoing monthly inference | ~$15–$30 |
This pipeline is economically superior to keeping the model on a SageMaker endpoint for any workload below ~5B tokens/month, because Bedrock’s on-demand inference eliminates idle instance cost entirely.
3. Bedrock Custom Model Import: Hosting Cost vs SageMaker Endpoint
Once a SageMaker-trained model is imported to Bedrock, the cost structure shifts from instance-hours to consumption-based billing. This is the central economic advantage.
SageMaker endpoint (always-on): An ml.g5.2xlarge running a 7B model 24/7 costs $1.52/hour × 730 hours = $1,110/month, regardless of whether it receives a single request. Idle cost is 100% of total cost at zero traffic.
Bedrock custom model (on-demand): A 7B model imported to Bedrock incurs cost only when inference runs. At 50M tokens/month with average 500-token responses, this is roughly 100,000 requests/month. Using Bedrock’s consumption-based rate for custom models, this lands at approximately $15–$40/month depending on model copy overhead.
SageMaker endpoint with auto-scaling to zero: SageMaker Serverless Inference eliminates idle cost but introduces cold starts of 5–10 seconds, making it unsuitable for interactive workloads. Bedrock custom model import achieves the same idle-cost elimination without cold-start penalties, because Bedrock manages the fleet.
When SageMaker endpoint beats Bedrock custom hosting:
- Traffic is extremely high and predictable (>10B tokens/month for a 7B model)
- Model architecture is unsupported by Bedrock custom import (custom attention variants, non-standard tokenizers)
- Serving requirements demand features Bedrock does not expose (custom batching, token streaming with custom hooks, multi-LoRA switching at inference time)
- Latency SLA is below 50ms P95 — SageMaker with dedicated instances and Inferentia2 chips can undercut Bedrock’s managed overhead
4. SageMaker Savings Plans: Scope, Exclusions, and Bedrock Contrast
SageMaker Savings Plans are one of the most misunderstood cost instruments in AWS AI/ML. They offer up to 64% off on-demand SageMaker prices in exchange for a commitment to a consistent per-hour spend rate (1-year or 3-year terms).
What SageMaker Savings Plans Cover
- SageMaker Training jobs (all instance types)
- SageMaker Real-time Inference endpoints
- SageMaker Batch Transform jobs
- SageMaker Processing jobs
- SageMaker Studio notebook instances (kernel gateway apps)
- SageMaker Data Wrangler instances
- SageMaker On-Demand Notebooks
What SageMaker Savings Plans Do NOT Cover
| Service / Feature | Why Excluded |
|---|---|
| SageMaker JumpStart foundation model inference | Billed under a separate marketplace/license structure |
| Amazon Bedrock (any tier) | Separate service with separate billing product code |
| SageMaker Ground Truth labeling jobs | Excluded from SP coverage |
| SageMaker Feature Store offline storage | Storage billed separately |
| SageMaker Pipelines orchestration | Charged per execution step |
| AWS Inferentia/Trainium instances via EC2 | Must use EC2 Savings Plans or Reserved Instances instead |
Critical implication: Teams that commit to a SageMaker Savings Plan expecting to cover JumpStart inference workloads will find that JumpStart charges are ineligible. JumpStart model hosting runs on SageMaker infrastructure but the model license and infrastructure cost are bundled differently. Verify which line items appear as AmazonSageMaker vs proprietary JumpStart usage codes in CUR before sizing a Savings Plan commitment.
Bedrock Reserved Tier vs SageMaker Savings Plans
Bedrock’s equivalent of a Savings Plan is Provisioned Throughput with a term commitment. The comparison is structural:
| Dimension | SageMaker Savings Plans | Bedrock Provisioned Throughput |
|---|---|---|
| Commitment unit | $/hour spend rate | Model units (throughput capacity) |
| Minimum term | 1 year | 1 month |
| Discount vs on-demand | Up to 64% | 10–25% vs no-commitment PT |
| Applies to | All covered SM instance types | Specific model + region combination |
| Flexibility | Any covered SM workload | Locked to named model |
| Cost if unused | Full commitment still billed | Full capacity charge still billed |
SageMaker Savings Plans are more flexible across workload types. Bedrock Provisioned Throughput is model-specific and must be sized correctly at purchase time. Neither instrument helps the other service.
5. Model Evaluation Costs: Bedrock Evaluations vs SageMaker Clarify
Model evaluation is a recurring cost that teams often undercount. Both platforms offer evaluation tooling with different cost structures.
Bedrock Model Evaluation:
- Automated algorithmic metrics (accuracy, ROUGE, BERTScore, etc.): No additional charge beyond inference tokens consumed during evaluation
- LLM-as-judge evaluation: Charges inference tokens at the judge model’s on-demand rate (e.g., Claude Sonnet 4.6 at $3/$15 per million input/output tokens)
- Human evaluation (bring-your-own workforce): $0.21 per completed human task + inference cost for the evaluated outputs
- RAG evaluation: Judge model tokens billed at on-demand rates
Bedrock evaluation overhead: A 1,000-sample evaluation using LLM-as-judge with 2,000-token prompts and 500-token judge outputs costs approximately: (1,000 × 2,000 × $0.000003) + (1,000 × 500 × $0.000015) = $6.00 + $7.50 = $13.50 per evaluation run.
SageMaker Clarify for Foundation Models:
- Evaluation jobs run as SageMaker Processing jobs billed at standard Processing rates
- ml.m5.xlarge at $0.23/hour; a 1,000-sample evaluation job may run 2–4 hours = $0.46–$0.92 in compute
- Model inference during Clarify evaluation is a separate charge on whatever endpoint hosts the model
- Integration with MLflow adds experiment tracking overhead (no direct charge, but adds engineering time)
Practical comparison: Bedrock evaluation is simpler to set up and costs approximately $13–$20 per 1,000-sample run with LLM-as-judge, inclusive of all fees. SageMaker Clarify evaluation is cheaper in raw compute ($1–$2) but requires a running endpoint, incurring idle cost if the model is not otherwise deployed. For teams without a persistent SageMaker endpoint, Bedrock evaluation is materially cheaper end-to-end.
Billing quirk: Some Bedrock evaluation charges appear under the AmazonSageMaker product code in CUR, not AmazonBedrock. This creates cost attribution confusion; see Section 9 on CUR disambiguation.
6. Hybrid Architecture Patterns: SageMaker Training + Bedrock Inference
The most cost-effective enterprise architecture separates the training plane (SageMaker) from the inference plane (Bedrock). This pattern exploits SageMaker’s training tooling and Savings Plan coverage while Bedrock handles serverless, managed inference.
Pattern A: One-Shot Fine-Tune → Custom Model Import
S3 (training data) → SageMaker Training Job → S3 (model artifacts)
→ Bedrock Custom Model Import → Bedrock On-Demand Inference
Cost profile:
- Training: one-time cost, covered by SageMaker Savings Plan
- Import: free
- Inference: consumption-based, no idle cost
- Ideal for: Applications with bursty or unpredictable traffic and a stable fine-tuned model
Pattern B: Continuous Re-Training Loop
Production traffic → S3 logs → SageMaker Processing (data clean)
→ SageMaker Training (weekly fine-tune) → model registry
→ Bedrock Custom Model Import (replace prior version)
→ Bedrock On-Demand Inference
Cost profile:
- Weekly training runs: ~$10–$300 depending on model size and tuning depth
- SageMaker Processing for data prep: ~$1–$5/week for typical log volumes
- Bedrock inference: unchanged, consumption-based
- Ideal for: Production models that drift and need regular re-training without inference downtime
Pattern C: SageMaker for Experiments, Bedrock for Production
SageMaker Studio notebooks → experiment/evaluate → promote winners
→ Bedrock Provisioned Throughput (production) + On-Demand (overflow)
Cost profile:
- Studio: ephemeral kernel instances, shut down after each session
- Bedrock PT: committed capacity for known production volume
- Bedrock OD: overflow handling at standard rates
- Ideal for: Enterprise teams with predictable production load + active R&D
Total Cost Model (Pattern A, 12-Month Horizon, Llama 3.1 8B)
| Cost Item | Monthly | 12-Month |
|---|---|---|
| SageMaker Training (quarterly fine-tune, 5 hrs each) | $2.53 amortized | $30 |
| S3 model storage + staging | $0.50 | $6 |
| Bedrock custom model inference (500M tokens/month) | $180 | $2,160 |
| SageMaker Processing (data prep) | $5 | $60 |
| Total | ~$188/month | ~$2,256 |
Equivalent SageMaker-only architecture (dedicated ml.g5.2xlarge endpoint, 24/7):
| Cost Item | Monthly | 12-Month |
|---|---|---|
| ml.g5.2xlarge endpoint | $1,110 | $13,320 |
| Training (same schedule) | $2.53 | $30 |
| Total | ~$1,113/month | ~$13,350 |
12-month delta: $11,094 saved by using Bedrock for inference at 500M tokens/month. The crossover to SageMaker advantage requires approximately 15–20B tokens/month on this model size.
7. SageMaker Inference Recommender: Right-Sizing for SageMaker-Hosted Models
SageMaker Inference Recommender is a benchmarking service that runs managed load tests against a set of candidate instance types and returns ranked recommendations by cost, latency, and throughput. It applies only to SageMaker-hosted endpoints — it has no awareness of Bedrock.
How it works:
- You provide a model artifact, container image, and sample payload
- You specify a list of instance types to benchmark (e.g., ml.g5.2xlarge, ml.g5.4xlarge, ml.g5.12xlarge, ml.inf2.xlarge)
- Inference Recommender spins up each instance, runs a load test at configurable concurrency levels, and collects P50/P95/P99 latency, throughput (tokens/second), and cost-per-request metrics
- Results are ranked by cost efficiency for your target SLA
Cost of running Inference Recommender: You pay instance-hours for each tested configuration. Testing 5 instance types for 30 minutes each costs approximately $15–$40 depending on instance sizes selected. This is a one-time investment that can prevent months of over-provisioning.
When to run it:
- Before initial deployment of any new model to a SageMaker endpoint
- When a new GPU instance family launches (e.g., ml.g6e or ml.trn2 variants)
- After model quantization — INT8 or INT4 models may run optimally on different instance types than their FP16 equivalents
- When P95 latency or cost-per-request targets change
What it does not solve: Inference Recommender benchmarks do not account for cold-start behavior, autoscaling hysteresis, or multi-model endpoint packing efficiency. For models migrated to Bedrock, this tooling is irrelevant — Bedrock manages fleet sizing internally.
8. SageMaker Studio Hidden Costs
SageMaker Studio is the primary development environment for teams working on Bedrock-adjacent ML pipelines. It carries cost exposure that teams routinely underestimate.
Kernel Gateway Instance Costs
Every interactive notebook session in Studio spawns a Kernel Gateway application on an instance you select. Billing starts the moment the instance starts and continues until the app is explicitly shut down or the instance is terminated — closing the browser tab does not terminate the instance.
| Instance | vCPU | RAM | Price/hour |
|---|---|---|---|
| ml.t3.medium | 2 | 4 GB | $0.05 |
| ml.m5.large | 2 | 8 GB | $0.115 |
| ml.m5.4xlarge | 16 | 64 GB | $0.922 |
| ml.g5.2xlarge | 8 | 32 GB + 24 GB GPU | $1.515 |
| ml.p3.2xlarge | 8 | 61 GB + V100 | $3.06 |
Idle instance risk: A data scientist who opens a g5.2xlarge kernel, does 2 hours of work, and leaves it running over a weekend incurs 60+ hours × $1.515 = $90.90 before anyone notices. Across a 10-person ML team, this compounds rapidly.
AWS-provided mitigation: The StudioLifecycleConfig feature allows automatic shutdown of idle KernelGateway apps after a configurable period (minimum 60 minutes). This is not enabled by default. AWS published a reference implementation; teams should treat this as mandatory configuration on any Studio domain.
EFS Storage Costs
SageMaker Studio uses Amazon EFS for the user home directory — not S3. EFS Standard pricing is $0.30/GB-month vs S3 Standard at $0.023/GB-month. A 100 GB workspace directory costs $30/month in EFS vs $2.30 in S3. Teams accumulating training checkpoints, large datasets, or model artifacts in their Studio home directory pay 13× the equivalent S3 rate.
Mitigation: Enforce S3 for all artifacts above 1 GB. Use Studio’s data connections to S3 rather than local EFS paths for training data. EFS should hold only code, small configs, and conda environments.
Studio Costs Appearing in Bedrock Workstreams
Teams using Studio to write code that calls Bedrock APIs incur Studio charges even though the actual inference runs on Bedrock. A notebook running all day to orchestrate Bedrock evaluations, prompt experiments, or fine-tuning data prep will accumulate Studio instance hours that appear under AmazonSageMaker in billing — not AmazonBedrock. This creates attribution noise.
9. CUR Disambiguation: Building a Unified AI/ML Cost View
AWS bills Bedrock and SageMaker under separate product codes in the Cost and Usage Report. This creates fragmented visibility for teams using both services.
Product Codes
| Service | CUR product_code | Notes |
|---|---|---|
| Amazon Bedrock inference | AmazonBedrock |
All on-demand and batch inference |
| Bedrock Provisioned Throughput | AmazonBedrock |
PT charges appear here |
| Bedrock Custom Model Import inference | AmazonBedrock |
Consumption-based charges |
| Bedrock Model Evaluation | AmazonSageMaker |
Historical billing quirk; verify in your account |
| SageMaker Training | AmazonSageMaker |
All training job instance hours |
| SageMaker Inference Endpoints | AmazonSageMaker |
Real-time, serverless, async |
| SageMaker Studio | AmazonSageMaker |
Kernel gateway + EFS |
| SageMaker JumpStart (some models) | AmazonSageMaker or marketplace code |
Varies by model vendor agreement |
Key Usage Type Dimensions
In CUR 2.0, the line_item_usage_type column disambiguates within each product code:
USE1-Bedrock-InputTokens-Claude— Bedrock input tokens, Claude, us-east-1USE1-Bedrock-OutputTokens-Claude— Bedrock output tokens, ClaudeUSE1-SageMaker-Training:ml.g5.2xlarge— training instance hoursUSE1-SageMaker-Hosting:ml.g5.2xlarge— inference endpoint hoursUSE1-SageMaker-Notebook:ml.t3.medium— Studio kernel hours
Recommended CUR Query Pattern (Athena)
To build a unified AI/ML cost dashboard, create a view joining both product codes:
SELECT
line_item_usage_start_date,
CASE
WHEN product_product_name = 'Amazon Bedrock' THEN 'Bedrock'
WHEN product_product_name = 'Amazon SageMaker'
AND line_item_usage_type LIKE '%Training%' THEN 'SageMaker-Training'
WHEN product_product_name = 'Amazon SageMaker'
AND line_item_usage_type LIKE '%Hosting%' THEN 'SageMaker-Inference'
WHEN product_product_name = 'Amazon SageMaker'
AND line_item_usage_type LIKE '%Notebook%' THEN 'SageMaker-Studio'
ELSE 'SageMaker-Other'
END AS cost_category,
resource_tags_user_project,
SUM(line_item_unblended_cost) AS cost_usd
FROM cur_table
WHERE line_item_usage_start_date >= date_add('month', -1, current_date)
AND product_product_name IN ('Amazon Bedrock', 'Amazon SageMaker')
GROUP BY 1, 2, 3
ORDER BY 4 DESC;
2026 Update: Bedrock IAM Cost Allocation
As of April 2026, Bedrock supports cost allocation by IAM principal (user and role). This means teams can tag Bedrock requests by the IAM role used by each application, enabling cost attribution to specific microservices, teams, or projects without requiring application-level tagging. This narrows the attribution gap between Bedrock’s token-level billing and SageMaker’s resource-level billing.
10. Bedrock vs SageMaker for Embeddings
Embedding models power RAG pipelines, semantic search, and vector store population. The cost comparison between Bedrock-native embeddings and SageMaker-hosted embedding models affects RAG pipeline economics materially.
Bedrock: Titan Embeddings
Amazon Titan Embed Text v2.0 on Bedrock:
- Price: $0.02 per million tokens (input only — embeddings have no output tokens)
- Max input: 8,192 tokens
- Output: 1,024-dimensional vector
- Latency: typically 50–150ms per request
- No infrastructure: fully managed, pay-per-call
SageMaker: Hosted Embedding Model
Deploying an open-source embedding model (e.g., BGE-large, E5-large, or Cohere Embed) to a SageMaker endpoint:
- ml.g4dn.xlarge ($0.736/hour), capable of ~500 embedding requests/second
- 730 hours/month × $0.736 = $537/month regardless of usage
- At peak utilization (500 req/s × 730 hours = 1.3 billion requests/month): $0.00041/request
Cost Comparison at Scale
| Monthly Requests | Avg Tokens/Request | Bedrock Titan V2 | SageMaker ml.g4dn.xlarge |
|---|---|---|---|
| 1M | 512 tokens | $0.01 | $537 |
| 10M | 512 tokens | $0.10 | $537 |
| 100M | 512 tokens | $1.02 | $537 |
| 1B | 512 tokens | $10.24 | $537 |
| 10B | 512 tokens | $102.40 | $537 |
| 52B+ | 512 tokens | $531+ | $537 |
Crossover point: Bedrock Titan becomes more expensive than a dedicated SageMaker embedding endpoint at approximately 52 billion tokens per month — roughly 1.7 billion requests at 512 tokens each. Almost no single embedding workload reaches this threshold.
Latency consideration: SageMaker dedicated endpoints can achieve sub-10ms P50 latency for embedding models. Bedrock’s managed inference adds overhead; P50 is typically 50–100ms. For applications populating a vector store in batch (nightly document ingestion), latency is irrelevant. For real-time query embedding in interactive RAG, latency matters.
Model quality: Titan Embed v2.0 performs competitively on MTEB benchmarks for general-purpose retrieval. For domain-specific retrieval (legal, medical, financial), a fine-tuned open-source embedding model on SageMaker will typically outperform Titan. The cost of a SageMaker-hosted fine-tuned embedder is justified only when Titan’s retrieval quality measurably degrades downstream RAG accuracy.
11. Data Pipeline Costs: S3 + SageMaker Processing Before Bedrock Fine-Tuning
Bedrock fine-tuning (for supported models like Titan Text, Claude) requires training data in S3 in JSONL format. SageMaker Processing is commonly used to clean, deduplicate, and format raw data before submitting a Bedrock fine-tuning job.
Typical Data Pipeline
Raw data source (S3 raw bucket)
→ SageMaker Processing Job (clean, deduplicate, format to JSONL)
→ S3 fine-tuning bucket
→ Bedrock Fine-tuning Job
→ Bedrock fine-tuned model endpoint
Cost Breakdown by Stage
SageMaker Processing (ml.m5.xlarge at $0.23/hour):
- 10 GB dataset: typically 1–2 hours = $0.23–$0.46
- 100 GB dataset: 3–5 hours = $0.69–$1.15
- 1 TB dataset: 10–20 hours = $2.30–$4.60
S3 storage:
- Raw data (assume 3-month retention): 100 GB × $0.023 × 3 = $6.90
- Processed JSONL (typically 40% compression): 60 GB × $0.023 = $1.38/month
- Model artifacts post-fine-tuning: size varies; 7B in FP16 = 14 GB → $0.32/month
Data transfer:
- S3 within same region to SageMaker Processing: free
- S3 to Bedrock (same region): free
- Cross-region data prep (e.g., training data in us-west-2, Bedrock job in us-east-1): $0.02/GB → $2.00 per 100 GB
Bedrock fine-tuning job cost: Bedrock charges for fine-tuning based on the number of tokens processed. Rates vary by model; Amazon Titan Text Express fine-tuning runs approximately $0.006 per 1,000 tokens. A 100M-token training set costs $600 for the Bedrock fine-tuning job itself.
Full pipeline cost example (100 GB dataset, Titan Text fine-tuning):
| Item | Cost |
|---|---|
| SageMaker Processing (4 hours, ml.m5.xlarge) | $0.92 |
| S3 raw storage (3 months) | $6.90 |
| S3 processed storage (3 months) | $4.14 |
| Bedrock fine-tuning job (assumed 50M tokens) | $300 |
| Total one-time | ~$312 |
Data pipeline costs are typically less than 1% of the Bedrock fine-tuning job cost. Optimize the Bedrock fine-tuning budget first; processing and storage are noise by comparison.
12. Migration Economics: SageMaker LLM Endpoint → Bedrock
When a team has an established SageMaker endpoint hosting an LLM and considers migrating to Bedrock, the economics depend on current traffic volume, endpoint utilization rate, and operational overhead.
When Migration Pays Off
Scenario 1: Low-utilization SageMaker endpoint A dedicated ml.g5.2xlarge endpoint serving a 7B model at 20% average utilization (common in enterprises with irregular usage patterns) costs $1,110/month. At 20% utilization with average 500-token requests, monthly output is approximately 60–80M tokens. Equivalent Bedrock on-demand cost: $12–$16/month. Migration saves ~$1,094/month, payback period < 1 month.
Scenario 2: Moderate utilization SageMaker endpoint Same endpoint at 60% utilization (200M tokens/month). Bedrock on-demand equivalent: ~$40/month. Migration saves ~$1,070/month. Still compelling.
Scenario 3: High-utilization SageMaker endpoint ml.g5.48xlarge at 80%+ utilization serving a 70B model (8–10B tokens/month). Bedrock equivalent at $0.72/million tokens: $5,760–$7,200/month vs SageMaker at $11,772/month. Migration still saves money at this scale. Crossover to SageMaker advantage requires 15B+ tokens/month.
Migration Cost and Risk
One-time migration costs:
- Engineering time to rewrite inference calls: 1–4 weeks for teams with non-trivial SageMaker SDK integration
- Testing and validation: 1–2 weeks
- Parallel-running both environments during cutover: typically 2–4 weeks × SageMaker endpoint cost (~$2,220–$4,440 for a g5.2xlarge)
- Total migration investment: $5,000–$30,000 in engineering + AWS cost depending on model size and integration complexity
Architecture-specific constraints that prevent migration:
- Model architecture not supported by Bedrock Custom Model Import (custom attention, non-standard vocab)
- Multi-LoRA serving (switching adapters per-request) — Bedrock does not expose this
- Sub-50ms P95 latency requirements — Bedrock managed inference adds overhead
- On-premise or VPC-only deployment requirements
Break-Even Calculation
For a team migrating a moderately utilized ml.g5.2xlarge endpoint (200M tokens/month):
- Monthly savings: $1,070
- One-time migration cost: $15,000 (estimate: 4 weeks engineering + 3 weeks parallel running)
- Break-even: $15,000 / $1,070 = 14 months
For high-urgency idle-cost elimination (20% utilization scenario):
- Monthly savings: $1,094
- One-time cost: $10,000
- Break-even: ~9 months
Migration is financially justified in almost every scenario where the SageMaker endpoint serves fewer than 15B tokens/month. The primary barrier is engineering switching cost, not ongoing economics.
Summary Decision Matrix
| Decision Point | Bedrock | SageMaker | Hybrid |
|---|---|---|---|
| FMOps with zero infrastructure overhead | ✓ | — | — |
| Fine-tuning large models (70B+) | Limited | ✓ | — |
| Production inference, bursty traffic | ✓ | — | — |
| Production inference, 15B+ tokens/month | — | ✓ | — |
| Serverless inference, no idle cost | ✓ | Serverless only (cold start) | — |
| Training → inference separation | — | — | ✓ |
| Custom model architectures | — | ✓ | — |
| Savings Plan coverage of training | — | ✓ | — |
| LLM-as-judge evaluation | ✓ | — | — |
| Embedding at scale (<52B tokens/month) | ✓ | — | — |
| Sub-50ms embedding latency | — | ✓ | — |
| Unified CUR cost view | Tag both | Tag both | Required |
Sources Consulted
- Amazon Bedrock Pricing — AWS
- Amazon SageMaker AI Pricing — AWS
- Bedrock Custom Model Import docs — AWS
- Understanding Bedrock CUR data — AWS docs
- Bedrock IAM cost allocation (April 2026) — AWS
- Bedrock vs SageMaker — DEV Community
- AWS AI Cost Optimization: SageMaker vs Bedrock vs EC2 — Medium
- SageMaker Inference Recommender — AWS docs
- SageMaker Savings Plans — CloudZero
- LLM Fine-Tuning Cost Guide 2026 — AI Superior
- Titan Embed Text v2.0 cost — Future AGI
- Save costs by shutting down idle Studio resources — AWS ML Blog
- Bedrock custom model import for Salesforce — AWS ML Blog
- AmazonSageMaker CUR billing codes — Vantage