Designing an application around a foundation model (FM) starts with a shortlist of requirements that any candidate model must pass: what data it handles, which languages it speaks, how much it can read and write in one request, whether it can be customized, and how its cost and speed fit the workload. This lesson treats model choice as a design checklist, and it's the lens the exam uses when a scenario lists requirements and asks which model or feature fits.
Hard Requirements First
Some criteria are pass-or-fail. A model that fails one is out, however good it is otherwise.
- Modality: the kinds of input and output the model supports. A product-photo search needs a model that accepts images; a voice app may need one that handles speech.
- Languages: a model trained mainly on English may answer poorly in Japanese or Arabic. If users write in several languages, check that each one is supported.
- Input and output length: the context window caps how much the model can read in one request, and a separate limit caps how long its answer can be. A 300-page contract needs a large context window; a 20-page generated report needs a high output limit.
- Region: the model must be offered in the AWS Region where your data is allowed to be processed.
In Amazon Bedrock, each model's card in the "Models at a glance" section lists its modalities, context window, output limits and Regions, so it's the first place to check. Language support isn't on the cards, so confirm it in the model provider's documentation.
Design for Change
Requirements grow. A team that expects to fine-tune later, or to distill a large model into a smaller one, should check now that the chosen model supports that customization method in Amazon Bedrock. Not every model does. Choosing a model with no customization path can force a painful switch later, along with a full round of re-testing.
Size, Complexity, Cost and Speed
Model size, roughly the number of parameters, drives model complexity. Larger models handle subtle reasoning better but cost more per token and respond more slowly. A design should match model size to the hardest task the application really performs, not the hardest task imaginable. Some applications route easy requests to a small model and hard ones to a large model.
Prompt Caching as a Selection Factor
Many applications send the same long block of text on every request: system instructions, tool definitions or a reference document. Prompt caching lets supported models reuse that repeated opening part of the prompt instead of processing it again, which lowers input token cost and speeds up responses. Support varies by model, and caching applies to on-demand inference, not batch jobs. So when two models are otherwise equal and the workload repeats a long prefix, caching support can decide the choice.
| Requirement in the scenario | Criterion to check |
|---|---|
| Users write in several languages | Language support |
| Very long inputs or outputs | Context window and maximum output length |
| Fine-tuning planned for later | Supported customization methods |
| Same long instructions on every call | Prompt caching support |
| Data must stay in one place | Regional availability |
On the Exam
Read the scenario for the one requirement that rules options out. If it mentions several languages, long documents, planned fine-tuning or repeated long prompts, the answer turns on that criterion, not on choosing the biggest or newest model.