Skip to main content
In this lesson, we review the foundation models available in Amazon Bedrock and how to choose the right one for your application. We’ll frame the selection problem, identify the most important model properties, show how to use the model catalog plus empirical testing to narrow choices, and describe the expected results when you pick the right model for the task.
A slide titled "Lecture Flow" showing a linear flowchart of gradient blue boxes: "Real Problem" → "Solution" → "Workflow", with arrows leading down to "Results" and "Key Takeaway." The diagram summarizes evaluating and selecting models for an app on a dark blue background.
Problem statement With many models from multiple vendors available in Bedrock, selecting the right model can be difficult. Models differ in capabilities, modalities, latency, context-window size, cost, and failure modes. Choosing poorly can produce inaccurate, late, or irrelevant responses—wasting budget and hurting user satisfaction. A practical, repeatable evaluation strategy helps teams match models to the concrete requirements of each use case and minimizes unnecessary cost and risk. Evaluating model properties Focus on the core properties that matter most for your app:
  • Modality — What kinds of input and output does the model support? Text-only, image-only, multimodal (text+image), audio, or image generation? Pick models that natively support the modalities you require.
  • Context window — The listed token/length limit describes the combined input plus output the model can handle. If you expect to pass large inputs (for example, multi-thousand-page documents), confirm the model’s context window accommodates the input plus the expected response.
  • Task alignment (strengths) — Some models are tuned for multi-turn chat and instruction-following; others excel at summarization, code generation, or image editing. Use models that are optimized for your primary task to reduce hallucinations and improve quality.
  • Latency and throughput — For interactive applications, latency matters. For batch workloads, throughput and cost per token matter more.
  • Failure modes — Understand how a model tends to fail (e.g., hallucinations, truncated output, or frequent retries) so you can design mitigations and acceptance criteria.
A presentation slide titled "Solution: Evaluate Model Properties" showing three sections: Modality (Text, Image, Multi-modal), Context Window ("How much input can be processed"), and Model Strengths (Chat, Summarization, Coding). The design uses a dark blue background with rounded turquoise gradient buttons.
Quick reference table: core property checklist Model size, cost, and latency “Model size” (number of parameters) often correlates with reasoning ability, but bigger is not always better:
  • Larger models typically provide stronger reasoning and generalization, but cost more per token and have higher latency.
  • Smaller models are faster and cheaper; they can be ideal for simple summarization, classification, or routine Q&A.
  • For input-heavy tasks, prioritize context-window capacity over parameter count.
When designing for scale:
  • Estimate expected throughput (calls per second) and concurrency (simultaneous users). Cost per token compounds quickly at scale.
  • Use smaller models where they suffice; reserve larger models for tasks requiring deep reasoning.
  • Consider provisioned throughput if you can predict steady, high demand (see next section).
A presentation slide titled "Workflow: Model Strengths" showing two blue circular icons labeled "Cost" (with a receipt icon) and "Modality" (with a document/image icon). Under each are brief bullet points about pricing (charged per token, larger models cost more) and supported modalities (text, image, multi-modal).
Use-case alignment Match the model to the job. Typical mappings:
  • Simple Q&A and document summarization: text-only, small-to-midsize models (cost-effective and sufficient for many tasks).
  • Chat assistants with multi-turn reasoning: midsize-to-large conversational models (some Anthropic and Meta models are examples).
  • Image generation or editing: specialized image-generation models (for example, Stable Diffusion by Stability AI).
  • Code generation: models tuned for coding or those with strong reasoning to reduce incorrect outputs.
A slide titled "Workflow: Use-Case Alignment" showing four colored panels for different AI use cases: Simple Q&A or Summarization, Chat Assistant With Reasoning, Image Generation, and Code Generation. Each panel includes an icon and a short suggestion about which model types to consider.
A practical model-selection strategy Follow a staged approach to reduce risk and cost:
  1. Start with a smaller model that matches your modality and context-window needs.
  2. Test quality against your acceptance criteria with real inputs.
  3. If quality is insufficient, evaluate midsize or large models and re-run tests.
  4. Once you meet quality goals, optimize prompts and token usage to reduce cost.
  5. Monitor performance and cost in production and iterate.
Start small and iterate: this reduces experimentation cost and prevents over-provisioning. Use automated tests and representative datasets to compare models objectively.
An infographic titled "Workflow: Model Selection Strategy" with five colorful steps. The steps read: 01 Begin with a smaller model, 02 Test quality, 03 Increase model size if necessary, 04 Monitor token usage, and 05 Optimize for cost vs performance.
Provisioning and billing modes Bedrock typically offers serverless on-demand hosting (multi-tenant) where you pay per token (input + output). Image-generation and larger multimodal models generally cost more per token or per image. If you can forecast steady throughput, provisioned throughput reserves capacity and can provide discounted pricing. Accurately forecast concurrent load (e.g., 100, 1,000, or 10,000 concurrent users) because costs increase substantially when moving from development/test to production. Don’t bind your application to a single model Design your application to route requests to different models based on capability and cost:
  • Use a small, inexpensive model for routine or low-risk queries.
  • Route image generation to a specialized image model (for example, Stable Diffusion).
  • Use a stronger reasoning model for tasks that require deeper comprehension or higher trust.
Keep revisiting modality, model size, and context window when you define routing rules.
Important: Mixing models improves cost and quality trade-offs, but also increases operational complexity. Track which model handled each request for debugging, billing allocation, and auditing.
A dark-blue presentation slide titled "Summary" listing six numbered tips about selecting and using models — covering use case, latency, cost (Bedrock), routing prompts, model size, modalities, and context window. Each item is marked with a teal arrow-shaped number icon.
Expected results from good model selection When you align models to use cases, you should see:
  • Lower costs and fewer surprises in production billing.
  • Better latency and a stronger user experience for interactive apps.
  • Reduced experimentation time since candidate models are narrowed early.
  • More efficient use of generative AI resources by avoiding one-size-fits-all models.
A presentation slide titled "Results" with four numbered panels highlighting benefits: better model selection for specific use cases, improved application performance and quality, reduced experimentation time, and more efficient use of generative AI resources. Each panel has a small icon and a colored top accent.
Key takeaway Use the right model for the right task every time. Avoid sending all requests to a single model without evaluating modality fit, context-window capacity, cost, and latency.
A minimalist presentation slide with a dark left panel labeled "Key Takeaway" and a turquoise "01" badge next to the text: "Use the right model for the right task, every time."
Next steps Try a hands-on lab to experiment with different foundation models and observe trade-offs firsthand. For vendor documentation and pricing details, see: Additional resources

Watch Video

Practice Lab