Amazon SageMaker pricing — every component, broken down (2026).

IHow SageMaker billing works — the shape before the numbers

Before any specific rate, understand the structure: SageMaker is pure usage-based pricing with no licence fee, billed per second of compute, with separate meters for each component. Get the shape right and the numbers slot in.

There is no flat subscription or seat fee for SageMaker. Every dollar you spend traces to a resource you turned on: an instance that ran, storage you held, a feature you invoked. Compute is billed per second with no minimum, which is what makes ephemeral training jobs cheap — you pay for exactly the seconds the cluster existed.

The bill decomposes into a handful of independent meters: (1) training-job compute — per instance-second while a job runs; (2) inference compute — the instances behind real-time/async endpoints, or per-inference compute for serverless, or per-job compute for batch transform; (3) notebook/Studio compute — the instances backing interactive work; (4) Feature Store — writes, reads, and storage; (5) Data Wrangler — processing-instance time; (6) Ground Truth — per labeled object; and (7) storage and data transfer — S3 for data and artifacts, plus any provisioned volumes.

Across almost every real account, compute dominates — training instance-seconds and always-on endpoint instance-hours are the big lines; the feature and storage meters are usually rounding error by comparison until you reach large scale. So the rest of this page weights toward compute: which instances, which endpoint mode, and how to cut both.

One caveat stated once and applied throughout: every dollar figure on this page is representative as of 2026. AWS pricing varies by region and changes over time, and GPU instance pricing in particular moves. Use these numbers to reason about the shape and relative magnitude of cost — then confirm exact current rates on the AWS SageMaker pricing page before you budget.

IIPricing by component

Here is each meter, what triggers it, and how to think about its size. The pattern to notice: the things that run continuously cost the most; the things that run transiently are cheap.

Read this as a checklist of everything that can appear on a SageMaker bill, roughly ordered from biggest typical impact to smallest.

• Training jobs — Billed per instance-second for every instance in the job, from launch to completion. Cost = (per-hour instance rate ÷ 3600) × seconds × instance count. A short job on a small GPU is a few dollars; a multi-day distributed job on many high-end GPUs is the largest single line a research team will see. Managed Spot training can cut this substantially in exchange for interruptibility.
• Real-time endpoints — Billed per instance-hour for as long as the endpoint exists, 24/7, regardless of whether requests arrive. This is the most expensive idle mode and the #1 source of surprise bills. Cost = per-hour instance rate × instance count × hours up. Auto-scaling adds instances under load (and cost).
• Serverless inference — Billed for the compute consumed per inference (memory-size × duration) plus the number of requests; scales to zero when idle, so you pay nothing between bursts. Cheaper than real-time for spiky or intermittent traffic; trade-off is occasional cold-start latency.
• Asynchronous inference — Billed per instance-time while the endpoint is processing the queue; can scale to zero between bursts. Suits large payloads and long-running inferences where you do not need a synchronous response.
• Batch transform — Billed per instance-second of the transient job that scores a dataset — no persistent endpoint, so nothing bills between runs. Usually the cheapest way to score a whole dataset offline (e.g., nightly).
• Studio / notebook compute — Billed per instance-hour for the compute backing your interactive notebooks and IDE apps while they are running. An idle-but-still-running notebook keeps billing — set auto-shutdown. (There is no charge for the SageMaker domain itself, only the compute apps inside it.)
• Feature Store — Billed for writes and reads to the online store plus storage in the offline store. Modest for most workloads; can grow with very high-throughput real-time feature serving.
• Data Wrangler — Billed per hour for the processing instance used during interactive data prep and for the processing job when you run a transformation flow at scale.
• Ground Truth (labeling) — Billed per labeled object, plus the human-workforce cost if you use a vendor workforce or Mechanical Turk. Automated/active-learning labeling reduces the count of objects that need human review.
• Storage & data transfer — S3 storage for datasets and model artifacts at standard S3 rates, plus any EBS volumes attached to instances, plus standard AWS data-transfer charges. Small relative to compute but non-zero at scale.

IIIInstance family & GPU cost table (representative 2026)

Because compute dominates the bill, the instance you pick is the lever. The table below gives representative on-demand SageMaker rates by instance class so you can reason about relative cost — a high-end GPU can be 50–100× the hourly rate of a small CPU instance.

These figures are representative as of 2026, in the rough mid-range across major US regions, for SageMaker on-demand usage. They are intended for relative reasoning, not budgeting to the cent. Real-time hosting, training, and notebook usage of the same instance type are billed at slightly different SageMaker rates; the magnitudes below are the right ballpark. Always confirm the exact, current, region-specific rate on the AWS SageMaker pricing page.

IVSageMaker Savings Plans & Spot — committing to cut the rate

If your SageMaker usage is steady and predictable, you are leaving money on the table paying pure on-demand. Two mechanisms cut the effective rate: Savings Plans (for steady usage) and Spot (for interruptible training).

SageMaker Savings Plans let you commit to a consistent amount of compute usage — measured in dollars per hour — for a one-year or three-year term, in exchange for a meaningful discount versus on-demand. The plan applies automatically across eligible SageMaker usage: Studio notebooks, training jobs, real-time inference, and processing. The longer the commitment and the more you pay up front, the deeper the discount. The trade-off is commitment risk: if your usage drops below the committed level, you still pay for the commitment, so size it to your reliable baseline, not your peak.

Spot instances for training are the other big lever. Managed Spot training runs your training jobs on spare AWS capacity at a steep discount versus on-demand, automatically checkpointing so an interrupted job resumes rather than restarting. For non-urgent training that can tolerate interruption and restart, this is one of the largest single savings available — often cutting training compute cost by more than half. It applies to training jobs, not to real-time endpoints (you do not want a production endpoint on interruptible capacity).

A practical combined strategy: put your steady baseline (notebooks, the always-on portion of inference) under a Savings Plan, run training on Spot where the schedule allows, and keep spiky or experimental work on serverless/on-demand so you are not committing to capacity you might not use. And if you are credit-funded, the credits stack on top — they apply to the post-discount usage just as they would to on-demand.

VTwo worked examples

Abstract rates only get you so far. Here are two concrete scenarios — training a model once, and hosting an endpoint around the clock — worked end to end with representative 2026 numbers so you can see how the bill actually assembles.

Both examples are illustrative and use the representative rates from section III. Your real numbers depend on region, instance choice, and current pricing — but the method (instance rate × time × count, plus the small meters) is exactly how you should estimate your own.

VICost-optimization levers, ranked

There is a fairly stable hierarchy of what actually moves a SageMaker bill. Work down this list in order — the top items dwarf the bottom ones.

In rough order of impact for a typical ML team:

• 1 · Kill idle real-time endpoints and notebooks — The highest-leverage and most-ignored lever. An always-on endpoint or an un-shut-down notebook bills 24/7. Auto-shutdown notebooks, delete test endpoints the moment an experiment ends, and audit for "zombie" endpoints monthly. This alone often cuts a wasteful bill by the largest single margin.
• 2 · Match the endpoint mode to the traffic — Serverless for spiky online, batch transform for offline scoring, async for large/slow inferences, real-time only for steady latency-sensitive traffic. As Example B shows, this can be a 10–20× difference for the same model.
• 3 · Use Spot for training — Managed Spot training cuts training compute substantially for interruptible jobs, with automatic checkpointing. For development and non-urgent training, this is close to free money.
• 4 · Right-size the instance — Do not train on an 8×H100 box what fits on a single A10G; do not host on a GPU what runs fine on CPU. Profile the workload and pick the smallest instance that meets the latency/throughput target.
• 5 · Consider AWS silicon (Trainium / Inferentia) — For large training or high-volume inference, Trainium (training) and Inferentia (inference) are positioned as cheaper per unit of work than equivalent NVIDIA GPUs, via the Neuron SDK. The migration cost is real but the per-job savings compound at scale.
• 6 · Buy a Savings Plan for the steady baseline — Once usage is predictable, commit your reliable baseline to a 1- or 3-year Savings Plan for a discounted rate. Size to baseline, not peak.
• 7 · Use auto-scaling on real-time endpoints — Where you must run real-time, configure auto-scaling so you run the minimum instances off-peak and add capacity only under load — rather than provisioning for peak 24/7.
• 8 · Fund it with AWS credits — The lever that takes the bill to $0 for eligible teams. Credits apply to all of the above usage; combined with right-sizing and Savings Plans, they stretch much further. Covered next.

VIIHow AWS credits fund SageMaker training & hosting

Every cost line on this page is credit-eligible. AWS credit programs apply to SageMaker compute, storage, and features exactly as they apply to the rest of AWS — which means a funded ML team can train and host on credits rather than cash.

AWS funds large credit pools through partner-incentive programs because it wants AI and ML workloads consolidated on AWS for the long term. The relevant pools for SageMaker work: Activate Portfolio (up to ~$100K for institutionally-funded startups, general AWS infrastructure), Bedrock / GenAI PoC funding ($10K–$50K for a defined generative-AI proof-of-concept), and the Generative AI Accelerator (up to $1M for selected AI-first companies). Credits auto-apply to your monthly AWS bill until exhausted — including the SageMaker lines.

The mechanic that makes this free to you: the credit pool is funded by AWS, the engagement is delivered by a vetted AWS partner (who AWS pays through separate partner-incentive programs), and CloudRoute is paid a routing commission by that partner. You — the customer — pay $0. There is no invoice from CloudRoute, no procurement cycle, and no cost passed to you; the structural incentives work without you in the payment loop.

In practice this means an ML team can run its experimentation budget (Example A, repeated dozens of times), stand up its training pipeline, and host its endpoints — all drawing down a credit balance rather than burning runway. And because credits stack on top of Savings Plans and Spot, disciplined cost management makes the credits last dramatically longer. CloudRoute routes you to a partner who both builds the SageMaker workload and files the credit application that funds it.

VIIIThe pricing mistakes that cost teams the most

Most SageMaker overspend traces to a short list of recurring mistakes. Knowing them up front is cheaper than learning them from a surprise invoice.

• Leaving a real-time endpoint running after an experiment — The classic. A test endpoint on a GPU instance left up for a month is ~$1,000 of pure waste. Delete endpoints the moment you are done; audit monthly.
• Defaulting to real-time when serverless or batch would do — Reaching for the always-on mode out of habit when the traffic is spiky or offline. Match the mode to the traffic shape (section IV / Example B).
• Training on a bigger GPU than the job needs — Provisioning an 8×H100 box for a job that fits on one A10G burns 30–50× the rate. Right-size first.
• Not using Spot for interruptible training — Paying full on-demand for development training runs that could tolerate interruption — leaving more than half the training cost on the table.
• Buying a Savings Plan sized to peak, not baseline — Over-committing means paying for capacity you do not use. Size the commitment to your reliable baseline and keep variable usage on-demand/serverless.
• Forgetting to shut down Studio notebooks — Idle notebook compute bills per hour. Enable auto-shutdown so a forgotten notebook does not run all weekend.
• Budgeting without checking current GPU rates — GPU pricing moves and varies by region. Estimating from a stale number — including the representative ones on this page — without confirming on the AWS pricing page leads to a budget that is off.