Skip to content
Course outline

Learn it

Practice

Interview ready

The AI Architect Roadmap

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.

In this guide, you'll learn to:

  • The ladder to climb before fine-tuning is the right call
  • Bedrock's four model customization job types and which reason maps to which one
  • The three serving paths for a customised model and what each one costs
  • How to tell whether a fine-tune was actually worth it
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

Step 1 of 4

1. Prompt

Try steering the base model with a better prompt first. Most tone and format problems live here, and it costs nothing to test.

Bedrock's fork: one API, four jobs

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.

Supervised, on your own labelled input/output pairs. The classic case: you have examples of exactly what the model should output for a given input, and you train on them directly. Best fit for a rigid structured output a prompt can't hold consistently at scale.

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 true, but it's not the whole story any more.

Architecture diagram: a Bedrock base model forks into native customisation, producing a customised model served three ways: Provisioned Throughput, Custom Model Deployment, or Custom Model Import.

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. Works for any customised model, any region Bedrock customisation supports.

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.

Six questions, no pass mark, unlimited attempts. This is a self-check, not a gate.

Check your understanding

0 of 6 answered

  1. 1. Fine-tuning changes a model's weights. Which of these does NOT touch the weights at all?

  2. 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. 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. 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. 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. 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 flip each one.

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.

"What's the difference between DISTILLATION and REINFORCEMENT_FINE_TUNING, and how would you pick between them?"

Both skip building a labelled dataset by hand, but for different reasons. DISTILLATION needs no training pairs at all: point Bedrock at a stronger teacher model and a weaker student, and it generates the synthetic training set from the teacher's own responses (GA May 2025; up to 500% faster and 75% cheaper than the teacher, under 2% accuracy loss on retrieval-style tasks). REINFORCEMENT_FINE_TUNING, Nova-only, skips a training set entirely: you supply a reward function instead, either a Bedrock model as judge or your own Lambda grading logic, and the job trains against that signal. Distillation is the direct route to cost or latency reduction; RFT is the direct route to structured output and tool-calling reliability, because you can grade "did the tool call parse" programmatically.

"You customised a Nova Pro model on 1 July 2025, in us-east-1. Can you serve it via Custom Model Deployment?"

No, and this is the eligibility trap interviewers like to set. Custom Model Deployment requires the underlying model to have been customised on or after 16 July 2025 for Nova (15 September 2025 for Llama 3.3 70B). A model customised even one day earlier, or a Titan customisation, or anything outside the eligible Nova/Llama models and their two regions, still has exactly one way to serve it: Provisioned Throughput.

"Traffic is bursty, not steady 24/7. Does that change which serving path you'd pick?"

It's the whole decision. Provisioned Throughput bills the same whether the model answers one request that day or ten thousand, because you're renting capacity, not metering usage, so it can't do bursty economics at all. Custom Model Deployment and Custom Model Import can, because both are metered like the base model: a bursty workload invoked 4 hours a day on Custom Model Import worked out to roughly $823/month in the full cost breakdown, against a comparable Provisioned Throughput commitment that bills the same flat rate regardless of how much of that capacity actually gets used.

"How do you actually know a fine-tune, distillation, or RFT run was worth what it costs to serve?"

With numbers, not confidence. Whichever job type and serving path, the customised model has to beat the best prompt on the base model on a real evaluation, the same way, every time it changes. Before committing to serve anything, you should be able to answer three questions: what does the best prompt on the base model score today, on the same eval; what does the customised model score; and what's the smallest sample size at which that gap is actually distinguishable from noise. Skip the third question and you don't actually know if the first two differ at all.