Understanding Embeddings and Vector Search on AWS
Learn how embeddings turn text into numerical representations and enable semantic search on AWS. This article explains how vector search finds meaning beyond exact keywords, how it supports RAG, and the key design, security, and cost considerations.
Traditional search is good at finding the words you typed. But users do not always phrase a question the same way a document phrases the answer.
A customer might search for “Why can’t I sign in?” while the relevant support article says “Troubleshooting authentication failures.” The wording is different, but the meaning is closely related. A simple keyword search may miss that connection.
Embeddings and vector search are designed to find it.
The real-world problem
Imagine an internal support assistant searching thousands of troubleshooting guides, incident reports, and product documents.
Keyword search works when the query contains the same terminology as the documents. It becomes less reliable when users use synonyms, describe symptoms instead of error names, or phrase questions differently from the authors.
The application needs to search by meaning, not only by matching text. That is where embeddings become useful.
What is an embedding?
An embedding is a numerical representation of data. An embedding model converts text, an image, or another supported input into a list of numbers called a vector.
You can think of this vector as a location on a large semantic map. Content with similar meaning tends to be placed closer together, while unrelated content is placed farther apart.
For example, these sentences use different words:
- “The user cannot access the account.”
- “The customer is unable to sign in.”
An embedding model can represent them as nearby points because they express similar ideas. A sentence about configuring an S3 lifecycle rule should appear much farther away.
The individual numbers are not meaningful to a person; their value comes from the relationships between vectors.
Embeddings are not generated answers
An embedding model does not write a response, summarize a document, or reason through a problem. It transforms an input into a vector.
A typical semantic-search flow looks like this:
Document → Embedding model → Document vector → Vector store
When a user submits a query:
User query → Same embedding model → Query vector → Similarity search → Relevant documents
The embedding model creates the vectors. The vector store saves, indexes, and searches them. A generative model is needed only if the application will use the retrieved content to produce a natural-language answer.
This separation matters. Changing the foundation model that writes the final answer does not necessarily require rebuilding the vector index. Changing the embedding model usually does, because vectors from different models may not share the same semantic space or dimensions.
How vector search finds meaning
Once the documents and query are represented as vectors, the system measures how close the query is to each document or document chunk.
Similarity can be calculated using measures such as cosine similarity, dot product, or Euclidean distance.
The vector database returns the nearest matches, often called the top K results. If K is five, it retrieves the five chunks considered most similar to the query.
Most production systems use an approximate nearest-neighbor index instead of comparing the query with every stored vector. Approximation makes search practical at scale, although it can trade a small amount of recall for much faster retrieval.
Where AWS fits
AWS provides separate services for generating embeddings, storing vectors, and building retrieval workflows.
Amazon Bedrock embedding models
Amazon Bedrock provides access to embedding models, including Amazon Titan Text Embeddings and supported third-party models. The right choice depends on the data type, languages, input limits, output dimensions, quality, latency, Region availability, and cost.
Some models support text only, while multimodal embedding models can represent text and images in a related vector space.
Vector storage options
Amazon Bedrock Knowledge Bases supports multiple vector-store options, including Amazon OpenSearch Serverless, Amazon Aurora PostgreSQL-compatible databases with vector capabilities, Amazon Neptune Analytics, and Amazon S3 Vectors. The best choice depends on retrieval features, latency, scale, operational requirements, and existing architecture.
- OpenSearch Serverless fits workloads requiring scalable similarity search, filtering, and hybrid retrieval.
- Aurora PostgreSQL can fit applications that already rely on relational data and SQL.
- S3 Vectors emphasizes cost-efficient vector storage at scale.
- Neptune Analytics is useful when graph relationships should influence retrieval.
Choose the vector store from workload requirements; no option is universally best.
Embeddings inside a RAG application
Embeddings often power the retrieval stage of retrieval-augmented generation, or RAG.
During ingestion, the system:
- loads source documents;
- divides them into smaller chunks;
- converts each chunk into an embedding;
- stores the vector, original text, and metadata together.
During a request, it:
- converts the user’s question into an embedding;
- searches for nearby vectors;
- retrieves the associated text chunks;
- sends those chunks to a generative model as context;
- asks the model to answer using the retrieved evidence.
Embeddings do not guarantee a correct answer. They find potentially relevant context; final quality also depends on the documents, chunking, retrieval settings, prompt, and generation model.
Important design trade-offs
Vector dimensions
A vector’s dimension is the number of values it contains. More dimensions may preserve richer information, but they require more storage and computation. The index must match the embedding model’s supported dimensions, and the largest option is not automatically best.
Semantic search versus keyword search
Semantic search handles paraphrases well. Keyword search is often better for product names, IDs, error codes, and exact technical terms. Hybrid search combines both signals.
Search quality versus latency
Retrieving more candidates may find the right passage but increase latency and irrelevant context. Retrieving too few may omit the answer. Measure the best top-K value with representative queries.
One embedding model versus another
Evaluate embedding models on your actual content. Public benchmarks may not predict performance on multilingual data, code, legal documents, product terminology, or images. Measure retrieval quality, latency, storage, and cost with your own dataset.
Security and cost considerations
Embeddings are numerical, but they should not automatically be treated as anonymous or harmless. They are derived from source data and may preserve information about it.
- Restrict access to source documents, vector indexes, and retrieval APIs with least-privilege IAM permissions.
- Encrypt data in transit and at rest.
- Use private connectivity where workload requirements call for it.
- Apply tenant or user authorization before returning retrieved chunks.
- Store metadata carefully and avoid indexing unnecessary sensitive information.
- Delete or re-index vectors when governed source data is removed or materially changed.
Costs come from embedding generation, vector storage, indexing, search, and any generative model used afterward. Re-embedding an entire corpus can also be expensive.
Common mistakes
Using different embedding models for documents and queries
The stored content and incoming query must be represented in the same compatible vector space. Otherwise, similarity scores lose their meaning.
Embedding entire documents as one vector
A single vector for a long document can blur several unrelated topics. Smaller, logically complete chunks usually make retrieval more precise.
Treating the nearest result as automatically relevant
A vector database will return the closest match even when every match is poor. Applications may need relevance thresholds, reranking, fallback behavior, or human review.
Ignoring exact-match queries
Pure semantic search can struggle with identifiers and exact technical strings. Hybrid retrieval can preserve both meaning-based and keyword-based signals.
Changing the embedding model without rebuilding the index
Vectors produced by different models should not be mixed casually. A model migration normally requires re-embedding the documents and creating a compatible index.
Key takeaways
Embeddings translate meaning into vectors that software can compare. Vector search uses them to retrieve conceptually similar content even when the wording differs. On AWS, Bedrock models create embeddings, supported vector stores index and retrieve them, and Bedrock Knowledge Bases can connect the pieces into a managed RAG workflow.
The most important lesson is that semantic search is a system, not a single model. Its quality depends on the embedding model, chunking strategy, vector index, search configuration, metadata, security controls, and evaluation dataset working together.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article