Model Customization on Amazon Bedrock - What Each Method Demands as Input, and What It Takes to Call the Model You Built

First Published: 2026-09-02
Last Updated: 2026-09-02

Sometimes, when developing in-house generative AI applications, teams encounter situations where, despite implementing retrieval-augmented generation (RAG), the accuracy remains insufficient. This often leads to the question of whether to intervene directly with the model itself.

The initial question posed is typically, "RAG or fine-tuning?" However, this question has the number of options wrong. Amazon Bedrock offers three distinct customization methods, and each method requires a different type of input. Supervised fine-tuning (SFT) requires labeled data. Reinforcement fine-tuning (RFT) requires a reward function. Distillation requires a teacher model.

Therefore, the real question is not "Should we fine-tune?" Instead, what you already have decides which methods are open to you. If you have labeled input-output pairs, SFT is an option. If you do not have labels but can mechanically evaluate "good" answers, RFT is a possibility. If you lack both but have access to a large, capable model, distillation might be the right choice.

What Each Customization Method Requires as Input

This article will examine what each of these three methods requires, drawing on primary sources, and will then discuss what to expect after you have made your selection. Even if you believe you have the necessary data, it may not be in the format required. Information baked into the weights can come back out in a response. The supported models and Regions are extremely narrow. The custom model you create may not be immediately callable. Without understanding these factors upfront, you risk preparing your data only to reach a dead end.

This article does not cover post-customization quality evaluation. Information on automated metrics, LLM-as-a-Judge, RAG evaluation, and quality gates within a CI/CD pipeline is held by the existing article Amazon Bedrock Model Evaluation Practical Guide. The discussion of whether your customization actually improved the results is addressed in that guide.

This article does not rewrite existing terminology. The definitions of terms such as "custom model," "fine-tuning," "distillation," and "continued pre-training" are already documented in the Amazon Bedrock Glossary. This article puts down a single line at first mention and moves on.

This article does not cover the design aspects related to provisioned throughput. Quotas, throttling, latency optimization, and prompt caching are all held by the existing article Amazon Bedrock Inference Throughput and Latency Optimization document. This article focuses solely on what is required to call a custom model; it does not discuss the design considerations for determining the necessary capacity.

It also does not cover the process of running training jobs on your own clusters outside of Bedrock. That topic is covered in Distributed Training Resilience on AWS (a subsequent volume in this series). Programming AWS Trainium with the Neuron Kernel Interface (also a subsequent volume) takes the discussion all the way down to the instruction level. This article focuses on defining the parameters you do not need to configure when operating within a managed environment.

It does not delve into quantization during training. The existing article LLM Weight Quantization on AWS document covers weight quantization, and that document itself explicitly states that quantization during training is outside its scope.

This article does not discuss pricing. It will not provide information on costs, unit prices, or total cost of ownership. The official explanation often connects to cost through the phrasing "you can move to a smaller model," but this article stops at pointing out the structure. It also does not compare models against one another.

The specifications presented in this article were verified against official AWS documentation as of September 1, 2026. The list of supported models and Regions is the most likely part of this article to change. Check them against the primary sources before you make a design decision.

1. The Question Is Not "RAG or Fine-Tuning"
2. What Each Method Demands as Input
3. Having the Data Is Not the Same as Having It in the Right Shape
4. What Happens to the Data You Hand Over
5. Writing a Reward Function
6. What Distillation Actually Requires
7. Two API Surfaces for the Same Technique
8. The Count Depends on Which Page You Open
9. Where You Can Actually Do This
10. Calling the Model You Built
11. A Walk Through the Decision
12. Failure Modes and Anti-Patterns
13. Frequently Asked Questions
14. Summary
15. References

1. The Question Is Not "RAG or Fine-Tuning"

There are practical reasons for framing the choice as either RAG or fine-tuning. Both approaches appear to serve the same goal: to tailor the model's responses to a specific domain.

However, within Bedrock, these two options do not represent choices at the same level. RAG is a mechanism for adding context during inference, without altering the model's weights. Customization, on the other hand, is a mechanism that changes the weights and adds nothing at inference time. The AWS Machine Learning blog, when describing the fine-tuning of Nova, explains this difference as follows:

Each technique embeds new knowledge directly into the model weights, rather than supplying it at inference time through prompts or retrieved context.

Crucially, there are three different approaches within the category of methods that modify the weights. This aspect is often overlooked when framing the choice as a binary decision. As long as the question stays binary, the decision becomes "do it or not." What you actually decide is "which one to do," and that answer comes from the materials on hand rather than from preference.

The history and evolution of RAG and prompting techniques are documented in the existing article RAG and Prompting Techniques History and Timeline. That article explicitly excludes techniques used during training, and this article represents one potential direction within that broader scope.

Put the question this way instead. What do you have on hand right now?

Do you have labeled input-output pairs available? In other words, can you provide sets that define a correct output for a given input?
Can you objectively evaluate the quality of the output, even if there is not a single correct answer? Can you determine if a test case is passed, or if the output conforms to a specific format, using code?
Or do you have nothing on hand, but access to a large model that already handles the same task well?

These three questions map directly onto the three methods. The sections below take them in order.

2. What Each Method Demands as Input

The Bedrock user guide, on the page that serves as the entry point for customization, lists three methods. The description of each one begins with what you provide. That is where this article starts.

2.1 Supervised Fine-Tuning Demands Labeled Pairs

Supervised fine-tuning is a method used to improve performance on specific tasks by providing labeled data. The user guide states:

Provide labeled data to train a model to improve performance on specific tasks. By providing a training dataset of labeled examples, the model learns to associate what types of outputs should be generated for certain types of inputs.

The essential requirement is a set of input data paired with their corresponding correct outputs. This should be placed in a file formatted as JSON Lines and stored on Amazon Simple Storage Service (Amazon S3).

Of the three methods, SFT has the simplest requirements. However, it also places the greatest burden on the user. This is because a human has to write the correct answers. The user guide mentions scenarios where RFT might be more appropriate, such as "when collecting high-quality labeled examples is too expensive or impractical," acknowledging this burden.

For Bedrock's customization jobs using SFT, the only hyperparameters available for Nova's understanding models are the number of epochs, the learning rate, and the learning rate warm-up steps. An item that selects which weights to update, such as the rank used in low-rank adaptation, does not appear on that page. For the same Nova understanding model, the default number of epochs is set to 2. The user guide notes that "larger datasets may require fewer epochs to converge, while smaller datasets may require more." It also states that while increasing the learning rate can accelerate convergence, it can also lead to instability during training, making it undesirable. The available items differ by model. Image generation and embedding models, for example, offer different options such as batch size and step count.

2.2 Reinforcement Fine-Tuning Demands a Scoring Function

Reinforcement fine-tuning does not provide labeled input-output pairs. Instead, it requires you to define a scoring function. The user guide states:

Instead of providing labeled input-output pairs, you define reward functions that evaluate response quality. The model learns iteratively by receiving feedback scores from these reward functions.

The learning process works as follows: for prompts in the training data, the model generates multiple responses. The reward function then scores those responses. Bedrock uses these scored prompt-response pairs to train the model using a policy-based learning method called Group Relative Policy Optimization (GRPO). This iterative process continues until the training data is exhausted or the user chooses to stop at any checkpoint.

The system requires two inputs: a set of prompts and an implementation of the scoring function. You do not need to provide correct answers. However, you must be able to express, in code, what constitutes a "good" response. This can be easier or more difficult than writing correct answers. It is easier in areas where correctness can be mechanically verified, such as mathematical solutions or the results of code execution. It is more difficult in areas like text quality, where defining correctness is subjective.

The training data can come from two sources: you can use a dataset of prompts that you upload yourself, or you can use existing Bedrock invocation logs. The latter option is beneficial if you are already running the model in a production environment.

Bedrock claims an average accuracy improvement of up to 66 percent with reinforcement fine-tuning. The user guide states:

Reinforcement fine-tuning improves model accuracy by up to 66% on average compared to base models.

AWS itself puts this figure forward; this article did not measure it. The same figure appears in the "What is New" section from December 2025. Results will vary depending on the specific task.

2.3 Distillation Demands a Teacher Model

Distillation is a technique for transferring knowledge from a large, powerful model (the teacher) to a smaller, faster model (the student). The primary requirement is access to the teacher model.

Users provide a collection of prompts tailored to their specific use case, but do not provide the correct answers. Bedrock sends these prompts to the teacher model, which generates responses. These responses are then used to fine-tune the student model. The user guide describes this process as an automated workflow. The generated responses are divided into training and validation sets, and only the training data is used to fine-tune the student model.

If available, labeled data can be optionally added. The user guide refers to this as "golden examples." They act as worked examples that instruct the teacher model to generate responses of comparable quality. They are not required.

2.4 The Request Schema Says the Same Thing

The discussion about "different inputs" is not about organizing the information as a narrative. The structure of the requests for the Bedrock API essentially states the same thing.

CreateModelCustomizationJob requires the trainingDataConfig field, which specifies the location of the training data. In addition, there is an optional field called customizationConfig. The API reference explicitly describes this as a union, meaning only one member can be specified.

CreateModelCustomizationJob
├── trainingDataConfig                              (Required: Yes)
└── customizationConfig                             (UNION)
    ├── rftConfig
    │   ├── graderConfig                            (UNION)
    │   └── hyperParameters
    └── distillationConfig
        └── teacherModelConfig                      (Required: Yes)

Here is how it reads: SFT stands up on trainingDataConfig alone. It requires no additional configuration. RFT requires that you add graderConfig on top of that. This is necessary to point to the implementation of the grading process. Distillation requires the addition of the teacherModelConfig field, and this field is mandatory. You cannot create a distillation job without specifying a teacher model.

Ultimately, the difference between the three methods lies in what needs to be added to the request. You cannot add what you do not have. That is why the materials on hand decide which methods are open to you.

3. Having the Data Is Not the Same as Having It in the Right Shape

Even if you choose SFT, simply "having labeled data" is not enough. Each model requires data in a specific format, and that format is not always just one option. This is a common oversight during the planning phase.

3.1 Three Shapes for the Same Labeled Pairs

The training data is in JSON Lines format, with each line representing a single record. The AWS Machine Learning blog explains that this format was chosen because "it allows for efficient streaming of large datasets and allows each line to be independently validated." If a single line is invalid JSON, the job will fail.

The issue lies in the content of the records. The user guide states that for text-to-text models, the format varies depending on whether the application is conversational or non-conversational. In reality, three different shapes turn up.

Non-conversational models use a flat format with two fields: prompt and completion. This format is suitable for applications that return a single output for a single input, such as summarization, translation, and question answering.

{"prompt": "What is the capital of France?", "completion": "The capital of France is Paris."}

Models using the Converse API format use a nested format with fields schemaVersion, system, and messages. The content field is an array, which contains a text element.

{
    "schemaVersion": "bedrock-conversation-2024",
    "system": [{ "text": "You are a digital assistant with a friendly personality" }],
    "messages": [
        { "role": "user", "content": [{ "text": "What is the capital of Mars?" }] },
        { "role": "assistant", "content": [{ "text": "Mars does not have a capital. Perhaps it will one day." }] }
    ]
}

Claude 3 Haiku uses yet another format, with the system field as a string and the content within messages also as a string.

{"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "what is AWS"},{"role": "assistant", "content": "it's Amazon Web Services."}]}

Line the three shapes up and the types of system and content do not agree. In the Converse format, both are arrays, while for Claude 3 Haiku, both are strings. Even with the same "labeled input-output pairs," you cannot determine the correct format until you decide which model you are using.

When testing and comparing multiple models, this difference translates into the number of conversion scripts required. You can only truly say that you "have the data" after you have decided on the target model and converted it to the appropriate format.

3.2 The System Prompt Is Part of the Training Data

Note that the system field is part of the training data. This is not merely a formatting element. The AWS Machine Learning blog, in an article explaining Nova's fine-tuning, specifically emphasizes this point.

Important: Note that the system prompt appears in the training data. It is important that the system prompt used for training match the system prompt used for inference, because the model learns the system prompt as context that triggers its fine-tuned behavior.

If the system prompt used during training does not match the system prompt used during inference, the model may not exhibit the behavior it learned through fine-tuning. This is because the model learns the system prompt as the context that elicits its fine-tuned behavior.

This has operational implications. If your application continuously improves the system prompt, those improvements could subtly degrade the performance of your custom model. The system prompt used for training should be managed in conjunction with your custom model.

3.3 Where the Record Limits Bite

Record and token limits exist. The values differ by model, and the user guide gives them in a per-model table.

Generally, many models have an upper limit of 10,000 records combined for training and validation, which can be increased through Service Quotas. Some models also have lower limits. Claude 3 Haiku requires a minimum of 32 records, while Meta Llama 3.1, 3.2, and 3.3 series require a minimum of 100 records combined for training and validation.

RFT has a separate limit. The "Important" section on the Nova page states:

You can provide a maximum of 20K prompts to Amazon Bedrock for reinforcement fine-tuning the model.

This limit is specified on the Nova page. The same description is not found on the pages for open-weight models. It is better not to read that limit as applying outside Nova.

Regarding token count estimates, the user guide provides an approximate value of roughly 6 characters per token, which can be used when planning the size of your dataset.

Amazon S3 URIs have to point at a file. If they point to directories, the job will fail. It is a small thing, and it is the kind of pitfall you hit on the very first attempt.

4. What Happens to the Data You Hand Over

Customization involves transferring your data to the model's weights. Where that data goes and where it remains is a question that will certainly be asked during the internal approval process. The official documentation is explicit about it, so it is worth having the answer ready.

4.1 The Training Data Is Not Kept, But the Model Remembers It

First, the training data itself is not retained. The user guide states the following:

None of the training or validation data you provide for fine tuning is stored by Amazon Bedrock, after the fine-tuning job completes.

The data will not be used for any other purpose. The fine-tuning data is used solely for fine-tuning the specific foundation model and is not used for training the base model or distribution to third parties, as clearly stated. A similar description applies to distillation, stating that only the user has access to the resulting distilled model, and the provided data will not be used to train other teacher or student models for public release. The RFT page highlights this characteristic as an advantage, stating that "your proprietary data remains within the AWS managed environment."

So far, this is reassuring. However, the same page carries a caution that runs the other way.

Note that fine-tuned models can replay some of the fine tuning data while generating completions. If your app should not expose fine tuning data in any form, then you should first filter out confidential data from your training data.

A fine-tuned model can replay part of the training data while it generates a response. Data not being stored and the model not remembering it are two different things. Customization, at its core, involves embedding data into the model's weights, and this process inevitably leads to this behavior.

This is the most practical difference between customization and RAG. With RAG, you can apply access controls to the source documents. You can control which users can reach which documents in the search layer. Once the information is baked into the weights, that option is gone. Anyone who can access the custom model effectively has indirect access to everything contained within those weights.

As a measure, the recommended approach is to exclude confidential information from the training data in advance. The user guide also spells out what to do if you have already built a custom model that contains confidential data. This involves deleting the custom model, removing the confidential information from the training data, and then rebuilding the model from scratch. It is a process of rebuilding, not simply correcting.

Filtering confidential information therefore belongs inside the step that shapes the training data. As mentioned in the previous section, regardless, the data will need to be transformed to match the target model; it is therefore practical to incorporate the exclusion process within that transformation.

4.2 What You Configure, and What You Do Not

The aspects you decide regarding a customization job are surprisingly limited.

You define the service role. This role, which Amazon Bedrock assumes to execute the job, requires permissions to read training and validation data from Amazon S3 and write output data. You grant this permission to Bedrock's service principal through the trust policy.

Encryption is optional, but enabled by default. Bedrock automatically encrypts custom models using AWS-owned keys. In this case, you do not need to take any action, but you will not have the ability to view, manage, or audit the keys. If you choose a customer-managed key, you will be responsible for managing it.

VPC configuration is optional. The user guide explains that the job accesses input data from an Amazon S3 bucket and writes job metrics, and recommends using a VPC to control data access. It goes on to suggest configuring the VPC so the data is not reachable over the internet, and creating an interface endpoint with AWS PrivateLink for a private connection. It is a recommendation, not a requirement.

And there is a great deal you do not have to decide. How many instances to use. How to distribute the training. Where to resume from when a compute node fails partway through. Where to put the checkpoints. None of them ever come up. You only provide the customization job with the location of the data, a few hyperparameters, and the necessary permissions.

This is the meaning of being within a managed layer. Bedrock increases the number of things you do not need to decide while simultaneously reducing the number of things you can decide. The models you can choose, the Regions available, and the range of weights you can update all stay inside the boundaries Bedrock has set. Outside that boundary, which is to say on your own cluster, every one of the items just listed as something you do not have to decide becomes part of your design. That topic is covered in Distributed Training Resilience on AWS.

Regarding the overall IAM conditions for Bedrock, the design of Service Control Policies, PrivateLink configuration, and model call auditing, the existing article Amazon Bedrock Security and Governance provides that information. This article focuses solely on the destination of data specific to customization jobs.

5. Writing a Reward Function

Of the three options, the one that is most difficult to implement is RFT. When told to "write a reward function," it is unclear what exactly should be included. It is worth making this concrete.

5.1 Two Paths in the Console, One Path in the API

The Bedrock console offers two distinct approaches for creating reward functions. The Nova section describes these two options under the heading "Reinforcement Learning."

The first is Reinforcement Learning through Verifiable Rewards (RLVR), designed for tasks where the correctness of the answer can be mechanically verified, such as code generation or mathematical reasoning. This involves creating rule-based graders. The console provides tools for verifying mathematical reasoning, checking formatting and constraints, and offers a generic grader template. You can also specify the Amazon Resource Name (ARN) of your own AWS Lambda function.

The second is Reinforcement Learning through AI Feedback (RLAIF), intended for subjective tasks like instruction following or chatbot responses. This approach uses a foundation model hosted on Bedrock as a judge, allowing you to define evaluation criteria and scoring guidelines. The console provides four prompt templates: instruction following, summarization, reasoning, and RAG fidelity.

At first glance, it appears there are two separate paths. However, they ultimately converge. The user guide notes this:

The console's Model as Judge option automatically converts your configuration into a Lambda function during training.

Once you reach the API, only one path remains. While the RFTConfig's graderConfig is a union, the API reference lists only one member: lambdaGrader.

Therefore, ultimately, "writing a reward function" means preparing a single Lambda function. Even if you choose the "Model as Judge" path, the console converts your configuration into a Lambda function. Understanding this point simplifies permission and timeout design, as these settings are consistent regardless of the chosen path. The logs that appear in CloudWatch will also be uniform.

The open-weight models are even simpler, with no equivalent branching in the console. The open-weight reward function page only mentions Lambda functions, and states that for subjective tasks, you call a foundation model on Bedrock as a judge from within that Lambda function.

Subjective tasks – For subjective tasks like instruction following or chatbot interactions, call Amazon Bedrock foundation models as judges within your Lambda function to evaluate response quality based on your criteria.

In other words, only the Nova path lets you pick model-as-a-judge natively. With open-weight models, you must call them directly. Even though it shares the name "RFT," this functionality is not the same. The selection of the model used for judging, the management of prompts, and the handling of potential failures when calling the model – all of this is contained within your own Lambda function.

5.2 What the Function Receives and Returns

The input and output format of the Lambda function are specifically outlined in the user guide. The function receives an array and returns an array. Records arrive in a batch rather than one at a time, which matters for how you write it.

The function receives an identifier, a sequence of conversation messages, and metadata. The metadata can include a reference answer. This allows you to pre-populate correct answers in the training data and compare them during scoring.

The function returns an identifier, an aggregated reward score, and a list of optional metrics.

[{
  "id": "123",
  "aggregate_reward_score": 0.85,
  "metrics_list": [
    { "name": "accuracy", "value": 0.9, "type": "Reward" },
    { "name": "policy_compliance", "value": 0.8, "type": "Metric" }
  ]
}]

Each element in the metrics_list carries a type, which distinguishes Reward from Metric. That is, you can separate the metrics that drive learning from the ones you only want to observe. This design enables you to select a subset of these metrics to incorporate into the training process while visualizing the overall scoring breakdown.

Three guiding principles are highlighted in the design. First, the system should clearly assign high scores to the best answers. Second, it should consistently evaluate answers based on factors such as task completion, adherence to format, safety, and appropriate length. Finally, the scores should be normalized and kept non-exploitable. The last principle addresses the potential for the model to exploit scoring loopholes and focus solely on achieving high scores.

5.3 The Reward Function Runs Thousands of Times

The reward function is called again and again for the whole length of the training run. The user guide sets out what it asks of this function. Finish in seconds rather than minutes. Minimize calls to external APIs. Use efficient algorithms. Implement proper error handling. And take advantage of Lambda's parallel scaling.

Implementation notes are also provided. Lambda's default timeout is 3 seconds, so if performing complex evaluations, it may be necessary to increase this to a maximum of 15 minutes. The execution role requires permissions to call models via the Nova pathway.

These two are in tension. Allowing a timeout of up to 15 minutes does not mean that is the acceptable limit. If individual evaluations take a long time, the entire training process will be slowed down. This is particularly true with the RLAIF pathway, where the evaluation itself involves calling a model, and this can potentially dominate the overall training time.

Error handling is also crucial, given the large number of iterations. How you write the function decides whether one scoring call raising an exception stops the whole training run or merely drops that record.

5.4 When the Reward Signal Tells You to Stop

The best practices for RFT contain a passage that backs up the point that the three methods are not parallel options.

If rewards are consistently 0 percent, use supervised fine-tuning first to establish basic capabilities. If rewards are greater than 95 percent, reinforcement fine-tuning might be unnecessary.

If the model consistently receives a reward of zero, it has not yet demonstrated a basic understanding of the task. The official instruction is to build the basic capability with SFT first. Conversely, if the reward consistently exceeds 95 percent, reinforcement fine-tuning may not be necessary. The procedure this instruction presupposes is that you measure the raw performance of the base model before you run RFT.

There are also instructions on how to begin. Start with 100 to 200 samples, verify that the reward function is working correctly, and then expand from there. The first thing to verify is not the model but the reward function.

The key metrics to monitor include the average reward score and its distribution, as well as any signs of overfitting. Overfitting occurs when the reward increases during training but decreases during validation. Other potential issues to watch for include the reward consistently falling below 0.15 and remaining stagnant, an increasing variance in the reward over time, and a decline in validation performance.

The text also outlines steps to take when the reward does not improve. These include re-evaluating the design of the reward function, increasing the diversity of the dataset, adding more representative examples, and verifying that the reward signal is clear and consistent. All four are about the data and the scoring, not about settings on the model.

6. What Distillation Actually Requires

Distillation might appear to be simply a matter of needing a "teacher model," but in reality, the constraints are two-layered.

6.1 The Teacher and the Student Must Come from the Same Provider

The student model cannot be chosen arbitrarily. The user guide states the following condition:

The student model must be one of the student models paired with your teacher model in the supported models table.

When you open the supported models table, you can see that the pairings are closed within a single provider. An Amazon teacher model can only be paired with an Amazon student model, and a Meta teacher model can only be paired with a Meta student model. Cross-provider distillation is not possible. The concept of distilling from a larger Model A to a smaller Model B is not supported here.

There are also guidelines for selecting the teacher model. It recommends choosing a model that is significantly larger and more capable than the student model, and choosing one that has already been trained on tasks close to your own use case. The student model must be significantly smaller than the teacher model.

However, there is one particularly easy-to-overlook restriction, located on the same page under "Important." It states:

Distillation is not currently available for Anthropic models on Amazon Bedrock. There is no confirmed timeline for when Anthropic distillation will be restored.

This is crucial. In May 2025, when Model Distillation became generally available, a "What is New" announcement included Claude 3.5 Sonnet v2 as a supported model. However, this has since been rolled back, and Anthropic models are no longer listed in the current compatibility table. Reading only past announcements can lead to the misunderstanding that it is still available.

Furthermore, on the same page, under "Note," there is a statement that reads: "Distillation jobs for Claude and Llama models are executed in the US West (Oregon) Region." Despite Claude being removed from the table, it remains listed in the note. The compatibility table and the "Important" section should be considered the definitive source of information.

The pairings between teacher and student models, as well as the supported Regions, are subject to change. This article does not reproduce the compatibility table. Open the prerequisites page for distillation at the point you need it. A table copied into an article starts going out of date the moment it is published.

6.2 The Path Where the Teacher Is Not Called Again

There is a path in distillation where the teacher model is not called again. Specifying the teacher model stays mandatory, since teacherModelConfig is a required field, but no inference call is made to that model.

There are two ways to create training data. One is to manually provide prompts, in which case Bedrock sends those prompts to the teacher model to generate responses. The other is the path that uses invocation logs. If you have enabled invocation log recording to Amazon CloudWatch Logs, you can use past responses from the teacher model, stored in Amazon S3, directly as training data.

When using invocation logs, there are two further options. If you only use the prompts from the logs, Bedrock will re-call the teacher model to generate responses. If you use the prompt-response pairs, Bedrock does not call the teacher model again. The user guide states:

If you choose to have Amazon Bedrock use prompt-response pairs from the invocation logs, then Amazon Bedrock won't re-generate responses from the teacher model and use the responses from the invocation log to fine-tune the student model.

This path has a condition. The teacher model specified in the distillation job must match the model used for the invocations recorded in the logs. If there is a mismatch, those logs will not be used.

The practical implications are significant. If you are already running a large model in production and have invocation logs available, that production traffic becomes the training data for distillation as it stands. By including requestMetadata during invocations, you can then filter the logs on the distillation job side, allowing you to select logs based on specific use cases. It can be a reasonable decision to turn on invocation logging and metadata attachment now, in anticipation of a distillation you have not yet committed to.

6.3 What the Synthesis Step Adds

Bedrock may apply its own data synthesis techniques during distillation. The user guide describes these as a way to raise the quality of the responses. One example it gives is generating similar prompts to draw a more diverse set of responses out of the teacher model. When labeled data is supplied as golden examples, the technique is used to instruct the teacher model to generate responses of comparable quality.

This process has two potential side effects. First, the dataset used for fine-tuning may increase beyond the number of inputs you initially provided. The user guide states that it can grow to a maximum of 15,000 prompt-response pairs. Second, additional inference calls are made against the teacher model. The user guide records this as a billing note; since this article does not cover pricing, the point to take away is simply that the teacher model can be called more often than you expect.

7. Two API Surfaces for the Same Technique

RFT has a single name, but offers two different entry points. If you choose the wrong one, the code you have written may simply not function.

Nova models utilize a path that integrates with Bedrock's native infrastructure. This involves storing training data on Amazon S3 and creating a customization job through the console, AWS Command Line Interface, or AWS SDK.

Open-weight models, on the other hand, use an API compatible with OpenAI. Bedrock provides a dedicated endpoint for this purpose, and the user guide details the following support:

Provider	Model	model ID	Region	Endpoint
OpenAI	gpt-oss-20B	`openai.gpt-oss-20b`	`us-west-2`	`bedrock-mantle.us-west-2.api.aws`
Qwen	Qwen3 32B	`qwen.qwen3-32b`	`us-west-2`	`bedrock-mantle.us-west-2.api.aws`

This path utilizes the Files API for uploading training files and the fine-tuning job API for creating jobs. The user guide highlights the ability to directly use existing OpenAI SDK codebases, referring to it as "Easy migration." When uploading data, the value fine-tune should be specified to indicate the purpose.

The differences are not limited to the entry point. A key feature of this path is the ability to extract checkpoints during training. This allows you to evaluate and debug the model at various stages, selecting the best performing version. While the Nova documentation mentions the ability to stop jobs at any checkpoint, only the open-weight side explicitly lists retrieving a list of checkpoints as an API feature.

The exit differs as well, and that is handled in a later section.

These two approaches also correlate with differences in how reward functions are configured. With Nova, you can select a "model-as-a-judge" through the console, while with open-weight models, you call it directly from within a Lambda function. The design notes that collectively refer to "Bedrock's RFT" actually diverge in these two locations.

8. The Count Depends on Which Page You Open

This article has said "three methods" up to this point. That number changes depending on which page of the official documentation you open. The measurements below are recorded so that the mismatch does not confuse a reader who goes and checks.

Resource	Count	Listed Methods
Customization entry page in the user guide	3	Supervised fine-tuning, reinforcement fine-tuning, distillation
`CreateModelCustomizationJob`'s `customizationType`	3	Fine-tuning, continued pre-training, distillation
Console help panel	4	Distillation, fine-tuning, continued pre-training, reinforcement fine-tuning

There are two discrepancies.

The first concerns how RFT is handled. The valid values for customizationType are listed as follows:

FINE_TUNING | CONTINUED_PRE_TRAINING | DISTILLATION

RFT is not listed here. However, the customizationConfig union includes rftConfig. Therefore, RFT is represented as a "configuration" rather than an "enumeration" of types. Counting only the enumeration values will exclude RFT.

The second concerns how continued pre-training is handled. This method involves teaching the model new knowledge by using unlabeled data. It remains listed in both the console help panel and the API's valid values. However, the customization entry page in the user guide does not list it. When you attempt to access a dedicated explanation page, you are redirected to the Amazon Bedrock overview page.

So when you say "Bedrock customization has three options," understand that the count comes from the customization entry page in the user guide. This article also takes that perspective. If you are considering continued pre-training, it is advisable to confirm its current status with AWS support, taking into account that it is accepted as a valid value in the API.

Furthermore, the documentation carries other leftovers. A section for Cohere Command remains on the hyperparameter page, but Cohere is not listed in the table of supported models for fine-tuning. The console help panel states that "executing inference with a custom model requires purchasing Provisioned Throughput," but this information is currently inaccurate (as discussed later).

The practical lesson is not to rely on a single page. Four of the official pages opened while writing this article redirected to the Amazon Bedrock overview page. Even if a page is removed, the descriptions that pointed to that page may remain on other pages.

9. Where You Can Actually Do This

The supported models and Regions are the aspects most likely to change and, furthermore, the first things you should verify. It is the most costly mistake to prepare your data only to discover later that a particular model is not supported.

9.1 Reinforcement Fine-Tuning Has the Narrowest Surface

As of September 1, 2026, only three models are currently supported for Reinforcement Fine-Tuning (RFT). Furthermore, the supported Regions are fixed.

Provider	Model	model ID	Region
Amazon	Nova 2 Lite	`amazon.nova-2-lite-v1:0:256k`	`us-east-1`
OpenAI	gpt-oss-20B	`openai.gpt-oss-20b`	`us-west-2`
Qwen	Qwen3 32B	`qwen.qwen3-32b`	`us-west-2`

Simply noting the model ID is not sufficient to utilize these models. Nova 2 Lite can only be used to create customization jobs in the US East (N. Virginia) Region, while the remaining two models are only available in the US West (Oregon) Region. If you wish to test RFT with two or more models, you will inevitably need to operate across different Regions. Both the Amazon S3 bucket for storing training data and the Lambda function for the reward function will need to be configured within each respective Region.

This limited scope is subject to change. The "What is New" update from December 2025 mentioned only Nova 2 Lite, but indicated that additional models would be added soon. The two open-weight models were added in February 2026. Therefore, the table presented in this article may already be outdated by the time you are reading it. The place to check is the reinforcement fine-tuning page in the user guide.

9.2 Fine-Tuning and Distillation Are Wider, But Not Wide

SFT-compatible models are more numerous than RFT models, with companies like Amazon, Anthropic, and Meta all included. The scope extends beyond text models to encompass image generation and embedding models as well. However, the Regions supported are effectively divided into two. Amazon's models are based in the US East (N. Virginia), while Anthropic and Meta's models are based in the US West (Oregon).

Distillation follows the same regional division. Amazon's teacher-student model pairs are located in the US East (N. Virginia), while Meta's pairs are in the US West (Oregon).

One important note: the list of SFT-compatible models includes only Anthropic's Claude 3 Haiku, and this model is not part of their current generation. Anthropic's current generation includes the Claude 4.5 series and the Claude 5 series. Regarding distillation, as mentioned earlier, Anthropic itself is not currently supported. As of September 1, 2026, there is no pathway to utilize Anthropic's current generation models through Bedrock customization. If you are considering customization with the current generation of Claude models, you will need to revise your plans accordingly.

The generation and availability of each model are held by the existing articles Amazon Bedrock Model Catalog 2026, Amazon Nova Model Release Timeline, and Open-Weights LLM Release History and Timeline. This article only examines whether a model is eligible for customization and does not provide model introductions.

What Bedrock's customization features gained and when is held by the existing article AWS History and Timeline regarding Amazon Bedrock.

9.3 The Region Is Fixed at Training Time, Not at Serving Time

There is one workaround to the constraint that models are Region-specific. Custom models can be copied to another Region.

The user guide initially states regarding model copying:

By default, models are only available in the Region and account in which they were created.

However, it further explains that custom models, and models shared from other accounts, can be copied to a supported Region. In fact, the note on the "Prerequisites for Distillation" page provides a specific example. You can either purchase Provisioned Throughput in the US West (Oregon) Region, or copy the distilled model to another Region and then purchase Provisioned Throughput there.

Therefore, the design decision is this: the Region in which you can customize a model and the Region where you want to provide inference do not have to be the same. Training is performed in a supported Region, and then the model is distributed from there. The list of Regions where you can copy a model is clearly broader than the list of Regions where you can customize a model.

However, limitations remain. Only a limited number of base models can be copied, and you need to consult the compatibility table. Furthermore, copying is not automatic. Every time you recreate a custom model, you will need to copy it as well. If you choose an operation that spans Regions, this step adds an extra stage to your pipeline.

Account-based sharing also falls within the same framework. Models shared from other accounts must be copied to your own Region before you can use them. They cannot be accessed directly at the time of sharing.

10. Calling the Model You Built

Once the customization job is complete, your custom model will be available. This is where many users encounter issues. Depending on the configuration, simply entering the ARN of your custom model as the modelId may not allow you to successfully call the model.

10.1 Three Endings, Not Two

There are three possible paths after the creation process, not two.

The first is the path to purchase Provisioned Throughput. This secures dedicated compute capacity and guarantees throughput. Upon purchase, a provisionedModelArn is returned, which you should use as the modelId. You will need to wait until the status reaches InService.

Provisioned Throughput is available in both token-based and model unit-based options. If you choose the model unit-based option, you must apply for model unit allocation with AWS Support before making the purchase. You cannot purchase it until your application is approved, so this is an area to prioritize.

This path offers one operational advantage. Provisioned Throughput associated with a custom model can be linked to a different model later. The models you can select as replacements are either the base model that originally created the custom model, or another custom model created from the same base model. The user guide explicitly states that this replacement is only possible with Provisioned Throughput linked to a custom model. You will not need to repurchase capacity every time you recreate a custom model. This is particularly beneficial for ongoing model updates.

The second path is to create a custom model deployment. This configures on-demand inference. Upon deployment, an ARN is returned, which you should use as the modelId. No compute resources are pre-allocated.

This path has several prerequisites. The user guide lists the following four:

Use either US East (N. Virginia) or US West (Oregon) Regions.
The model must have been customized on or after July 16, 2025.
You must have access permissions for the model being deployed.
If the model is encrypted with an AWS Key Management Service key, you must have permissions to use that key.

Do not let that second condition slip past. Custom models created before this date will not be compatible with this path.

The supported base models are also limited. In US East (N. Virginia), the supported models are Amazon Nova Lite, Amazon Nova 2 Lite, Amazon Nova Micro, and Amazon Nova Pro. In US West (Oregon), the supported model is Meta Llama 3.3 70B Instruct. This functionality is not exclusive to Nova models.

There are discrepancies regarding dates across the documentation. The user guide lists only one date, July 16, 2025, as a prerequisite. In contrast, the September 2025 "What is New" section for Meta Llama 3.3 states "fine-tuned or distilled on or after September 15, 2025." If you plan to use Llama 3.3, it is safest to keep both dates in mind and determine the appropriate course of action based on the actual creation date of your job.

Deleting a custom model deployment cannot be undone. While deleting the deployment itself will not remove the underlying custom model, you will need to recreate the deployment to call it on demand.

Third, there is a path that needs no extra step. If you use an open-weight model and integrate it with OpenAI-compatible APIs using RFT, no additional deployment steps are required. The user guide states this under the "Immediate inference" section:

After fine-tuning completes, use the resulting fine-tuned model for on-demand inference through Amazon Bedrock's OpenAI-compatible APIs (Responses/chat completions API) without additional deployment steps.

You can directly use the ID of the fine-tuned model for inference. This is the simplest of the three options.

The Lifecycle of a Custom Model on Amazon Bedrock

10.2 How You Built It Decides How You Can Call It

The three paths are not a matter of preference. How you built the model decides how you are allowed to call it.

The implications of this become even clearer when customizing Nova using the Amazon SageMaker AI recipes. Within SageMaker AI, users can select the range of weights to be updated. Parameter-efficient fine-tuning (PEFT) updates only a subset of parameters through lightweight adapter layers, such as LoRA (Low-Rank Adaptation), offering faster training and lower compute costs compared to full fine-tuning (FFT), which updates all parameters.

The AWS News Blog notes that this choice even dictates the inference pathway.

Parameter-efficient fine-tuning (PEFT) — updates only a subset of model parameters through lightweight adapter layers such as LoRA (Low-Rank Adaptation). It offers faster training and lower compute costs compared to full fine-tuning. PEFT-adapted Nova models are imported to Amazon Bedrock and invoked using on-demand inference.

Continuing with the same description, it states that Nova models customized with FFT are used with Provisioned Throughput for inference. The design of the training process and the design of the inference process are linked here.

In contrast, within Bedrock's own customization jobs, this choice is not presented as an option for users. The hyperparameter page only lists the number of epochs, learning rate, and warm-up steps; there is no option to specify the range of weights to be updated. While it is impossible to definitively state that "Bedrock automatically applies PEFT," at least it is not presented as a choice for the user.

This difference will serve as a key factor when deciding whether to build with Bedrock or SageMaker AI. Bedrock increases what you do not have to decide, and in exchange it reduces what you are able to decide. While you stay in the managed layer, the range of weights to update, the way the work is distributed, and recovery from failure never become yours to design. In return, the models and the Regions you can choose stay inside the set Bedrock has fixed.

The design considerations regarding how much Provisioned Throughput to secure, which mode to choose, and how to combine it with cross-Region inference are held by the existing article Amazon Bedrock Inference Throughput and Latency Optimization. This article stops here.

The process of evaluating whether your custom model actually performs better is held by the existing article Amazon Bedrock Model Evaluation Practical Guide. Creating a custom model and determining its effectiveness are separate tasks.

11. A Walk Through the Decision

Here is the same material again, walked through in the order of what you have on hand. Work down the list; the first point at which you stop is your answer.

First, determine if the base model you want to use is eligible for customization. This is often where people encounter issues. If you are assuming the current generation of Anthropic models, as of September 1, 2026, there is currently no entry point. Before selecting a method, consult the compatibility table.

Next, verify the Regions supported by that method. For RFT, each of the three models has a specific, fixed Region. This is where you will place both the training data and the reward function. If you want to provide inference in a different Region, you will need to create a duplicate of the custom model, adding an additional layer.

Then, review the materials you have available. If you have labeled input-output pairs, you can choose SFT. However, ensure that you can format the data to meet the requirements of the model you are using. The effort required for conversion will vary depending on whether it needs to be in the prompt and completion format, the Converse API format, or a format specifically for Claude 3 Haiku. Also, check if the number of data points meets the minimum requirement.

If you do not have labels, but can write scoring code, you can choose RFT. However, the official guidelines recommend first measuring the raw performance of the base model. If the reward consistently returns zero, SFT is the better option. If the reward consistently exceeds 95 percent, you may not need it at all.

If you do not have either of those, but have access to a larger model, you can choose distillation. The teacher and the student are paired inside a single provider. If you are already running the teacher model in production and have call logs, you can use a path that does not require re-calling the teacher.

Finally, confirm how you will call the model after it is created. You have three options: purchase Provisioned Throughput, create a custom model deployment, or require nothing at all. The second option has the condition that it must be a model customized after July 16, 2025. After completing these checks, begin preparing the data.

12. Failure Modes and Anti-Patterns

The following are the patterns that looked easiest to walk into while reading the primary sources.

Recording the model ID without its Region. Simply noting a string like amazon.nova-2-lite-v1:0:256k does not tell you that you can only create customization jobs in the US East (N. Virginia) Region. Always treat the model ID and the Region as a pair.

Judging availability from an announcement post. A May 2025 "What is New" article announcing general availability for Model Distillation included Claude 3.5 Sonnet v2, but the current user guide excludes Anthropic. An announcement is the state of affairs at the time it was published, not the state of affairs now. Conversely, older announcement articles sometimes remain online with "preview" still in the title. Take availability from the user guide.

Counting the methods from the customizationType values alone. The enumeration does not include RFT, and it does list continued pre-training. You have to look at both the enumeration and the union to know what Bedrock will accept.

Planning on the strength of "we have the data." Having labeled input-output pairs is different from being able to format them to meet the requirements of the target model. Even within SFT, you might encounter three different shapes: a flat shape with prompt and completion, a nested shape for the Converse API, and a shape specific to Claude 3 Haiku. You cannot begin formatting until you have picked the target model.

Baking confidential data into the weights by leaving it in the training set. The user guide explicitly states that fine-tuned models may reproduce portions of the training data while generating responses. The training data itself is not retained after the job completes, but the model remembers it. With RAG you can apply access controls to the source documents; once the information is baked into the weights, that option is gone. Correcting this is a rebuild rather than an edit, since you delete the custom model, clean the data, and create a new model. Filtering confidential information belongs inside the step that shapes the training data.

Changing the system prompt between training and inference. The system prompt is part of the training data, and the model learns it as the context that triggers the fine-tuned behavior. Improving the prompt on the application side can quietly degrade the custom model. Manage the system prompt used for training as a pair with the custom model itself.

Choosing RFT because there are no labels. It is true that you do not have to supply labels, but you do then have to write the scoring code. Furthermore, the official best practices state that you should run SFT first if the reward is consistently zero. The absence of labels is a reason to choose RFT; it is not a reason to skip SFT.

Making the reward function heavy. This function is called over and over throughout training. The best practices ask you to finish within seconds and to minimize calls to external APIs. Being able to raise the Lambda timeout to 15 minutes does not mean you should take 15 minutes.

Making the reward design too simple. The design guidance asks you to keep scores non-exploitable, which is a safeguard against the model finding a loophole in the scoring. A reward function that only checks whether the format is correct can hand a high score to a well-formatted but meaningless response.

Putting the custom model ARN straight into modelId. You may not be able to call it unless you purchase Provisioned Throughput or create a custom model deployment. Which one you need depends on which base model you customized, and when.

Dropping the "on or after July 16, 2025" clause. A custom model created before that date does not qualify for the on-demand deployment path. The summary "Nova can be called on demand" drops both this condition and the fact that the path is not limited to Nova.

Trying to distill across providers. The student model can only be chosen from the ones paired with your teacher model.

Assuming that inference has to be served from the Region where you customized. Custom models can be copied to another Region, so the place you train and the place you serve can differ. Copying is not automatic, though, so the step returns every time you rebuild the model.

13. Frequently Asked Questions

I'm using RAG, but will customization make RAG unnecessary?

Not necessarily. RAG is a mechanism for adding context during inference, while customization adjusts the model's weights. You will need RAG if you want to reference frequently changing information. Customization is effective for stabilizing response formats, tone, and domain-specific behavior. It is common to use both approaches together.

Of the three methods, which provides the greatest accuracy improvement?

This article does not answer that question. The official documentation from AWS states that RFT provides an average accuracy improvement of up to 66 percent compared to the base model, but this figure is based solely on AWS's own claims and does not represent a comparison of all three methods under identical conditions. The selection criteria should not be solely based on anticipated accuracy, but rather on the input data you have available. If you have labeled pairs, it is SFT. If you can write the scoring, it is RFT. If you have access to a larger model, it is distillation.

I have a limited amount of labeled data. Is RFT sufficient?

RFT does not require labeled input-output pairs, but it does require prompts. The official best practices recommend starting with 100 to 200 prompts, with an upper limit of 20,000 for Nova. However, if the base model is unable to address the task effectively, the official documentation recommends performing SFT first. A guideline for assessment is that the reward consistently returns a value of zero.

Can I customize Claude models?

As of September 1, 2026, not for the current generation. The only Anthropic model supported for fine-tuning, according to the compatibility table, is Claude 3 Haiku, and this is not part of the current generation. Regarding distillation, the user guide explicitly states that Anthropic models are currently not supported, and no timeline has been provided for potential restoration of this functionality.

Once created, can I simply call my custom model?

It depends on the path. There are three ways to call the model: purchasing Provisioned Throughput, creating a custom model deployment, or needing no extra step. The third option only applies when you have fine-tuned an open-weight model using an OpenAI-compatible API. The second option requires that the model was customized on or after July 16, 2025, that it is based on a supported base model, and that it is located in either the US East (N. Virginia) or US West (Oregon) Region.

Can I only perform inference in the Region where I customized the model?

No, that is not the case. Custom models can be copied to supported Regions. By default, they are reachable only in the Region and account that created them. However, by copying them, you can purchase Provisioned Throughput in another Region. The prerequisites for distillation page lists this as a specific option. However, copying is not automatic, so it requires steps each time you update the model.

Will the data used for training remain on AWS?

The user guide clearly states that the training and validation data itself is not retained after the job is complete. The data you provide will not be used to train the base model or distributed to third parties. However, the same page includes a note stating that the fine-tuned model may, during response generation, reproduce portions of the training data. Data not being stored and the model not remembering it are two different things. Sensitive information should be removed from the training data in advance.

Are there three methods, or four, for customization?

The customization entry page in the user guide lists three methods, and this article maintains that perspective. However, the console's help panel lists four, including continued pre-training, while the API's customizationType lists a different three that include continued pre-training. The dedicated page for continued pre-training redirects to the Amazon Bedrock overview page. The discrepancy in numbers is not a misreading, but rather a difference between the documentation.

Can I choose whether or not to use PEFT?

It depends on where you are creating it. On the path that customizes Nova through the Amazon SageMaker AI recipes, you choose between PEFT and full fine-tuning, and that choice also settles the inference path. Within Bedrock's own customization jobs, no item for specifying the range of weights to update appears on the hyperparameters page.

14. Summary

This article has organized model customization on Amazon Bedrock from the side of what each method takes as input.

The binary of "RAG or fine-tuning" has the number of options wrong. The customization entry page in the user guide lists three methods, each requiring different input types. Supervised fine-tuning requires labeled data, reinforcement fine-tuning requires a reward function, and distillation requires a teacher model. This is not just a matter of how the information is presented; it is reflected in the structure of the CreateModelCustomizationJob request itself.

Having data and being able to format it correctly are two separate things. Even within supervised fine-tuning (SFT), the required format of the records can vary depending on the target model. Furthermore, the system prompt is part of the training data, and if it does not match between training and inference, the model will not exhibit the learned behavior.

While the training data is not retained, the model does remember it. The user guide states that training and validation data are not kept after the job completes, but it also notes that the fine-tuned model may occasionally reproduce portions of the training data during response generation. With RAG you can apply access controls to the source documents; once the information is baked into the weights, that option is gone. Excluding sensitive information will need to be incorporated as part of the data formatting process.

Creating a reward function involves providing a single Lambda function. The console presents two options: verifiable rewards and model-based judgment. However, the latter is a process where the console converts the information into a Lambda function during training. Looking at the API reference, the only "grader" listed is a single Lambda function. The open-weight path has no native branch for letting a model do the judging; instead, you have to call it from within the Lambda function.

Distillation has a two-tiered limitation. The teacher and the student must come from the same provider. Furthermore, Anthropic's models are currently unsupported, and there is no indication of when that might change. On the other hand, on the path that uses the prompt-response pairs from the invocation logs, Bedrock does not re-invoke the teacher model. If you are already running a large model in production, those logs can become your training data.

The range of supported models and Regions is limited, and it is also dynamic. Reinforcement fine-tuning is currently only available with three models, and the Region is fixed. The moment you try two or more of them, crossing Regions is settled. However, the fixed location applies to where the training takes place, not necessarily where the model is served. Custom models can be copied to another Region.

What is required next depends on how you built it. There are three possible paths: purchasing Provisioned Throughput, creating a custom model deployment, and a path where nothing further is needed. The second option carries the condition that the model was customized on or after July 16, 2025.

The number of methods available also varies depending on which official page you consult. The entry page lists three, the API's valid values list a different three, and the console help panel lists four. It is better not to settle for a single page when you go to the primary sources.

The process of measuring whether your customization has yielded positive results is held by the existing article Amazon Bedrock Model Evaluation Practical Guide. However, if you move beyond the managed environment and train your model on your own cluster, any decisions previously handled here will become entirely your responsibility. You will need to determine your distribution strategy, how to recover from failures, and how far to roll back. This is discussed in Distributed Training Resilience on AWS.

15. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi

hidekazu-konishi.com