Amazon S3 vector store — A cost effective vector store for RAG systems

Amazon S3 Vector Engine (Amazon S3 Vectors) introduces native vector storage and search capabilities directly within Amazon S3, eliminating the need to deploy or manage separate vector databases. With this feature, you can seamlessly upload, store, and query vector embeddings at scale while achieving sub‑second retrieval performance.

S3 Vectors adds two key primitives to S3:

• Vector buckets — specialized S3 buckets optimized for vector storage.
• Vector indexes — structures within those buckets that enable fast similarity search.

As the first major cloud object store to natively support vectors, S3 Vectors can reduce the operational overhead and cost of managing large‑scale embedding datasets — often by up to 90% compared to running traditional vector databases.

In this model, vectors are numeric representations of unstructured data (such as text, images, or audio) generated by ML embedding models. Using distance metrics like cosine similarity or Euclidean distance, S3 Vectors can efficiently identify related items by comparing the embeddings directly within S3.

For an AI agent operating in real‑world scenarios — whether it’s answering domain‑specific questions, generating internal insights, or automating workflows — a vector store plays a critical role:

• Captures semantic meaning: Traditional keyword search fails when queries are phrased differently from the source text. Vector embeddings capture the meaning of content, enabling semantic retrieval that aligns with how humans interpret language.
• Keeps the model up‑to‑date: Instead of retraining or fine‑tuning, the agent can instantly access fresh information by simply updating the vector store. This ensures the agent responds with the most current knowledge available.
• Enables context‑aware reasoning: AI agents need relevant context to avoid hallucinations. Using a vector store, the agent can pull highly relevant snippets and ground its reasoning in authoritative internal data.
• Scales with organizational knowledge: As enterprise content grows — documents, wikis, reports, emails, logs — the vector store scales horizontally, maintaining low-latency retrieval even for millions or billions of embeddings.
• Supports multi‑modal intelligence: Vector stores aren’t limited to text — they also index embeddings for images, audio, and other unstructured formats, enabling richer agent capabilities.

In short, a vector store is the memory layer of an AI agent: fast, searchable, semantic, and always aligned with your business data. When combined with Amazon Bedrock Knowledge Bases, a foundation model becomes not just a generative system but a fully informed reasoning engine capable of delivering accurate and trusted outputs.

Amazon Bedrock Knowledge Bases is a fully managed capability within Amazon Bedrock that delivers an end‑to‑end Retrieval‑Augmented Generation (RAG) workflow. It enables foundation models (FMs) to securely access and reason over your private enterprise data — without requiring any model fine‑tuning.

With Knowledge Bases, your documents are automatically ingested, chunked, and converted into vector embeddings that are stored in a vector database. During query time, the system performs a high‑precision vector search to retrieve the most relevant text segments, which are then injected into the model prompt. This grounding process results in accurate, context‑aware outputs, complete with source citations and without any need for retraining or modifying the underlying model.

A vector store is critical in this process because it enables fast semantic search over large unstructured datasets. By representing content as embeddings, it allows the AI agent to retrieve meaningfully related information — even when queries and documents use different wording. This makes the vector store the operational “memory” layer for any RAG‑enabled agent, ensuring responses remain up‑to‑date, context‑aware, and grounded in trusted data.

S3 Vectors is natively supported in Bedrock Knowledge Bases, allowing you to build RAG applications that can store billions of embeddings economically while still benefiting from sub‑second similarity search. Bedrock Knowledge Bases handle the retrieval and generation logic, while S3 Vectors provides a low‑cost, highly durable memory layer for all vectorized content. By using S3 as the underlying vector store, you get scalable, durable, pay‑as‑you‑go storage for massive embedding datasets — ideal for large document collections or workloads where queries are infrequent but data must be retained long‑term. Together, they enable ML applications and AI agents to answer questions using proprietary enterprise data — accurately, at scale, and with significantly lower operational cost than traditional vector database setups.

Prerequisites

For this demo, you’ll need an AWS account with IAM permissions to create and manage resources such as Amazon S3, Bedrock Agents, Knowledge Bases, and the required service roles.

1. S3 Vector Bucket

You’ll need an Amazon S3 Vector Bucket to store the vector index data (unless you let Bedrock create one for you automatically). You can provision a vector bucket through S3 Console or using AWS CLI

Make note of the bucket name and AWS Region. A vector bucket behaves like a standard S3 bucket but is optimized for vector data; its name and base encryption setting cannot be modified after creation.

2. Data Source for Documents

Your Knowledge Base requires a document source. For this walkthrough, use a standard S3 bucket containing the files (PDFs, text documents, etc.) you want indexed. While Bedrock Knowledge Bases also support sources such as Confluence, SharePoint, Salesforce, and web crawlers, this demo assumes S3 for simplicity.

3. Foundation Model Access

To build and run the RAG workflow, you must have access to two categories of foundation models in Amazon Bedrock:

• An embedding model — used to convert your documents into vector embeddings during ingestion and to embed user queries at runtime. Examples include Amazon Titan Text Embeddings or other supported embedding models.
• A large language model (LLM) — used to generate grounded responses by combining the retrieved context with the user’s query. Examples include models such as Anthropic Claude or Amazon Titan Text.

Both model types must be enabled in your Bedrock account beforehand and should have sufficient quotas. The embedding model powers the retrieval pipeline, while the LLM handles reasoning and response generation — together forming the core of the RAG execution process.

Create a KB with S3 vector store

First, create an S3 Vector Bucket. In the AWS Management Console, open Amazon S3 and select Vector buckets from the left navigation pane. Choose Create vector bucket, provide a unique bucket name, and select an encryption option — SSE‑S3 for this demo.

A vector bucket behaves like a standard S3 bucket but is purpose-built for vector data. Once created, its name and base encryption settings cannot be changed.

Next, create a Vector Index inside the vector bucket. A vector index functions like a collection or table that holds a specific set of embeddings.

In the S3 console, open your vector bucket and select Create vector index.

Provide a unique index name and configure the following parameters:

• Dimension — The dimensionality of your embedding vectors. This must match the output size of the embedding model you plan to use. Example: Titan Text Embeddings v2 produces 1,024‑dimensional vectors, so set dimension = 1024. (Titan G1 = 1536 dims, Titan v2 = 1024 by default — always confirm in the model docs.)
• Distance metric — Choose Cosine or Euclidean based on your embedding model’s recommendation. Tip: Cosine is common for normalized text embeddings; Titan models typically recommend Euclidean for float32 embeddings.
• Non-filterable metadata keys (optional) — Use this to mark large metadata fields (e.g., long text attributes) as non-filterable. All metadata is filterable by default, but marking non-essential fields as non-filterable can improve efficiency. Each vector can include up to 40 KB of metadata, but only 2 KB of it can be filterable. For large text chunks stored as vector metadata, Bedrock Knowledge Bases typically adds the chunk content (for example, AMAZON_BEDROCK_TEXT). Since these fields can be sizable — often exceeding 2 KB — it’s best to mark them as non‑filterable during index creation to improve efficiency and optimize index performance.
• Encryption — Optionally set bucket encryption. The default, Server-side encryption with Amazon S3 managed keys (SSE-S3) is selected in this demo.

Click Create vector index to finalize the index setup. Your vector index is now ready and will accept embeddings once data ingestion begins.

There are two ways to populate the vector store:

• Automatic ingestion via Bedrock Knowledge Bases — When you connect an S3 data source during Knowledge Base setup, Bedrock automatically reads your documents, chunks them, generates embeddings using the selected model, and writes those vectors into the S3 Vector Index. We will go with this option in this demo.
• Manual embedding (custom pipeline) — You can generate embeddings yourself (using Bedrock APIs or any other embedding model) and insert them directly using the S3 Vectors API (PutVectors API). This is useful for custom workflows or when you need full control over the embedding process.

Next, create a general purpose S3 bucket for storing the documents. This bucket will be our data source for knowledge base. Upload your documents to this bucket.

Next, let’s create the Knowledge Base in Amazon Bedrock and pointing it to use our S3 Vector store.

1. Open the Bedrock console and navigate to Knowledge Bases in the sidebar. Click Create Knowledge Base and choose “Knowledge base with vector store” .
2. Name and permissions: Give your knowledge base a name and description. For the IAM service role, you can let Bedrock create one for you. You may also choose an existing bedrock role if available. The existing role should have S3 permissions to the S3 data source and s3vectors permission to the S3 vector store.
3. Configure data source: On the next screen, select the type of data source. Choose Amazon S3 as the data source type. Then specify the S3 bucket that contains your documents. You can enter the S3 URI or use the file browser to locate the bucket. If your documents are under a specific prefix (folder), you can include that in the path. Leave the parsing strategy and chunking strategy at default for now. You can optionally add inclusion/exclusion filters or metadata files if needed (advanced options, not required in basic cases). If your S3 data is encrypted with a customer-managed KMS key, provide that key so Bedrock can decrypt the objects.
4. Embeddings model: Next, choose the embedding model that Bedrock will use to convert your data into vectors. Select Titan Text Embeddings v2 (or another model of your choice that outputs float32 embeddings). Important: The model’s embedding dimension and type must be compatible with your S3 Vector index. Since we created the index with 1024 dimensions (float32), Titan Embeddings v2 with 1024-dim float32 output is a perfect match.
5. Vector store configuration: This is where we tell Bedrock to use Amazon S3 Vectors. In the “Vector store” section, you have two choices:
6. Quick create a new vector store (Recommended) — This option lets Bedrock create a new S3 Vector bucket and index for you on the fly. Bedrock will manage naming and configuration
7. Use an existing vector store — This allows you to specify the ARN of an existing S3 Vector bucket and index that you created. Provide the Vector bucket ARN and Vector index ARN which we created earlier. It’s important that the index is empty or matches the data source; if you preloaded it with the same documents, Bedrock might either reuse them or overwrite.

Review and create the knowledge base.

It may take couple of minutes to create the knowledge base. Sync the data source to load the documents to the vector DB. Whenever there is a change in the source S3 bucket, use the sync operation to sync the changes to the vector DB. After syncing the data source, the knowledge base is now ready.

With the Knowledge Base configured, the final step is to query it through a foundation model to validate the RAG workflow. You can do this directly in the Bedrock Console by opening your Knowledge Base and selecting Test knowledge base, which lets you enter questions and choose the model used to generate responses.

Note: the test option will be enabled only after the initial data store sync.

Let’s understand what happens when we query the knowledge base. When you submit a natural-language question, Bedrock first embeds the query using the same Titan Embeddings model configured for the Knowledge Base. It then performs a similarity search against the S3 Vector Index to retrieve the most relevant chunks. Once relevant vectors are found, Bedrock sends those chunks along with the original question to the chosen foundation model (Claude Haiku, in this case). The foundation model, using its internal language understanding + the provided context:

• identifies the relevant facts from the retrieved chunks
• maps them to the user’s intent
• constructs reasoning paths constrained to that context

This is where RAG prevents hallucinations — the model is effectively “reminded” of your data and guided to use it.

The foundation generates a response that:

• synthesizes the retrieved facts
• structures them into a human‑readable answer
• keeps the reply coherent and context-specific

For RAG workflows, Bedrock enriches the output with:

• citations pointing to the exact chunks / S3 objects used
• metadata about which document supplied each part of the answer

This enables full traceability and auditability for enterprise use. Amazon Bedrock automatically handles the entire RAG workflow, including data ingestion, chunking, embedding generation, and vector indexing/querying within S3 Vectors. This eliminates the operational overhead of provisioning, scaling, or managing a separate vector database cluster. S3 Vectors is ideal when the priority is cost-effective storage and management of vast, long-term vector datasets for AI workloads, with the ability to scale automatically as your data grows.

There are some disadvantages also with S3 vector store.

• S3 Vectors is a simpler storage solution than a full search and analytics platform like Amazon OpenSearch. It lacks native support for complex querying capabilities such as combining vector similarity searches with keyword filtering, aggregations, or other advanced query DSL features within a single operation.
• Another disadvantage of using an S3 vector store is its higher query latency compared to dedicated, high-performance vector databases, making it unsuitable for real-time, ultra-low-latency applications.
• As a serverless, partition-based engine, S3 Vector may experience occasional latency spikes under cold-start or heavy-load conditions.
• S3 operates on an eventual consistency model for some operations, meaning updates to objects can take some time to propagate fully. While generally acceptable for analytics and batch processing, this needs to be a consideration for systems requiring immediate data consistency.
• There is a strict 2 KB limit for metadata keys that can be used for filtering. The combined limit for filterable and non-filterable metadata per vector is 40 KB.
• Fixed Dimensions is another disadvantage. Once you select an embedding model and create the vector index, you cannot change the dimensions; a mismatch will cause ingestion failures.
• S3 vector store is not designed for high Queries Per Second (QPS) scenarios. The service is optimized for workloads with less frequent queries

In summary, S3 Vectors is a highly scalable and cost-effective solution best suited for “cold” or batch-style RAG workloads where latency requirements are flexible. For “hot” path, high-queries-per-second (QPS) applications demanding millisecond latency, a hybrid approach or a dedicated vector database like Amazon OpenSearch Serverless is more appropriate.