An embedding model converts text into vectors — lists of numbers — so that "expense reimbursement rules" and "travel policy" land near each other in a searchable index even though they share no words. In a customer-managed Bedrock Knowledge Base (the type where you control the pipeline and vector store), you pick the embedding model at creation time, and it quietly determines retrieval quality, index size, and language coverage for everything downstream. Managed Knowledge Bases, by contrast, use service-managed embedding models by default, so this choice mostly arises on the customer-managed path — see managed vs customer-managed.
The documented menu
AWS's Knowledge Bases support page lists these text embedding models:
| Model | Model ID | Dimensions | Types |
|---|---|---|---|
| Amazon Titan Embeddings G1 – Text | amazon.titan-embed-text-v1 | 1536 | float |
| Amazon Titan Text Embeddings V2 | amazon.titan-embed-text-v2:0 | 256 / 512 / 1024 | float + binary |
| Cohere Embed English | cohere.embed-english-v3 | 1024 | float + binary |
| Cohere Embed Multilingual | cohere.embed-multilingual-v3 | 1024 | float + binary |
How to read that table
Titan G1 is the legacy row. A fixed 1536 dimensions, float only — no size or quantization flexibility. For new knowledge bases, its main relevance is recognizing it in older deployments.
Titan V2 is the flexible AWS-native default. Three dimension options (256, 512, 1024) plus binary vector support. Dimensions are a cost dial: a 256-dimension index stores a quarter of the numbers of a 1024-dimension one and searches faster, usually at some retrieval-quality cost. Binary embeddings — quantization down to one bit per dimension — shrink storage dramatically again. The honest method: build with 1024 float, measure retrieval quality on your own queries, then shrink and re-measure.
Cohere Embed is the language question. The English model targets English corpora; the Multilingual model handles mixed-language content — the standout differentiator on this menu. If your knowledge base spans German contracts, Japanese support tickets, and English wikis, cohere.embed-multilingual-v3 is the documented option built for it. Both Cohere models are fixed at 1024 dimensions with float and binary types.
One switching-cost warning: embeddings from different models (or dimensions) are not comparable. Changing the embedding model later means re-embedding and re-indexing the entire corpus.
When multimodal models change the comparison
If your knowledge base must retrieve from images, slides, or media — not just text — the menu shifts to the documented multimodal options: Amazon Titan Multimodal Embeddings G1, Cohere Embed v3 multimodal, and Nova Multimodal Embeddings, all at 1024 dimensions. Nova's multimodal path also unlocks audio/video chunking with configurable 1–30 second chunk durations (see multimodal chunking). The text-vs-text Titan/Cohere debate dissolves here: choose based on which media types and parsing pipeline you need, and check the current support page for regional availability.
What about Voyage — Anthropic's recommended companion?
Anthropic's own embeddings guidance points to Voyage AI, and Voyage is available through AWS Marketplace. But Voyage is not documented as a Bedrock Knowledge Bases embedding model — the KB list is Amazon and Cohere only. Wanting Voyage embeddings means leaving the managed KB pipeline: run your own index and pass retrieved chunks to Claude with search_result blocks. That trade — managed convenience versus embedding choice — is the real Titan-vs-Cohere decision's outer frame; the Voyage article covers the other side.
Where to go next
Embedding choice interacts directly with chunking strategy — decide them together. Then wire the generation side with RetrieveAndGenerate and Claude.