Choosing a Vector Store on AWS

A knowledge base needs somewhere to keep the vectors. Bedrock does not run that store for you in the general case: you provision it, you pay for it, and you pick it at knowledge base creation time. It cannot be swapped later without rebuilding, so the choice matters.

Nearly every option supports approximate nearest-neighbour search well enough. What separates them is what else they give you, and what you already operate.

The options

Store	What it is for	Watch out for
OpenSearch Serverless	The default. Managed, no cluster to size, and the only family that supports hybrid search - semantic plus keyword matching in one query.	Billed on OpenSearch Compute Units with a capacity floor, so an idle collection still costs money. Needs a data access policy, not just IAM.
OpenSearch Managed Cluster	Same engine when you want to control instance types, version and sizing yourself.	You own capacity planning, upgrades and node failures.
Amazon S3 Vectors	The cheapest option and the only genuinely pay-per-request one: vectors live in an S3 vector bucket, with no cluster, no node and no capacity floor to pay for while idle.	Higher query latency than OpenSearch or MemoryDB, and no hybrid search. Aimed at large, cost-sensitive or infrequently queried corpora.
Aurora PostgreSQL with pgvector	Vectors alongside relational data, so retrieval results can be joined to rows you already store. Cheap if you run Aurora anyway; Aurora Serverless v2 scales down.	Requires the RDS Data API enabled and credentials in Secrets Manager. You create the extension, table and index yourself unless you use quick-create.
Neptune Analytics	GraphRAG. Bedrock extracts entities and relationships from your documents into a graph, then combines vector similarity with graph traversal - better for multi-hop questions where the answer is spread across documents.	Ingestion is heavier and costlier; overkill for a flat FAQ corpus.
Amazon DocumentDB	Vector search inside a MongoDB-compatible database you already run.	Only sensible if DocumentDB is already in your stack.
Amazon MemoryDB	In-memory vector search for the lowest retrieval latency.	Highest cost per gigabyte stored - you are paying for RAM. Reserve it for latency-critical paths.
Amazon Kendra (GenAI index)	A managed retriever rather than a vector database: Kendra handles connectors, ingestion, ranking and document-level access control based on user identity.	You give up control of chunking and embedding - those settings do not apply. Priced as Kendra, not as a vector index.

How to choose

Work down this order:

1. Do you need per-user document permissions enforced at retrieval time, over connectors you would otherwise build? Kendra.
2. Do questions require joining facts across documents ("which suppliers are affected by this recall?")? Neptune Analytics.
3. Do you need results joined to relational data, or do you already run Aurora? Aurora pgvector.
4. Do you need single-digit-millisecond retrieval? MemoryDB.
5. Is cost the dominant constraint, with slower queries acceptable and no need for keyword matching? S3 Vectors.
6. Otherwise, OpenSearch Serverless - and if exact terms matter (part numbers, error codes, names), OpenSearch is also the way you get hybrid search.

The trade-off nobody mentions until the bill arrives

Most vector stores are provisioned infrastructure rather than per-query serverless, and S3 Vectors is the exception that is priced per request. A knowledge base holding ten documents costs roughly what one holding ten thousand does on OpenSearch Serverless, because you are paying for the minimum capacity. For many small, isolated corpora, one store with metadata filtering per tenant is far cheaper than one collection per tenant - but only if your isolation requirements allow a shared index.

Note also that a knowledge base does not have to be vector-backed at all. A structured-data knowledge base over Amazon Redshift generates SQL from a natural-language question instead of embedding anything - the right answer when the facts live in columns and rows rather than prose.

{
  "storageConfiguration": {
    "type": "RDS",
    "rdsConfiguration": {
      "resourceArn": "arn:aws:rds:eu-west-1:111122223333:cluster:kb-aurora",
      "credentialsSecretArn": "arn:aws:secretsmanager:eu-west-1:111122223333:secret:kb-aurora-admin-AbCdEf",
      "databaseName": "bedrock_kb",
      "tableName": "bedrock_integration.bedrock_kb",
      "fieldMapping": {
        "primaryKeyField": "id",
        "vectorField": "embedding",
        "textField": "chunks",
        "metadataField": "metadata"
      }
    }
  },
  "_notes": {
    "prerequisites": [
      "RDS Data API must be enabled on the cluster",
      "CREATE EXTENSION vector; then a table whose embedding column dimension matches the embedding model output",
      "An HNSW index on the embedding column for the distance operator you use",
      "The knowledge base service role needs secretsmanager:GetSecretValue and rds-data permissions"
    ]
  }
}