# Amazon SageMaker Batch Transform Job

> Batch transform jobs bill per instance-second while a dataset is being scored and nothing afterward, making them the cost-safe alternative to keeping a real-time endpoint deployed for offline inference. ZopNight discovers transform jobs via the SageMaker jobs API on the 6-hour cycle and attributes per-job cost from Cost Explorer or CUR 2.0.

Source: https://zop.dev/integrations/aws/sagemaker-transform-job
Updated: 2026-08-19

---

A SageMaker batch transform job runs offline inference over datasets on provisioned instances, billed per instance-second. Batch inference at scale can rival training cost, especially with oversized instance selections.

## Inference without the standing meter

Batch transform is what inference costs when nothing stays deployed: the job provisions instances, scores the input dataset from S3, writes predictions back, and releases the compute, billing per instance-second for exactly the scoring window. Contrast with the real-time endpoint, which bills per instance-hour around the clock to answer requests that may never come. For workloads whose predictions are consumed in bulk (nightly scoring, backfills, model evaluation), the transform job is structurally the right meter, and the choice between the two is one of the larger recurring cost decisions in ML serving.

## Transform activity in the ledger

ZopNight discovers transform jobs through the SageMaker jobs API on the 6-hour cycle, with per-job cost attributed from Cost Explorer or CUR 2.0 and spend trends across runs. The trend view earns its keep here because batch inference scales with data: a scoring job whose input doubles bills double, with no configuration change to flag it. Recurring transform families whose per-run cost drifts upward are the early warning that either the dataset, the model, or the instance selection changed, and the per-job attribution says which family.

## Scoring runs that overpay

Instance overshoot leads: transform configurations inherit the training job's GPU instances for models that score comfortably on CPU. Concurrency mis-tuning follows: max payload and batch strategy settings that leave instances half-fed, stretching duration on a fleet priced per second. Full-dataset re-scoring where incremental scoring would do multiplies input volume by habit. And the quiet anti-pattern in reverse: a real-time endpoint kept deployed solely to serve what is actually nightly batch traffic, paying always-on rates for a transform job's workload.

## Run history and unit economics

The SageMaker console's Batch transform jobs view lists runs with durations and instance configurations. Dividing each run's cost by records scored gives a per-prediction price. That number makes instance choices and endpoint-versus-batch decisions comparable at a glance.