The generative AI customization spectrum: From prompt engineering to custom models on AWS

This post shows you how to pick the right generative AI customization approach for your workload without over-engineering or under-investing.

AWS provides access to foundation models from Anthropic, Meta, Mistral, and Amazon through Amazon Bedrock, along with the infrastructure to build everything from chatbots and code assistants to document processors and autonomous agents. The models are available. The harder question is what to do with them for your specific problem.

Having access to Anthropic Claude, Amazon Nova, or Llama does not automatically mean you know how to make them work for your specific use case. Should you write a better prompt? Plug in your documents with Retrieval Augmented Generation (RAG)? Fine-tune? Train something from scratch? The number of options creates decision paralysis, and choosing wrong is expensive.

Teams often jump straight to fine-tuning when a well-structured prompt would have solved the problem in an afternoon. Other teams stay stuck on prompt engineering for weeks when their use case clearly needs domain-specific training data. Both mistakes cost real money in compute, real time in delayed launches, and real credibility when model outputs do not land with stakeholders.

This post gives you an 8-step decision framework, the generative AI customization spectrum on AWS. You will walk away knowing which approach fits your use case, what it costs, how much data you need, and when to escalate to the next level. The core principle: start with the simplest approach and go deeper only when you must.

Solution overview

The customization spectrum, a visual staircase from simplest to most complex: Not every generative AI problem needs the same level of investment. The customization spectrum is a staircase where each step increases in effort, cost, and data requirements, but also in the degree of control and domain specificity you gain.

The spectrum breaks into three categories:

USE: Don’t touch the model. Change how you talk to it. Steps 1–2: Use existing models as-is, or improve your prompts with system instructions, few-shot examples, and chain-of-thought reasoning. As you scale from one prompt to hundreds across production workloads, you can use prompt evaluation to measure prompt quality against accuracy and robustness metrics. Prompt optimization automatically rewrites prompts to perform better on your chosen model, removing manual trial-and-error from the process.

ENHANCE (harness the model): Add things around the model. Weights stay frozen. Steps 3–5: Ground the model with your documents (RAG), cache expensive prompts, or distill a large model’s knowledge into a smaller, faster one. This is what the industry calls “harnessing” a model: wrapping it with external tools, data sources, and optimizations while leaving its weights untouched.

TRAIN: Change the model itself. Steps 6–8: Update weights with your labeled data (fine-tuning), expand foundational knowledge with massive unlabeled corpora (continued pre-training), or build a fully custom model from scratch (Amazon Nova Forge).

The rule: start at Step 1. Move up only when the current step fails your accuracy, latency, or domain requirements. Most workloads never need to go past Step 3.

Architecture overview: AWS service mapping

The following diagram maps each step of the spectrum to the AWS services that support it.

Decision flow

The following diagrams summarize the escalation signals that tell you when to move from one step to the next.

Analogy: The chef’s kitchen

The chef analogy works well because it gives you a single protagonist (the chef is the model) to follow through all eight steps. It also makes the escalation cost obvious: writing sharper orders costs nothing, while sending a chef to culinary school costs months of investment and lost kitchen output. For distillation: “The head chef’s tasting menu is flawless but takes 45 minutes per plate and costs a fortune in ingredients. Teach the line cook the three bestsellers, serve them in 10 minutes at a third of the cost.” That maps directly to the distillation tradeoff: a smaller student model replicating the teacher’s outputs faster and cheaper for the specific tasks you have validated.

Technical breakdown: the 8 steps of the spectrum

The following sections cover each step in order: what it does, when to use it, and the signal that tells you to escalate to the next step.

Step 1: Using existing models as-is (Amazon Bedrock: Claude, Nova, OpenAI, Llama)

Call a foundation model (FM) directly through Amazon Bedrock with zero customization. Choose from Claude, Amazon Nova, Llama, Mistral, and others through a single API. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock.

When to use: General-purpose tasks like summarization, translation, brainstorming, and code generation where off-the-shelf accuracy is acceptable. No training data needed, no setup required, only an API call.

When to progress: Output is too generic, wrong format, or doesn’t follow your domain conventions.

Real-world examples:

• Dovetail: Creates prototypes within a day and releases new generative AI features in only two weeks using Amazon Bedrock with no model customization.

Step 2: Prompt engineering and in-context learning (system prompts, few-shot, chain-of-thought)

Optimize how you instruct the model with system prompts, few-shot examples, chain-of-thought reasoning, without changing model weights.

When to use: The model has the knowledge but needs guidance on format, tone, or reasoning path. This works for the majority of use cases.

When to progress: Prompt exceeds approximately 2,000 tokens, still hallucinating domain-specific facts, or requires knowledge the model doesn’t have.

Structuring effective prompts

To get the most out of prompt engineering on Amazon Bedrock, structure every prompt using five building blocks: clear instructions (use action verbs and specify scope), sufficient context (current state, dependencies, constraints), specific requirements (functional and non-functional), output format (code only, step-by-step, comparison), and quality indicators (expected behavior, edge cases, performance targets).

A common mistake is overloading instructions or dumping context without specificity. Instead, scale your prompt detail to the task complexity. Quick tasks need minimal context, while complex feature requests demand comprehensive specifications.

Real-world examples:

• DoorDash: Built a fully voice-operated self-service generative AI contact center solution using Amazon Bedrock and Anthropic Claude, ready for live testing in only 2 months.
• Reference: Prompt Optimization in Amazon Bedrock

Step 3: Retrieval-augmented generation (RAG)

Supply the model with external knowledge at inference time using Amazon Bedrock Knowledge Bases, the fully managed RAG capability. The model generates answers grounded in your data, reducing hallucinations without retraining.

When to use: The model needs access to private, frequently updated, or domain-specific data (internal docs, policies, product catalogs).

When to progress: Retrieval latency exceeds requirements, context window overflows, or the model still can’t reason correctly over retrieved content.

Real-world examples:

• Fractal Analytics: Built a unified knowledge base for call center agents using Amazon Bedrock and RAG, achieving 10–15 percent reduction in call handling time, 30 percent call deflection, and 200K+ monthly queries.
• EXL: Reduced insurance underwriting costs by 80 percent using a RAG-powered virtual assistant on Amazon Bedrock that processes and evaluates extensive documents.

Reference: Guidance for Building Custom Chatbots Using RAG on Amazon Bedrock

Step 4: Prompt caching and context optimization (reducing latency and cost for repeated queries)

Pre-process and cache frequently used prompt prefixes (system instructions, few-shot examples, large context) so repeated queries skip redundant computation. Reduce latency and cost without changing output quality.

When to use: High-volume, repetitive queries with shared context. For example, customer support bots, document Q&A, code assistants hitting the same system prompt.

When to progress: You need a smaller, cheaper model that delivers the same quality, when caching alone can’t solve the model size/cost problem.

Real-world example:

• inGenious.ai: Tested and validated multiple large language models (LLMs) to achieve chatbot responses in less than 1 second without sacrificing comprehension, improving chatbot comprehension by 80 percent using Amazon Nova.

Reference: Effectively use prompt caching on Amazon Bedrock

Step 5: Model distillation (training smaller models to mimic larger ones)

Transfer knowledge from a larger “teacher” model to a smaller “student” model. The student learns to replicate the teacher’s outputs for your specific use case, delivering near-identical quality at a fraction of the cost and latency.

When to use: You’ve validated quality with a large model but need it cheaper, faster, or deployable at the edge. Amazon Bedrock Model Distillation produces student models that are up to 500 percent faster and up to 75 percent less expensive than the teacher, with less than 2 percent accuracy loss (per the Amazon Bedrock Model Distillation general availability announcement, May 2025).

When to progress: The distilled model can’t match the tone, format, or reasoning style you need, which means the model’s weights need direct updating through fine-tuning.

Real-world example:

• Goodnotes: Transitioned from a self-hosted model on Amazon Elastic Kubernetes Service (Amazon EKS) to Anthropic Claude on Amazon Bedrock to improve scalability and cost-effectiveness for its AI-powered “Ask Goodnotes” feature.

Reference: Amazon Bedrock Model Distillation

Step 6: Fine-tuning

Update model weights using your labeled data (input-output pairs) to permanently change the model’s behavior, style, or domain accuracy. Available as Parameter-Efficient Fine-Tuning (PEFT/LoRA) for smaller datasets or Full Fine-Tuning for comprehensive updates.

When to use: Tone, format, or task-specific reasoning doesn’t match after prompt engineering and RAG. You have thousands of labeled examples showing desired behavior.

When to progress: The model doesn’t understand domain terminology or concepts. It needs foundational knowledge, not only behavioral adjustment.

Real-world example:

• Trellix (Cyber security): Built generative AI security tools using Amazon Bedrock and Anthropic Claude. They fine-tuned models for cyber security integration, saving over 40 hours of development time per integration and achieving a 90% reduction in time-to-market for new security integrations.

Reinforcement fine-tuning (RFT): Standard fine-tuning (SFT) requires you to produce gold-standard labeled input-output pairs for every behavior you want the model to learn. For tasks like code generation, structured output accuracy, and multi-step reasoning, creating these perfect examples by hand is expensive and often impractical, because verifying correctness is far cheaper than demonstrating it. RFT solves this by letting you define a reward function that scores outputs, and the model learns to optimize against that signal. Without managed infrastructure, implementing RFT requires building custom training loops, managing GPU clusters, and orchestrating reward model serving alongside policy training. Amazon Bedrock makes this accessible as a fully managed service: you supply prompts (up to 20,000 per job) and a scoring function, and Bedrock handles the reinforcement learning pipeline end-to-end. RFT became available for Amazon Nova models in December 2025 and expanded to open-weight models including OpenAI GPT OSS 20B and Qwen 3 32B in February 2026. For a complete implementation walkthrough, see Reinforcement fine-tuning on Amazon Bedrock with OpenAI-Compatible APIs on the AWS Machine Learning Blog (March 2026).

Reference: Amazon Bedrock fine-tuning

Data requirements:

Method	Data needed
PEFT	Few thousand labeled examples
Full Fine-Tuning	Tens of thousands of labeled examples
DPO – Direct Preference Optimization	Pairs of preferred/non-preferred responses

Direct Preference Optimization (DPO) aligns model outputs with human preferences by training directly on pairs of preferred and non-preferred responses, alleviating the need for a separate reward model. For implementation details, see Customize Amazon Nova in Amazon SageMaker AI using Direct Preference Optimization.

Step 7: Continued pre-training (massive unlabeled domain corpus)

Expand the model’s foundational knowledge by training on large volumes of unlabeled, domain-specific data (documents, transcripts, code, research papers). This is self-supervised learning where the model learns your domain’s language, concepts, and relationships at a fundamental level.

When to use: The model doesn’t understand your domain terminology even after fine-tuning. You have massive proprietary corpora (1B+ tokens) that represent knowledge no public model has seen.

The historic challenge with continued pre-training (CPT) is catastrophic forgetting: training on domain-specific data improves domain performance while degrading general reasoning, instruction following, and safety alignment. Amazon Nova Forge addresses this with data mixing, which blends your proprietary corpus with Amazon Nova-curated training data at every training phase. The curated datasets are organized by domain and designed to preserve general performance while your data reshapes the model’s domain expertise. For implementation details, see the Continued Pre-Training and Mid-Training documentation in the Amazon Nova Forge User Guide.

RAG retrieval returns correct document chunks but the model still produces incoherent synthesis. When the retriever surfaces the right paragraphs and the model still cannot combine them into a valid response, the problem is comprehension, not information access. Additional prompt engineering will not bridge that gap because the missing knowledge is architectural, not factual.

Reasoning over domain structure fails even when individual facts are correct. A model fine-tuned on insurance claims data can learn to fill standardized forms, but it can’t reason about subrogation chains or multi-party liability cascades because those relationship patterns never appeared in its pre-training data. Feeding large volumes of unstructured domain documents through CPT builds the structural comprehension that labeled fine-tuning examples can’t replicate.

The model consistently misinterprets domain-specific terminology even when Amazon Bedrock Knowledge Bases retrieves the correct context and fine-tuning examples demonstrate proper usage. Legal contracts, patent filings, pharmaceutical compound nomenclature, and financial regulatory filings use language that the model’s original pre-training corpus underrepresents, so its internal token representations lack the structural foundation needed to parse these domains correctly.

When to progress: No existing model architecture fits your requirements, and you need full control over training data, checkpoints, and model design.

Real-world example:

• Sonrai: Accelerates precision medicine research by 50 percent with 5x fewer errors, saving up to $20,000 per experiment, using Amazon Bedrock for single-cell RNA-seq data analysis with domain-specific model customization.

Data requirements: 1B+ tokens of unlabeled domain content for mid-training, and 1T+ tokens for full continued pre-training.

Step 8: Custom model training, Amazon Nova Forge (fully custom foundation model)

Build your own frontier foundation model using the Amazon Nova architecture, intermediate checkpoints, and Amazon-curated training data mixed with your proprietary data. This is the “open training” paradigm: you start from early model checkpoints, blend proprietary data, and create a model trained for your domain from scratch.

When to use: Off-the-shelf models and all previous customization steps can’t meet your accuracy requirements. You have machine learning (ML) expertise, large proprietary datasets, and need durable competitive differentiation. This is typically the path when you intend to monetize your model as a core product or service offering. Amazon Nova Forge makes this investment worthwhile by providing managed training infrastructure, Amazon-curated data mixing, and intermediate checkpoints, significantly reducing the time and cost to build a production-ready custom foundation model.

When NOT to use: For most customers, Steps 1–7 are sufficient. Nova Forge is for specialized industries requiring deep domain expertise such as pharma, robotics, finance, manufacturing.

Real-world examples:

• Nimbus Therapeutics: Used Amazon SageMaker to accelerate the design of candidate drugs with custom-trained models on proprietary molecular data.

What makes Forge different:

• Access to intermediate model checkpoints (pre-trained, mid-trained, post-trained).
• Data mixing with Amazon-curated datasets (helps prevent catastrophic forgetting).
• Multi-turn RFT in customer’s own environment (robotics simulators, code validators).

Reference: Building specialized AI without sacrificing intelligence: Nova Forge data mixing in action

RL with custom reward functions: Amazon Nova Forge supports reinforcement learning (RL) where you connect your own environment as the reward signal. Chemistry simulations that score molecular designs, robotics physics engines that penalize collisions, code validators that check compilation success: these connect directly to the training loop so the model learns to optimize against your business-specific evaluation criteria rather than generic human preference labels. Nova Forge also supports multi-turn rollouts for training complex agent workflows and sequential decision-making tasks.

On-demand inference for custom models: Custom Amazon Nova models trained after July 2025 support pay-per-token inference on Amazon Bedrock with no Provisioned Throughput required. You can train a custom model and serve it at standard per-call rates, the same pricing model as non-customized Amazon Bedrock model inference. This changes the cost calculation for Steps 6-8 significantly, since you no longer need to commit to allocated capacity before validating production traffic.

Why Nova Forge over building a custom pipeline on Amazon SageMaker: Amazon SageMaker gives you raw infrastructure: GPU clusters, distributed training libraries, and custom containers with full control over every training parameter. Amazon Nova Forge is a fully managed service that gives you a curated path. You start from model checkpoints that Amazon has already trained on billions of tokens, blend your data with Amazon-curated corpora organized by domain, and run push-button recipes optimized for the Nova architecture. The practical difference is timeline and team size. A custom training project that would otherwise require a dedicated ML team and months of iteration collapses into a managed workflow that produces a deployable model in weeks, because the infrastructure decisions, recipe tuning, and data mixing ratios are already solved. This reduces your time to market so you can focus on your domain data and use case rather than building and maintaining training infrastructure.

Nova Forge SDK (pip install amzn-nova-forge): Available on GitHub since March 2026, the SDK provides a unified Python interface spanning the complete customization lifecycle. ForgeTrainer manages training job configuration and execution, ForgeEvaluator runs model evaluations against your benchmarks, ForgeDeployer handles deployment to Amazon Bedrock or Amazon SageMaker endpoints, and ForgeInference wraps inference calls against custom models. The SDK runs on Amazon SageMaker Training Jobs or Amazon SageMaker HyperPod, alleviating the need to manage distributed training configurations, gradient checkpointing strategies, or cluster fault tolerance.

Decision framework

The spectrum is a diagnostic process, not a menu where you pick the most advanced option your budget allows. Start at Step 1, validate the output against your requirements, and if it fails, identify why it fails. That specific failure mode maps to exactly one next step on the spectrum.

Production systems often layer multiple steps together because real workloads have compound requirements. RAG plus fine-tuning is the most common hybrid: fine-tune the model for behavioral alignment and domain-specific formatting, then use RAG for dynamic knowledge that changes faster than any training cycle can keep up with. Teams also commonly distill a fine-tuned model to achieve both behavioral alignment and production-grade latency in a single serving configuration. The spectrum helps you identify which capabilities your system needs. The final architecture combines whatever steps address your specific failure modes.

Common mistakes to avoid

Serving a large teacher model in production without distilling. If you validated quality with a larger model during prototyping, distill into a smaller student model before scaling to production traffic.

Choosing continued pre-training because “we have a lot of data.” Data volume alone does not justify CPT. If your data consists of factual reference material like product specifications or policy documents, RAG handles it at lower cost because the information changes frequently and the model only needs to cite it, not internalize it.

Jumping to fine-tuning because “RAG is too slow.” Fine-tuning changes model behavior, not inference speed. If retrieval latency is the bottleneck, the fix is better chunking strategies, hybrid search configurations, or prompt caching.

When to escalate: Matching your problem to the right step

No existing model architecture fits your requirements, or you need full control over training phases with proprietary reward environments? Build from early checkpoints with data mixing and custom RL through Amazon Nova Forge (Step 8).

Model does not understand domain language or structural patterns even after fine-tuning with representative examples? The gap is comprehension, not behavior. Continued Pre-Training (Step 7) with your raw domain corpus builds the foundational understanding that fine-tuning cannot add.

Model tone, reasoning style, or task execution does not match your requirements despite having correct knowledge? Fine-tune (Step 6). Use SFT when you can demonstrate correct behavior through labeled examples, or RFT when you can define correctness as a reward function.

You validated quality with a large model but need it cheaper and faster for production? Distill (Step 5). Amazon Bedrock Model Distillation uses a teacher model to generate synthetic training data, then fine-tunes a smaller student model to replicate the teacher’s outputs for your specific use case.

RAG works but latency or cost is too high for production volume? Cache repeated prompt prefixes (Step 4). Amazon Bedrock prompt caching pre-computes the static portions of each request so repeated queries skip redundant computation.

Model hallucinates domain-specific facts? The model lacks knowledge it was never trained on. Ground it with your data through Amazon Bedrock Knowledge Bases (Step 3), since providing knowledge at inference time is cheaper and faster than any form of model training.

Output is generic or poorly formatted? The model needs better instructions. Improve your prompt (Step 2) by adding system instructions, specifying output format, and including few-shot examples that demonstrate the structure you want.

Conclusion

You now have a clear path from “we have a foundation model” to “we have a model that works for our specific use case.” The spectrum is not about using the most advanced technique available. It is about using the simplest technique that meets your accuracy, latency, and domain requirements.

Here’s the short version: Amazon Bedrock handles Steps 1–7: prompt engineering, RAG through Knowledge Bases, prompt caching, model distillation, and fine-tuning. When you need deeper customization, Amazon SageMaker AI gives you managed infrastructure for continued pre-training. And when your use case demands a fully custom frontier model, such as in specialized industries like pharma or defense, you can use Amazon Nova Forge to build one from intermediate checkpoints with your own data mixing.

To get started, try your use case with an existing model on Amazon Bedrock. If the output meets your requirements, you are done. If it doesn’t, identify what is failing, find that failure mode in the escalation signals, and move to the next step. Start simple. Escalate only when you have evidence that the current step is insufficient.

---

About the authors

​