One line of Python creates a real-time endpoint. It also commits you to $1,027.84 a month.
huggingface_model.deploy(initial_instance_count=1, instance_type="ml.g5.xlarge")
Amazon SageMaker AI pricing spreads across roughly 25 independently metered components, and the one that surprises people runs whether or not anyone calls the model. If you are an ML engineer, platform engineer or FinOps practitioner staring at a SageMaker cost line you cannot explain, request volume is rarely the cause. What follows is the rule behind most SageMaker bills, three worked monthly totals, and the configuration that stops the leaks.
Every SageMaker rate comes from the AWS Price List offer file for AmazonSageMaker, version 20260915150721, retrieved 15 September 2026. Figures are us-east-1 and on-demand unless stated.
SageMaker AI bills you for uptime, not for inference requests
Yes, an idle endpoint still charges you. A real-time inference endpoint provisions ML instances the moment it reaches InService, and those instances run until you delete the endpoint or an autoscaling policy resizes it, including to zero under the narrow conditions covered later. Requests can move the instance count through a target-tracking policy on SageMakerVariantInvocationsPerInstance. They never become the billing unit: you pay instance-hours either way.
Here is the anchor number. One ml.g5.xlarge real-time endpoint in us-east-1 bills $1.4080 per instance-hour, so over a 730-hour month:
$1.4080 x 730 = $1,027.84 per month
That is compute only, before storage and data transfer, on an endpoint that served zero requests. SageMaker endpoint pricing behaves like a subscription you pay by the hour.
Studio works the same way. AWS publishes an exact list of what incurs cost in Studio, including "launching a JupyterLab application, even if no resources or jobs launched in the application". Closing a notebook tab is not shutting down the app, and the instance keeps metering behind that closed tab: "You must shut down the instance to stop incurring charges." Shutting down the app does stop the compute. What survives is the space's EBS volume, covered in the teardown section.
Request volume does move two meters. Endpoint data processed in and out bills at $0.016 per GB. Serverless inference bills by duration instead of uptime, the option where traffic and cost track each other most closely.
Which SageMaker pricing page governs your bill: SageMaker AI or Unified Studio?
Check which of AWS's two SageMaker pricing pages your bill reads from. On 3 December 2024 AWS renamed the original service to Amazon SageMaker AI and made Amazon SageMaker the umbrella platform. Each has its own pricing page.
The decision rule is short. Training jobs, real-time endpoints, notebook instances and Studio JupyterLab, Code Editor or RStudio sessions land on SageMaker AI meters. Unified Studio, SageMaker Catalog, Lakehouse and the Data Agent land on the next-generation meters.
SageMaker Unified Studio pricing is real, not free. Catalog bills $10 per 100,000 requests with 4,000 free per account each month, metadata storage is $0.40 per GB, compute units are $1.776 each, and Data Agent credits are $0.04 each.
The detail with teeth is the SKU prefix. Unified Studio notebooks meter as sc.m5.xlarge, not ml.m5.xlarge. Both cost $0.23 per hour at that size, so the rates give nothing away. They sit on different usage types, so a Cost Explorer filter written for ml. misses that spend entirely. For SageMaker AI the API and IaC namespace did not move: still sagemaker, still AWS::SageMaker::*. Unified Studio governance is a different surface, run by SageMaker Catalog on top of Amazon DataZone, so its domains and projects are AWS::DataZone::* resources. If your notebooks run in Unified Studio, estimate them with the SageMaker Unified Studio calculator instead.
What starts the clock on each Amazon SageMaker AI pricing meter
The most useful simplification in AWS SageMaker pricing is this: for a given instance type, the hourly rate is essentially identical across components. ml.m5.xlarge in us-east-1 is $0.23 per hour on JupyterLab, Code Editor, Studio Classic, RStudio, a notebook instance, a processing job, a training job, a real-time endpoint, an asynchronous endpoint or a batch transform job.
What changes is which meter it lands on, not the price. SageMaker instance pricing answers "what will this cost". The usage type answers "why is this line on my bill".
| Meter | Clock starts | Clock stops | Increment | Still billing after you stop |
|---|---|---|---|---|
Real-time (USE1-Host:) | Instances reach InService | DeleteEndpoint, or autoscaling scale-in | Instance-hour, by duration of use | EBS volume while scaled to zero, on types that get one. DeleteEndpoint takes it too |
Studio apps (USE1-Studio:) | Launching the app | Stopping the app | Instance-hour | Space EBS volume |
Notebook instances (USE1-Notebk:) | Instance creation | StopNotebookInstance | Instance-hour | ML storage, until deletion |
Training (USE1-Train:) | TrainingStartTime | TrainingEndTime, covering Downloading, Training, Uploading | Instance-hour; AWS's ML blog puts partial hours at per second | No, the volume goes with the job |
Processing (USE1-Processing:) | Job start | Job end | Instance-hour, by duration of use | No |
Batch transform (USE1-Tsform:) | Job start | Job end | Instance-hour | No storage or data charge |
Asynchronous (USE1-AsyncInf:) | Instance provisioned | Scale-in to zero, after a billable cooldown | Instance-hour | Disputed, see below |
Serverless (USE1-ServerlessInf:) | Request arrives | Request completes | By the millisecond, rate by memory tier | No, it scales to zero |
| Provisioned Concurrency | Configuring it | Removing it | Two meters: keep-warm per second regardless of traffic, plus inference duration per second | Yes, the keep-warm meter |
Storage (VolumeUsage.gp2, .gp3) | Volume creation | Deleting the owner | Per GB-month | Yes |
Endpoint data (USE1-Hst:Data-Bytes-In) | Request and response bytes | Request completes | Per GB | No |
Storage is where rate uniformity stops. Studio spaces are gp3 at $0.112 per GB-month. Training, hosting, notebook and HyperPod volumes are gp2 at $0.14, and processing volumes are cheaper at $0.10.
Only two data-transfer meters exist in the whole SageMaker Price List: endpoint data in and out, both $0.016 per GB, identical in us-east-1, eu-west-1 and ap-southeast-1. You will see $0.02 per GB in two worked examples on the SageMaker AI pricing page. Use $0.016, which is what the Price List, and therefore your bill, uses. Same for Studio storage, where one paragraph says both $0.1125 and $0.112. It is $0.112.
Be careful with increments. AWS documents per-second billing only for training and tuning, Data Wrangler jobs, and Model Customization reinforcement learning; elsewhere, only "based on the duration of use".
The rate card also hides this: not every instance type exists on every meter. ml.t3.medium has no Hosting SKU and ml.inf2.xlarge has no Training SKU, so a type you priced for one component can simply fail to launch on another. Check the type against the component before you plan around a rate.
What three real SageMaker workloads cost per month
Here is what those rates total for three setups you will recognise. All three assume us-east-1, on-demand, no Savings Plan, and a 730-hour month.
One Hugging Face model on an ml.g5.xlarge endpoint
A Hugging Face model deployed to a real-time endpoint with initial_instance_count=1 and instance_type="ml.g5.xlarge". No autoscaling policy exists, because the one-line deploy() call creates none.
| Line item | Rate | Arithmetic | Monthly |
|---|---|---|---|
| Endpoint compute, 24/7 | $1.4080 per instance-hour | 1.4080 x 730 | $1,027.84 |
| Endpoint data in and out, 100 GB | $0.016 per GB | 0.016 x 100 | $1.60 |
| S3 model artifact | Amazon S3 rates | Billed outside SageMaker | Not priced here |
| Total on SageMaker meters | $1,029.44 |
There is no EBS line because ml.g5.xlarge ships 250 GB of local NVMe. AWS attaches an endpoint volume to "all instance types that don't come with a SSD storage". On an EBS-only type such as ml.m5.xlarge, add 0.14 x VolumeSizeInGB. The 50 GB each way is my assumption, not an AWS figure. Two variants move the total more than any tuning will:
- A 10-hour weekday schedule.
1.4080 x 220 hours = $309.76 per month, 70% off. There is noStopEndpoint, and a conventional production variant floors at one instance, so this means deleting the endpoint each evening and recreating it from the sameEndpointConfigeach morning. - Scale to zero. Compute approaches zero while idle, but only if the endpoint hosts inference components, and only if you accept several minutes of provisioning during which invocations error.
Region moves the compute line, and not by one multiplier. The same ml.g5.xlarge endpoint costs 11.5% more in eu-west-1 and 40.0% more in ap-southeast-1, while endpoint data stays flat at $0.016 per GB in all three.
Swap in your own instance type, count and hours with the Amazon SageMaker AI Pricing Calculator. It covers the instance-hour portion, not the storage, data-transfer or S3 lines, so keep those on the side.
A multi-model experimentation account with nothing serving traffic
Three ml.m5.xlarge endpoints left over from model comparisons, one JupyterLab space somebody sized for GPU work, and a stopped notebook instance nobody deleted.
| Line item | Arithmetic | Monthly |
|---|---|---|
Three idle endpoints on ml.m5.xlarge | 3 x 0.2300 x 730 | $503.70 |
One JupyterLab app on ml.g4dn.xlarge | 0.7364 x 730 | $537.57 |
| Space EBS volume, 50 GB gp3 | 0.112 x 50 | $5.60 |
| Stopped notebook instance storage | 0.14 x your volume size | Your number |
| Total | $1,046.87 + $0.14/GB |
AWS documents ml.g4dn.xlarge as the default for GPU-based images on Studio Classic. A JupyterLab space runs whatever instance the space was created with, so the $537 line is a choice someone made once and forgot, not a silent default. Space volumes resize one way only: you can grow them from the 5 GB minimum, never shrink them. And StopNotebookInstance "preserves the ML storage volume", so compute stops and storage does not. Every line above served zero inference requests.
A recurring training and batch-transform pipeline
Endpoints bill for existing. Training bills for running, which changes the optimisation entirely.
SageMaker training pricing on ml.g5.2xlarge is $1.5150 per instance-hour. Three-hour jobs run twenty times a month, an illustrative cadence, give 3 x 20 = 60 instance-hours, so 60 x $1.5150 = $90.90. The training volume bills only while the job runs, so 100 GB across those 60 hours is 0.14 x 100 x (60 / 730) = $1.15. Distributed training multiplies exactly, using AWS's own formula BillableTimeInSeconds * InstanceCount, where BillableTimeInSeconds is the wall-clock time you are charged for.
Managed Spot Training needs a correction. In the Price List, the Spot SKU rate equals the on-demand training rate for the same instance. Savings arrive as fewer billable seconds instead, which AWS computes as (1 - (BillableTimeInSeconds / TrainingTimeInSeconds)) * 100, up to a documented 90%. AWS does not publish whether the training volume or S3 checkpoint traffic is discounted too.
Batch transform is $0.2300 per hour on ml.m5.xlarge, with no storage and no data-processing charge. Its parallelism is bounded by file count: one input file with ten instances leaves nine idle instances you still pay for. Say twenty one-hour scoring runs on a single instance, matching the training cadence: 20 x 0.2300 = $4.60. On those illustrative assumptions the whole pipeline totals $96.65 a month, under a tenth of the idle endpoint.
Savings Plans, briefly: up to 64%, over one or three years, flexible across instance family, size, Region and component. AWS names seven eligible components: Studio Notebook, On-Demand Notebook, Processing, Data Wrangler, Training, Real-Time Inference and Batch Transform. Serverless, asynchronous, HyperPod, Feature Store, MLflow, Canvas and Ground Truth are not on that list. Once your baseline is steady, read how to size a SageMaker Savings Plan commitment.
Real-time, serverless, or asynchronous: which is cheapest for your traffic?
That choice moves the number more than any optimisation above it. Real-time bills for uptime. Serverless bills for duration, by the millisecond, at a rate set by the memory tier, from $0.00002 per second at 1 GB to $0.00012 per second at 6 GB.
So here is the crossover. An ml.m5.xlarge endpoint running 24/7 costs 0.2300 x 730 = $167.90 per month. At the 2 GB serverless tier, that same $167.90 buys 167.90 / 0.00004 = 4,197,500 seconds of inference duration, roughly 1,166 compute-hours a month. Below that, serverless wins on SageMaker inference cost. Above it, the always-on endpoint does.
Treat that as a cost crossover and nothing more. A 2 GB serverless worker is not the same machine as an ml.m5.xlarge, and serverless carries hard limits: 1 GB to 6 GB memory only, no GPUs, no Multi-Model Endpoints, no VPC configuration, no data capture, no Model Monitor. Any one of those can decide this for you regardless of price.
Provisioned Concurrency is a third shape, and it bills on two meters rather than one. Keep-warm runs at $0.000005 per second per GB whether or not requests arrive, and inference duration bills separately at $0.0000117 per second per GB on top. Budget for both: the keep-warm rate alone understates an endpoint that is actually serving traffic. AWS's CDK documentation is blunt about the first meter: "Provisioned concurrency incurs charges even when the endpoint is not processing requests."
Asynchronous inference scales to zero too, but the scale-in cooldown is billable, and AWS's own example bills 2.5 hours for an endpoint used two hours a day. AWS's sources then disagree on storage. The Developer Guide says "you only pay when your endpoint is processing requests", while the AWS cost blog lists provisioned storage as a separate asynchronous charge. Until AWS reconciles them, budget for the volume.
The SageMaker AI pricing calculator prices instance-hour options, including real-time, asynchronous and batch transform. Serverless is not in it, which is why the crossover arithmetic sits here.
How much extra ml.g5.xlarge costs over the same EC2 instance
One comparison is left: the same silicon without SageMaker. Against the equivalent EC2 on-demand rates, the premium is tiered rather than uniform, running about 15% on p4d, p5 and trn1, about 20% on t3, m5 and c5, and 40% on g5.xlarge, g6.xlarge and g4dn.xlarge. This is the premium over EC2 in the same region, not the regional spread quoted earlier, which coincidentally also lands near 40%.
| Pair | SageMaker | EC2 | Formula | Premium |
|---|---|---|---|---|
ml.m5.xlarge / m5.xlarge | $0.2300 | $0.1920 | (0.2300 / 0.1920) - 1 | +19.8% |
ml.g5.xlarge / g5.xlarge | $1.4080 | $1.0060 | (1.4080 / 1.0060) - 1 | +40.0% |
ml.p5.48xlarge / p5.48xlarge | $63.2960 | $55.0400 | (63.2960 / 55.0400) - 1 | +15.0% |
AWS does not publish a SageMaker premium figure. These percentages divide two official rate cards published five days apart, on Linux shared-tenancy on-demand rates, and the formula is shown so you can check them.
A premium is not automatically waste. It buys the managed control plane, endpoint orchestration, autoscaling, the model registry and zero-downtime deploys. Whether you would build and operate that yourself is worth asking out loud at 40%.
One correction while you compare rates. In June 2025 AWS announced a price reduction of up to 45% on SageMaker AI instances, covering P4d, P4de, P5, P5e and P5en only. On-Demand pricing changed from 9 June, Savings Plans after 16 June. If you run g5, g6, m5, c5 or inf2, nothing changed for you.
Where SageMaker money leaks, and the configuration that stops it
Whatever premium you pay, you pay it on idle resources too. Five leaks account for most of the SageMaker bills I have looked at, each with the property that fixes it.
Studio apps that meter while nobody is typing
Studio Classic image defaults start meters quietly: ml.t3.medium for CPU images at $0.05 per hour, or $36.50 a month, and ml.g4dn.xlarge for GPU images at $0.7364 per hour, which is $537.57 a month if nobody stops it. JupyterLab and Code Editor spaces make you choose instead, which helps only if someone chooses down again.
Built-in idle shutdown fixes this, with one honest limitation. IdleTimeoutInMinutes has a valid range of 60 to 525600, so you cannot configure a window shorter than one hour of idle. That floor is quantifiable waste: an hour of idle GPU every time someone walks away. AWS makes the same point as a Well-Architected practice, MLCOST04-BP08, "Stop resources when not in use".
Set it per application type, since JupyterLab and Code Editor are configured independently, at domain or user-profile level. It needs SageMaker distribution image v2.0 or newer, so older domains need a lifecycle configuration instead. The two also define idle differently. JupyterLab is idle with no active kernel sessions and no active terminal sessions; Code Editor is idle with no file changes, no files being viewed and no terminal interaction. Either way it only applies with no jobs running, and changing the setting on a running app needs a restart to take effect.
Endpoints that never scale down
Scale-to-zero exists for real-time endpoints, conditionally. AWS is specific: "An endpoint can scale to and from zero instances only if it hosts inference components." An inference component is the unit that allocates CPU, accelerator and memory to a model on an endpoint. That precondition is what every "just use autoscaling" answer omits.
Set ManagedInstanceScaling.MinInstanceCount to 0 on the production variant, then register each inference component as a scalable target:
aws application-autoscaling register-scalable-target \
--service-namespace sagemaker \
--resource-id inference-component/my-inference-component \
--scalable-dimension sagemaker:inference-component:DesiredCopyCount \
--min-capacity 0 --max-capacity 4
Registering the target is not the whole job. Scale-in still needs a target-tracking policy on the inference component, and scale-out from zero needs a step scaling policy wired to a CloudWatch alarm on NoCapacityInvocationFailures. Use that metric, not ordinary invocations: at zero copies the requests fail before they count as successful invocations, so an invocation alarm never fires and the component stays stuck at zero.
Know the trade. After scaling in to zero, AWS warns that "your endpoint can't respond to any incoming inference requests until it provisions at least one instance", and "the provisioning process takes several minutes. During that time, any attempts to invoke the endpoint will produce an error." Application Auto Scaling scales out after a 1-minute alarm and in after a 15-minute one.
Storage that outlives the compute it was attached to
This is why teams are still charged for SageMaker after they think they turned it off. Teardown has three levels, and only the middle one does what people assume.
| Action | Compute stops? | Storage stops? |
|---|---|---|
| Shut down the notebook or kernel only | No | No |
| Stop the app | Yes | No, the EBS volume survives |
| Delete the space | Yes | Yes, the EBS volume goes |
| Delete the domain, default settings | Yes | No, EFS is retained by default |
That last row is the expensive one. DeleteDomain's RetentionPolicy.HomeEfsFileSystem defaults to Retain, so the EFS volume survives the domain and keeps billing:
aws sagemaker delete-domain \
--domain-id d-xxxxxxxxxxxx \
--retention-policy HomeEfsFileSystem=Delete
The accounting wrinkle makes it invisible: that orphaned volume bills under Amazon EFS, not under SageMaker, so a team auditing "our SageMaker bill" never sees it. These are volumes that outlive the instance they were attached to, one service over. To find existing orphans, look for the tag key ManagedByAmazonSageMakerResource on the EFS file system, carrying the domain ID as its value.
Finding SageMaker spend on the bill before it surprises you
Usage types follow REGION-UsageType:instanceType, as in USE1-Notebk:ml.g4dn.8xlarge. Endpoints are USE1-Host:, training is USE1-Train:, JupyterLab is USE1-Studio:JupyterLab-.
In Cost Explorer, filter Service to SageMaker, then group by usage type. To read hours rather than dollars, de-select every storage usage type first: VolumeUsage.gp2 and, if you run Studio spaces or Unified Studio notebooks, VolumeUsage.gp3 too. Leave any of them in and GB-months get summed with hours into a meaningless quantity.
Resources Studio creates after 30 November 2022 carry sagemaker:domain-arn automatically. The finer-grained sagemaker:user-profile-arn and sagemaker:space-arn tags depend on the creation context, so build the report on the domain tag and treat the other two as a bonus. Two traps go with them: SageMaker resources have a 50-tag limit, and propagated tags that exceed it make resource creation fail. Cost allocation tags also take 24 to 48 hours to become selectable in Cost Explorer.
This is the one piece of advice AWS backs formally: Well-Architected's ML Lens makes tagging and budgets a named practice, MLCOST04-BP12. Attribution turns the meters above into someone's problem rather than a line on a shared bill.
The meters that bill when nothing is running
These components charge with zero activity. Each monthly figure is rate x 730 hours.
| Resource | Rate, us-east-1 | Monthly at zero usage | The catch |
|---|---|---|---|
| RStudioServerPro Medium | $0.816/hr | $595.68 | Runs 24/7 while RStudio is enabled on the domain. Small is $0.00/hr |
| MLflow tracking server, Small | $0.60/hr | $438.00 | "Will incur costs until you delete or stop it" |
| Feature Store in-memory store | $0.233 per GB-hour, minimum 5 GiB | About $913 (0.233 x 5.37 x 730) | The only documented minimum charge in SageMaker |
| Canvas session | $1.90/hr | $1,387.00 | Billing stops at logout. Idle shutdown is a Lambda you build |
| Provisioned Concurrency, 1 GB | $0.000005/s | Bills continuously | Charged for duration times concurrency, traffic or not |
| Feature Store provisioned capacity | $0.00065/WCU-hr, $0.00013/RCU-hr | Bills continuously | "Billed whether utilized or not" |
Catch a $1,028/month endpoint before the pull request merges
Every leak above is fixable today. The cheaper fix is not creating it.
The surprise happens because instance_type="ml.g5.xlarge" is one short string inside one line, and it is a $1,027.84 a month commitment. I have watched that exact line get approved by reviewers who would have blocked a t3.large in a Terraform plan, because nothing in the diff carried a number.
Split the resources you review into two groups, because they fail differently. The ones that provision billable compute are AWS::SageMaker::Endpoint, plus NotebookInstance, App, ProcessingJob, Cluster, InferenceComponent and MlflowTrackingServer. An Endpoint names only an EndpointConfigName, so a matcher has to follow that reference into AWS::SageMaker::EndpointConfig and read ProductionVariants[*].InstanceType and ProductionVariants[*].InitialInstanceCount. The ones that provision billable storage are Space, which creates a persistent EBS volume, and Domain, which owns the EFS file system and the instance defaults its apps inherit. Neither starts an ML instance on its own, so flag them for the storage that outlives them, not as compute commitments. Terraform's equivalents are aws_sagemaker_endpoint and aws_sagemaker_endpoint_configuration, per the HashiCorp provider docs rather than an AWS source.
One misconception is worth correcting in review. AWS::SageMaker::Model and AWS::SageMaker::EndpointConfig cost nothing alone. A Model is a pointer, an EndpointConfig is a specification, and only Endpoint provisions instances. A diff adding an EndpointConfig with four ml.p4d.24xlarge looks alarming and bills nothing until an Endpoint references it.
Two defaults hide well. A ResourceSpec.InstanceType of system translates to ml.t3.medium for KernelGateway apps, so $36.50 a month per app appears from a value that reads as free. And domain-level DefaultSpaceSettings apply only to shared spaces, never private ones, so a sane default block is not a guardrail. CDK offers little help either: its README states there are no official L2 constructs for SageMaker, only the experimental @aws-cdk/aws-sagemaker-alpha package, so every instance type stays invisible unless somebody diffs the synthesized template.
This belongs in CI. A rule that reads the instance type out of an aws_sagemaker_endpoint_configuration or a CfnEndpointConfig and posts the monthly figure on the pull request turns an invisible commitment into a review comment. That is what CloudBurn does, and the case for shifting cost review into the pull request holds for every service.
Amazon SageMaker AI pricing questions, answered
A few questions come up every time.
Is Amazon SageMaker AI free on AWS?
What changed when AWS renamed SageMaker to SageMaker AI?
Does a SageMaker Savings Plan cover serverless or asynchronous inference?
Am I charged if a training job or a batch transform job fails?
Does SageMaker bill per second?
Start with the meter, not the total
Four things to carry away from this breakdown of Amazon SageMaker AI pricing:
- Your bill is uptime. Request volume barely moves the compute number on a real-time endpoint.
- One
ml.g5.xlargeendpoint left up is $1,027.84 a month in us-east-1, before storage and data. - Stopping an app is not deleting a space, and deleting a domain retains the EFS volume by default.
- Savings Plans cover training and real-time endpoints, not serverless, asynchronous or MLflow.
Put your own instance types and hours into the calculator below, then open Cost Explorer grouped by usage type and see what is running. If the baseline turns out steady, read how to size a SageMaker Savings Plan commitment. If you are still deciding whether to host models yourself, compare what the same workload costs on Amazon Bedrock.
CloudBurn
Put Your Own Instance Hours In
CloudBurn's free SageMaker AI pricing calculator covers Studio apps, notebook instances, processing, training, real-time inference, asynchronous inference and batch transform. No signup, official AWS rates by region.