Fine-tuning on Bedrock, from first principles

What fine-tuning actually changes, Bedrock's four customization job types, and the three different bills you can end up with serving the result. Quiz and cue cards included.

Verified as of 2026-09-15. Full write-up: You probably don't need to fine-tune.

What fine-tuning actually changes

Fine-tuning is the one technique on this page that touches a model's weights. Prompting, retrieval and caching all leave the weights exactly as they were and change what the model sees or how fast it answers. Fine-tuning is different: you train further on top of a base model, and the resulting weights are what you're now serving. That's the entire reason it's expensive to get wrong. You're not adjusting an input, you're changing the thing itself.

Which is exactly why it should be the last thing you reach for, not the first.

The ladder, and the three reasons to climb it

Prompt, then RAG, then caching, then fine-tune, in that order, and only past whichever step actually stops solving the problem. Most teams reaching for fine-tuning are actually trying to fix one of three things that don't need it at all: the model doesn't know something (that's retrieval), the model is slow or expensive per call (that's caching, or a smaller model), or the model's tone drifts (that's usually a better system prompt).

The three reasons that genuinely do need it: a rigid structured output a prompt can't hold consistently at scale; cost or latency distillation, where a big model already proves the task and you want a small one doing it cheaply; and a narrow domain vocabulary or tone a few-shot prompt only approximates.

Bedrock's fork: one API, four jobs

Say yes, and Bedrock's CreateModelCustomizationJob API asks which of four jobs you actually want, via its customizationType parameter. Match the reason to the job, not the other way around:

Structured output → FINE_TUNING, supervised on your own labelled input/output pairs.
Cost or latency distillation → DISTILLATION. No training pairs to write: point Bedrock at a stronger teacher model and a weaker student, and it generates the synthetic set. GA May 2025, and AWS's own figures put distilled models at up to 500% faster and 75% cheaper than the teacher, under 2% accuracy loss on retrieval-style tasks.
Narrow domain tone → CONTINUED_PRE_TRAINING if you have unlabelled domain data to accumulate, or FINE_TUNING if you have labelled examples of the register you want.
A fourth job, REINFORCEMENT_FINE_TUNING, is Nova-only today: you supply a reward function instead of a fixed answer key, which is the most direct fit for structured output and tool-calling reliability specifically, since "did the tool call parse" is gradable programmatically.

Serving it forks again, into three different bills

Bedrock's own documentation is plain: "if you customized a model, you must purchase Provisioned Throughput to be able to use it." That's the universal default: reserved capacity, billed hourly, whether a request arrives or not. Priced today, Amazon Nova Micro and Nova Pro cost the same $60.50/hr per model unit with no commitment, despite Micro costing a fraction of Pro on demand, because you're renting a model unit, not a token budget.

Since 16 July 2025 a narrower on-demand exception exists: Custom Model Deployment, for specific Nova models (Lite, 2 Lite, Micro, Pro, all us-east-1) and Meta Llama 3.3 70B Instruct (us-west-2), priced at the base model's own token rate, but only if the underlying model was customised on or after that date (15 September 2025 for Llama). Everything else, every Titan customisation, every model customised before those dates, still has exactly one way to serve it.

A third path skips CreateModelCustomizationJob entirely: Custom Model Import, for weights you trained yourself outside Bedrock. Billed per Custom Model Unit-minute, currently $0.05718 in us-east-1, scaling to zero five minutes after the last invocation, with a real cold start (seconds to a couple of minutes) as the trade-off.

Full write-up

The complete pricing table, the worked cost maths (steady 24/7 traffic vs a genuinely bursty workload), and where the sourcing came from: You probably don't need to fine-tune.

Check your understanding

0 of 6 answered

1. Fine-tuning changes a model's weights. Which of these does NOT touch the weights at all?
2. A team has real invocation logs, no labelled training pairs, and wants a smaller, cheaper model that matches a bigger one on a narrow task. Which customizationType fits?
3. A team needs tool calls that reliably parse, and can grade 'did it parse' with code. Which job type is the most direct fit?
4. You customise Amazon Nova Pro on 1 July 2025, in us-east-1. Can you serve it via Custom Model Deployment, the on-demand path?
5. On Bedrock Provisioned Throughput, why does a fine-tuned Nova Micro cost the same $60.50/hr, no commitment, as a fine-tuned Nova Pro?
6. Traffic is bursty, roughly 4 hours a day. Which serving path is cheapest, assuming the model is eligible for all of them?

Cue cards

Try to answer before you open each one.

The ladder, before you fine-tune?

Prompt, then RAG, then caching. Fine-tune only past whichever step actually stops solving the problem.

Bedrock's four customizationType values?

FINE_TUNING, CONTINUED_PRE_TRAINING, DISTILLATION, REINFORCEMENT_FINE_TUNING.

Model Distillation's headline numbers?

AWS's own figures: up to 500% faster and 75% cheaper than the teacher, under 2% accuracy loss on retrieval-style tasks. GA May 2025.

What must you buy to serve almost any customised model?

Provisioned Throughput: reserved capacity, billed hourly, whether a request arrives or not.

What changed on 16 July 2025?

Custom Model Deployment GA’d for eligible Nova models (Llama 3.3 70B followed 15 September 2025): an on-demand serving path at the base model’s own token rate.

Provisioned Throughput, Nova family, no commitment?

$60.50/hr per model unit, identical across Micro, Lite, Pro and Canvas.

Custom Model Import's billing unit?

$0.05718 per Custom Model Unit-minute (us-east-1), scaling to zero five minutes after the last invocation.

How do you know a fine-tune actually worked?

It has to beat the best prompt on the base model, on a real evaluation, not a vibe check.

How this comes up in an interview

"When does fine-tuning actually make sense on Bedrock, and which of its four job types fits?"

Climb the ladder first: prompt, then RAG, then caching, then fine-tune, only past whichever step actually stops solving the problem. When it genuinely is the right call, Bedrock's CreateModelCustomizationJob API forks into four distinct jobs via its customizationType parameter: FINE_TUNING for your own labelled pairs, CONTINUED_PRE_TRAINING for unlabelled domain data, DISTILLATION when a teacher model can train a cheaper student with no labelled pairs needed, and REINFORCEMENT_FINE_TUNING, Nova-only, when you can grade success with a reward function instead of a fixed answer key. They are not flavours of the same thing, and picking the wrong one is a common interview tell.

"Do you need to buy Provisioned Throughput to serve a fine-tuned model on Bedrock, and what does it actually cost?"

For almost every customised model, yes: Provisioned Throughput is the universal default, reserved capacity billed hourly whether a request arrives or not. Priced today, Amazon Nova Micro and Nova Pro cost the same $60.50/hr per model unit with no commitment, despite Micro costing a fraction of Pro on demand, because you're renting a model unit, not a token budget. Since 16 July 2025 a narrow on-demand exception exists, Custom Model Deployment, for specific Nova and Llama models customised after that date, priced at the base model's own token rate. Everything else still has exactly one way to serve it.