# Amazon Bedrock Customization Job

> Bedrock customization jobs bill for what each run consumes: fine-tuning and continued pre-training meter the tokens processed, evaluation and batch inference meter the records and tokens they work through, and everything stops billing at completion. ZopNight discovers jobs via its Bedrock jobs provider on the 6-hour cycle and attributes cost per run.

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

---

A Bedrock customization job runs model fine-tuning, continued pre-training, evaluation, or batch inference, billed for the tokens or compute the job consumes. Large fine-tuning and batch inference jobs are significant one-time costs worth tracking per run.

## Transient work, token-denominated

Bedrock's job family shares one billing shape (consume, complete, stop) with meters denominated in the work itself rather than in instance time. Fine-tuning and continued pre-training bill by tokens processed across the training epochs, which makes dataset size times epoch count the cost formula, all payable before anyone knows whether the resulting model is good. Batch inference processes bulk prompt files at per-token rates below on-demand, the discount that rewards moving offline-tolerant workloads out of the request path. Evaluation jobs meter the inference they perform against test sets. Nothing lingers after completion except artifacts. Fine-tuning also leaves a custom model whose storage and serving begin their own meters.

## Run-level attribution for lumpy spend

ZopNight discovers these jobs through a dedicated Bedrock jobs provider on the 6-hour cycle, attributing per-job cost from Cost Explorer or CUR 2.0 into spend trend analysis. Job spend is lumpy by nature: a quiet month, then a continued pre-training run that dwarfs the quarter's inference. Per-run attribution keeps each lump explained and owned. Trends catch the systematic version: retraining cadences tightening, batch inference volumes growing, or evaluation suites re-running against every model release at full corpus size.

## One-time costs that repeat

The waste patterns are repetition without reflection: full fine-tuning re-runs after marginal dataset updates, where the delta never justified reprocessing every token; epoch counts copied from a tutorial rather than stopped at convergence; batch inference re-scoring entire corpora when only new records needed predictions; and evaluation configured exhaustively for models that fail fast on the first metric.

## Job history in the console

The Bedrock console lists customization, evaluation, and batch inference jobs with status, timing, and configuration. Reading per-run token counts against the outcome, model shipped or model rejected or predictions consumed, is the retrospective that makes the next run cheaper.